How Does Let’s Encrypt Gain Your Browser’s Trust?
Ethan Robish //
ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.
Let’s Encrypt is a free service that allows you to obtain a free (as in beer) SSL/TLS domain validation certificate to use as you wish. Here is what they have to say about themselves:
Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Research Group (ISRG).
The key principles behind Let’s Encrypt are:
- Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
- Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
- Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
- Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
- Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
- Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.
You might be wondering how such a service can exist. On the technical side the answer is fairly straightforward. Let’s look at why your browser automatically trusts certificates issued by this provider.
Inspecting a certificate obtained from Let’s Encrypt shows that it was issued by “Let’s Encrypt Authority X3” which is in turn signed by “DST Root CA X3”.
Next, I opened up the list of my system’s certificates. I run Mac OS X, but you can find a similar list on your operating system as well. I searched for the certificate authority (CA) I found earlier, “DST Root CA X3”, and it came right up. Mystery solved. Let’s Encrypt has been issued an intermediate certificate that is signed by a root CA certificate that comes bundled with your operating system. More on that below.
One side note is that while Internet Explorer, Safari, and Google Chrome all use the host operating system’s certificate store, Mozilla Firefox comes bundled with it’s own. “DST Root CA X3” is listed there, but it is interesting to see that Let’s Encrypt’s certificates are listed directly there as well.
To confirm our bit of sleuthing, this Let’s Encrypt blog post details how it obtained its first certificates. It essentially echoes what we’ve just uncovered.
The post also had a nice diagram showing the signing relationships. There are a couple more moving parts in the diagram because Let’s Encrypt actually first generated a key pair for its parent organization, the Internet Security Research Group (ISRG), which is shown as well.
One question remains, however, since the post only mentions Let’s Encrypt Authority X1 & X2. But my earlier screenshots show a Let’s Encrypt Authority X3. What’s going on? This forum post answers that question. In an effort to gain better backwards compatibility, Let’s Encrypt had two new certificates issued named Let’s Encrypt Authority X3 & X4.
IdenTrust (in the form of the DST Root CA X3 certificate we found earlier) is already a trusted CA in your system’s certificate store. By having IdenTrust sign Let’s Encrypt’s intermediate certificates, it allowed Let’s Encrypt to bypass what it claims is a 3-6 year process of getting their own root CA into operating systems certificate stores.
Remember how I said that Firefox has it’s own self-contained certificate store? Turns out it’s much quicker to get a certificate added there because Let’s Encrypt has announced that the “ISRG Root X1” key shown in the diagram above will be included starting with Firefox 50.
There are already instructions on implementing Let’s Encrypt for many operating systems and web servers here, along with countless other articles that you can use Google to find. However, if there’s enough interest I may do a follow-up post where I walk through my own non-trivial setup. I created a workflow that allows integrating Let’s Encrypt into a pre-existing Nginx configuration with zero downtime. In addition, it lets me quickly secure a new sub-domain at any time using Let’s Encrypt. If you’re interested in this type of setup let me know on Twitter at @EthanRobish.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
@packetbrigade
September 10, 2016 @ 2:40 pm
Thanks for writing this up, Ethan. Our web host recently changed my company’s website SSL cert to use Lets Encrypt and I’ve been meaning to figure out how it works.
I am optimistic that the security benefits of a system like lets encrypt will be a net benefit to security. For example, if the pain of renewing certs is reduced admins are more likely to use TLS and CA issued certs on their web apps, servers, and tools.
Some ideas for follow-up questions in case you decide to write a part two:
How was domain verification handled with the testing you did? Was there any top-level ownership verification (e.g. via email, or adding TXT record) by the CA?
Is Lets Encrypt load-balancer / proxy friendly? Does it support something like SCEP for enrollment of 3rd party devices like firewalls, phones, etc?
Does the Lets Encrypt automagic renewal protocol function similarly to automagic renewal of member server certs in with an Active Directory CA?
Ethan
September 13, 2016 @ 5:54 pm
Hello @packetbrigade and thank you for your comment!
I will definitely look into and address some of those topics if I do a part two. In the meantime, here is what I know from my experience so far.
Domain verification happens using the ACME protocol. This boils down to challenge-response from Let’s Encrypt’s API servers and your domain. The client script provides the response by means of a HTTP web page served at a specific URL on your domain. Their server verifies that this URL is available and that it returns the correct value, which is sufficient verification for them to issue the certificate.
I’m not sure I can answer your second questions. I currently use Nginx as a reverse proxy for a for a web app and the Let’s Encrypt cert works fine. I don’t use any load balancing features but I see no reason why it wouldn’t work there either. I’m not familiar with SCEP so I can’t answer that part of your question.
Automatic renewal happens the same way the initial certificate was issued. So you have to make sure you remove any manual steps and only rely on the script+config. Then you just put that in a cron job or something similar. Let’s Encrypt will let you renew once you are in a certain time frame from your expiration (30 days I think).