maxkabakov - Fotolia
The evolution of the Let's Encrypt certificate authority
Certificate authorities work differently since the open source Let's Encrypt project went into effect. Expert Fernando Gont explains how both CAs and Let's Encrypt operate.
As strong cryptographic protection for websites continues to grow in importance to ensure the privacy of web communications, the Let's Encrypt certificate authority, which was first established in 2016, is changing the industry in interesting ways.
A public key infrastructure (PKI) is a key enabler of secure internet communications. A PKI consists of a variety of components that securely distribute public keys. These components typically include certificates, a procedure to evaluate a chain of certificates starting from a trust anchor, certificate repositories and a certificate revocation mechanism.
Certificates are standardized messages that bind an entity, such as a domain name, to a public key so that whenever a website wants to securely communicate with such an entity, it is possible to securely determine which public key should be used.
Certificates are issued by certificate authorities (CAs), which are expected to verify the identity of the entity for which a certificate is issued. CAs subsequently certify that a given public key corresponds to that entity by signing the certificate with their own key.
For example, if certificates are used for email, the CA should verify that you have control over the email address for which you want a certificate. Similarly, if you want a CA to issue a certificate for a website or mail server domain name, the CA should verify that you own or control that domain name.
Once the CA has verified the necessary information, it will issue a certificate that has been signed with its own public key. Thus, one may verify the validity of the certificate by checking the contents of the certificate itself -- such as its valid dates and other fields -- and the signature of the certificate authority. Certificates usually form a certificate chain.
Each rectangle in the figure above represents a certificate, and the note on the right hand side of each square specifies the key used to sign the certificate in question.
The basic idea behind a certificate chain is that you start with a root certificate you trust -- Z in this case -- which is used to sign the next certificate in the chain. This successive signing of certificates continues through the final certificate, forming a chain of trust. We can trust Y because we trust Z, we trust X because we trust Y, and so on.
In the example above, Z vouches that Z's public key is z -- this is a self-signed certificate. Z also vouches that Y's public key is y, Y vouches that X's public key is x, and X vouches that W's key is w. Z is said to be a trust anchor, meaning that it is secure and can be trusted. Y and X are usually called intermediate certificates and they correspond to certificate authorities. Finally, W is called a leaf or server certificate and it is the certificate you would use for a web server, mail server or to secure email.
Most applications, especially web browsers, ship with a number of trust anchors in the application software. The specific set of anchors is selected at the developer's own discretion. For example, the Chrome web browser ships with over 80 trust anchors.
In theory, there should be a repository from which certificates can be accessed or downloaded. However, in many PKIs, this repository does not really exist, and certificates are sent in-band when needed -- like during an SSL/TLS session establishment.
Finally, the PKI incorporates mechanisms that enable the revocation of certificates. Consider, for example, the scenario in which a certificate has been compromised. In order to prevent further use of the certificate, there should be some means for a certificate authority to advertise that a certificate has been revoked.
The revocation mechanism is based on certificate revocation lists (CRL) that are published by CAs which, as the name implies, list certificates that should no longer be accepted. Verifiers should check the certificate issuer's CRL to determine whether a certificate has been revoked and should no longer be trusted.
Use of encryption on the internet
Operating a CA can be costly; the more rigorous the processes used to verify certificate requesters is, the more costly it is to run the CA. Thus, buying a certificate -- that is, getting a CA to issue a certificate for a domain name -- has been expensive for a long time. This, along with the complexity associated with issuing and renewing certificates, was generally seen as an unnecessary burden only electronic commerce sites needed.
Less than ten years ago, many popular websites, including Facebook and others, did not use SSL/TLS to encrypt network traffic, but used rather plain HTTP on TCP port 80, thus sending all their information as clear-text, which was vulnerable to man-in-the-middle and eavesdropping attacks.
The Snowden revelations about pervasive monitoring raised awareness about the reality that eavesdropping attacks are more commonplace than was previously assumed. This generated the necessary momentum for the internet community to work toward a more widespread use of encryption.
While the motivation for widespread use of encryption was evident, there were still at least two key issues to tackle; first, the monetary cost of issuing certificates, and second, the complexity associated with issuing, renewing and installing certificates.
For small or noncommercial sites, the monetary cost of certificates represented an extra cost that had generally been seen as unwarranted. On the other hand, the procedure to buy, install and renew a certificate tended to be trivial.
The Let's Encrypt certificate authority
In mid-2016, the Let's Encrypt certificate authority project was launched as a free, open and automated certificate authority. Let's Encrypt would issue certificates at no cost, using software that would automate the issuance, renewal and configuration of certificates using open protocols.
Put another way, any owner of a domain name could get Let's Encrypt to issue a certificate for their domain name for free by employing a user-friendly tool that, with a simple configuration, could automate the issuance and renewal of certificates and even automatically install them on a local web server. Let's Encrypt only issues domain-validated certificates and not extended validation or organization-validated certificates, which require a more thorough identity validation processes.
The sponsors of the Let's Encrypt certificate authority project, including Cisco, Akamai, Google Chrome and dozens of others, provide the funds needed to keep the project free of charge for users.
Automation of certificate issuance and renewal
Let's Encrypt uses the Automatic Certificate Management Environment (ACME) protocol, which is still being standardized by the Internet Engineering Task Force. The protocol enables the automation of certificate issuance, renewal and revocation. Essentially, ACME automates the process of verifying that a user controls a domain name in use on a server, so that, upon verification, the corresponding certificate can be issued.
A number of tools, such as certbot, can also automatically edit a web server configuration file if HTTPS is enabled.
Trust for Let's Encrypt certificates
In order to properly validate a CA's certificates, a certificate chain must exist from the trust anchor to the server or leaf certificate. Ideally, CAs will have their root certificate installed as a trust anchor in all the relevant software, such as web browsers. For example, at the time of this writing, the Let's Encrypt root is already directly trusted by all the major root programs, including Microsoft, Google, Apple, Mozilla, Oracle and BlackBerry.
However, legacy versions of popular web browsers existed before the Let's Encrypt project even started and, thus, the Let's Encrypt root will not ship as one of the trust anchors in such browsers.
In order to address this issue, Let's Encrypt partnered with the IdenTrust CA, with IdenTrust signing Let's Encrypt's intermediate certificates. Therefore, if an application does not directly trust the Let's Encrypt root, it can still trust certificates issued by Let's Encrypt thanks to the IndenTrust cross-certificate.
The following figure depicts how Let's Encrypt intermediate certificates are signed.
Let's Encrypt has proven successful for issuing domain-validated certificates, with the number of active certificates approaching roughly 100 million.
