Transport Layer Security

From ArchWiki
(Redirected from Ca-certificates)
Jump to navigation Jump to search

According to Wikipedia:

Transport Layer Security (TLS), and its now-deprecated[1] predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.


Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Mention that NSS in contrast to the other implementations uses databases. (Discuss in Talk:Transport Layer Security#)

There are five TLS implementations available in the official repositories. OpenSSL should already be installed on your system as it is an indirect dependency of the base meta package (base > coreutils > openssl). GnuTLS might already be installed on your system as it is required by many packages.

  • OpenSSL — A robust, commercial-grade, and full-featured toolkit for the TLS and SSL protocols; also a general-purpose cryptography library. || openssl
  • GnuTLS — A free software implementation of the TLS, SSL and DTLS protocols. Offers APIs for X.509, PKCS #12, OpenPGP and other structures. || gnutls
  • Network Security Services (NSS) — Implementation of cryptographic libraries supporting TLS/SSL and S/MIME. Also supports TLS acceleration and smart cards. || nss
  • mbed TLS — Portable SSL/TLS implementation, aka PolarSSL. || mbedtls
  • LibreSSL — A version of the TLS/crypto stack forked from OpenSSL in 2014 by the OpenBSD project, with goals of modernizing the codebase and improving security. || libressl

Certificate authorities

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: What does update-ca-trust do? What is p11-kit? Where are certificates stored? (Discuss in Talk:Transport Layer Security#)

With TLS one of a set of certificate authorities (CAs) signs for the authenticity of a public key certificate from a server. A client system connecting to the server via TLS may verify its certificate's authenticity by relying on a CA certificate obtained via a separate path. On Arch Linux the certificate authorities are provided by the ca-certificates package, which is most likely already installed because of the dependency chain (pacman > curl > ca-certificates), and has the following dependency tree (excerpt):

Trust management

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: How to distrust a certificate authority? Where to cover CRL? (Discuss in Talk:Transport Layer Security#)

See Security#Managing SSL certificates on how to blacklist a certificate authority.

Trust a certificate authority system-wide

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Without the anchor you can trust regular certificates. Does it need to be in PEM format? (Discuss in Talk:Transport Layer Security#)
Warning: This allows anyone with access to the private key to intercept all of your TLS traffic.
# trust anchor certificate.crt

This is for example required to allow a HTTPS MITM proxy to intercept traffic.

Obtaining a certificate

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Recommended key size? (Discuss in Talk:Transport Layer Security#)

The first step is to generate an RSA private key. Before generating the key, set a restrictive file mode creation mask with umask (for example 077).

Note: The openssl package does not properly safeguard the /etc/ssl/private directory like most other distributions do, see FS#43059.

A certificate can be obtained either from a certificate authority with a Certificate Signing Request (CSR) or self-signed. While self-signed certificates can be generated easily, clients will reject them by default, meaning that every client needs to be configured to trust the self-signed certificate.

For the actual generation commands refer to the article of the used implementation:


Server-side recommendations

Because there are various attacks against TLS the best practices should be considered:

Checking TLS

Programs to check TLS:

Websites to check TLS:


ACME clients

The Automated Certificate Management Environment (ACME) protocol lets you request valid X.509 certificates from certificate authorities, like Let's Encrypt.

See also List of ACME clients.

  • acme-client — Secure Let's Encrypt client, written in C. || acme-client-portableAUR
  • acme-tiny — A 200-line Python script to issue and renew TLS certs from Let's Encrypt. || acme-tiny
  • — A pure Unix shell script ACME client. ||
  • acmetool — An easy-to-use ACME CLI, written in Go. || acmetoolAUR, acmetool-gitAUR
  • Certbot — ACME client recommended by Let's Encrypt, written in Python. || certbot
  • dehydrated — ACME client, written in Bash. || dehydrated, dehydrated-gitAUR
  • getssl — ACME client, written in Bash. || getsslAUR, getssl-gitAUR
  • lego — Lets Encrypt client and ACME library, written in Go. || lego-gitAUR
  • letsencrypt-cli — Yet another Letsencrypt (ACME) client using Ruby. || letsencrypt-cliAUR
  • manuale — A fully manual Let's Encrypt client, written in Python. || manualeAUR
  • ruby-acme-client — A Ruby client for the letsencrypt's ACME protocol. || ruby-acme-clientAUR
  • simp_le — Simple Let's Encrypt client, written in Python. || simp_le-gitAUR


The Online Certificate Status Protocol (OCSP) is supported by Firefox. Chromium has its own mechanism[2].

See also ocsptool(1) by GnuTLS and ocsp(1ssl) by OpenSSL.


The HTTP Strict Transport Security (HSTS) mechanism is supported by Firefox, Chromium and wget (~/.wget-hsts).


See Wikipedia:DNS Certification Authority Authorization.

See also