Things you want to know about Let's Encrypt

— Leave a Comment

Let's Encrypt is a new certificate authority that entered the internet scene at the end of 2015.

Let's Encrypt is not simply another certificate authority, if for no other reason than the certificates are free, whereas the vast majority of existing certificate authorities sell SSL/TLS certificates for a price that depends on the certificate type.

However, Let's Encrypt is not only free. Quoting the homepage: Let's Encrypt is free, automated, and open.

But what does it mean? In this article I'll share some of the direct consequences of that quote to help you better understand how Let's Encrypt (currently) works. My goal here is not to judge or advertise the service offered by Let's Encrypt (either in a negative or positive way), rather provide an overview of what you should expect if you use this service, and let you decide whether Let's Encrypt is a good fit for you or not.

In addition, since I've been closely monitoring and testing the service for the last weeks for personal and business use, I'll also provide some extra details you should know about the current status of the project and the issued certificates.

Table of Contents

Let's Encrypt is free

And this is a fact. It's also very easy to understand: any certificate issued by Let's Encrypt is free as in beer and you don't need to pay for it (as long as you obtain it directly from the Let's Encrypt website, as other providers may still resell the service in one way or another).

However, wording is important here: it's not true that Let's Encrypt will issue any certificate for free (and this is a common misunderstanding). Not because Let's Encrypt charges you for some SSL certificate types, but because there are some types of certificates that Let's Encrypt will not issue at all. I'll talk about the supported certificates later on in this article.

Let's Encrypt is free to use, but not free to run or operate. Developing, maintaining, and operating a certificate authority is very complex. Indeed, there are non-trivial technical challenges associated with encryption/cryptography, but also security risks and implications associated with the ability to issue publicly trusted SSL certificates. The reason why I bring this to your attention is because, regardless your opinions about the current or future state/policies/decisions/… of the Let's Encrypt service, you should respect the work of the people directly or indirectly involved with this project.

Let's Encrypt is Automated

The operational model of Let's Encrypt is designed to be completely automated: no manual intervention should be required to register for the service, request, issue, revoke or renew a certificate.

The goal is to encourage the development or libraries, tools, and services that can automate the deployment of secure sites. Nowadays the issuance process often involves manual steps (such as the email-based validation) that represent a bottleneck for the automatic deployment, and drastically affect a large-scale HTTPS distribution.

It's easy to understand that this operational model has some limitations, and in fact Let's Encrypt doesn't support EV and OV certificates. This is an important aspect to keep in mind, but keep reading. I'll discuss the various limitations later in this article.

If you have some programming skills, it's clear that the possibilities offered by Let's Encrypt and a fully-automated process are almost infinite: you can integrate it into your service, create a command line tool, script the deployment a new machine from zero to HTTPS without a single human intervention. I'll talk about integration in the Notes section.

Let's Encrypt is Open

All the Let's Encrypt code and protocol specifications are on GitHub.

letsencrypt/boulder is the heart of the service. It's the certificate authority source code, written in Go. It contains the core modules, the validation authority, the certificate authority, everything.

letsencrypt/letsencrypt is a client, written in Python, that can be used to obtain certificates and extensibly update server configurations automatically. The client is compatible with Let's Encrypt and any other authorities that follows the specifications of the ACME protocol.

The ACME specification itself is also open source. This protocol was designed to automate the management of domain-validation certificates, based on a simple JSON-over-HTTPS interface.

From the practical point of view of a technical person, Let's Encrypt being open source means:

From the practical point of view of an user, Let's Encrypt being open source means transparency.

Moreover, if you have a question or a doubt, you can generally find the answer in the source code or someone can point you to that. If you ever had to deal with a certificate authority in the past, you probably know how hard it is to get technical information or knowledgeable support (especially from their first-line customer services).

Beta and Limitations

At the time of writing (February 2016), Let's Encrypt is in public beta and it will probably take some time before the service hits the general availability.

Although the original meaning of beta has been drastically altered in the last years, in this case, beta indicates the service still hasn't reached the maturity to be considered stable and complete. Therefore, it is potentially unstable, incomplete, and under heavy development.

In general, the following statement pragmatically summarizes the current state of the project:

In this section, I'll talk about some of the limitations and outstanding issues that will likely affect your usage of the service.

Rate-Limiting

Read this section carefully. Most people are currently hitting rate limits because they are not aware of the limit or because of an improper usage of the clients/tools.

It's not by coincidence that this topic is the first one of the Beta section. It's definitely one of the most popular "issues". During this beta test, Let's Encrypt have very tight rate-limiting in place. They plan to loosen these limits as the beta proceeds.

There are two rate limits in play:

  • Registrations/IP address limits the number of registrations you can make in a given time period; currently 10 per 3 hours.
  • Certificates/Domain is 5 certificates for a registered domain in a sliding window of 7 days.

A registered domain is a combination of a Top Level Domain + Domain. Each issued certificate counts against the limit. If you issue a single SAN certificate with multiple domains, each domain will also counts against the limit.

You should use the staging environment for testing, before using the production environment. This will allow you to get things right before issuing trusted certificates and reduce the chance of hitting the rate limits.

Official answer about rate limiting. Rate limits also apply on renewals and reissues.

Rate limits can't be reset. Once you hit the limit, you'll have to wait until the end of the limit window in order to be able to issue/reissue/renew a certificate. You are warned.

Does not work on XP

Certificates issues by Let's Encrypt don't play well on Windows XP. The issue is still under investigation, there is also an open ticket. See compatibility.

Does not work on Java

Java currently doesn't recognize the certificate because one of the intermediate certificates is not trusted. See compatibility.

Beta Client

Let's Encrypt is committed into the development of an official ACME client. The client is written in Python, and will support the majority of platforms.

The Let's Encrypt Client is a fully-featured, extensible client for the Let’s Encrypt CA (or any other CA that speaks the ACME protocol) that can automate the tasks of obtaining certificates and configuring web servers to use them. Please remember the client is currently beta software.

The most relevant (current) limitations of the official client are:

  • It only supports Debian-based OSes (such as Debian and Ubuntu). The support for other platforms is either experimental (such as Mac OS X) or not available yet
  • It only supports Apache. The Nginx integration is experimental, however it's also possible to generate a certificate manually using the certonly flag.
  • It doesn't support the DNS challenge, hence it's not possible to use to validate a certificate via DNS. Most third-party client already support it.
  • It doesn't support Python 3

Elliptic Curve Cryptography (ECC) support

Right now, all the root and intermediate keys use RSA. Let's Encrypt is planning to generate ECC keys and support Elliptic Curve Cryptography at some point in 2016.

Right now all of our root and intermediate keys use RSA. We're planning to generate ECC keys and make an ECC option available to subscribers in 2016. – @josh

Internationalized Domain Names support

Internationalized domain names are currently not supported. Let's Encrypt will eventually support them, but it's still not clear whether it will be before or after the general availability. There is currently no ETA.

We would like to support them eventually. – @josh

Important Notes

Several decisions were made as part of the development of the ACME protocol in order to keep Let's Encrypt free, automated and open. Some of these decisions are definitely new and unusual when compared to the existing certificate authorities.

As I mentioned at the beginning of this post, Let's Encrypt is not a classic certificate authority. In this section I'll summarize the most relevant policies that, for better or for worse, will likely affect your decision to use Let's Encrypt or not.

Some of the following notes, and other questions I will not answer here, are covered in the frequently asked questions.

Compatibility

The major browsers and platforms are supported, see Which browsers and operating systems support Let's Encrypt.

Make sure to double check the post above before installing a Let's Encrypt certificate. Also note that Let's Encrypt will only issue SHA256 signed certificates, hence any client that can't handle SHA256 certs (such as pre-SP3 Windows XP) is not compatible.

There are currently some known issues with Windows XP and Java.

Supported Certificate Types

Let's Encrypt only issues domain validated certificates. Organization validated or extended validation certificates are not issued and will not be issued because the process can't be automated.

We expect that Let's Encrypt won't support EV, because the EV process will always require human effort, which will require paying someone. Our model is to issue certificates free of charge, which requires a level automation that doesn't seem compatible with EV. – @schoen

Let's Encrypt doesn't support wildcard certificates: it only issues single-name or multi-domain (SAN) certificates. The decision about not supporting the wildcard domain is a result of technical challenges in the validation process. Let's Encrypt doesn't currently support wildcard certificates.

Wildcard certs aren't yet supported by the ACME protocol. There has been discussion on the IETF ACME mailing list, as well as issue 97 at the original acme-spec. – @jcjones

We're not currently planning to offer wildcard certificates. – @schoen

UPDATE Jun 2017: Wildcard certificates may be supported from Jan 2018 with ACME v2.

The current limit for the SAN multi-domain certificates is 100 domains per certificate. This is a decision and not a technical limitation.

We've set the limit to 100 out of an abundance of caution, as it appears that when you get over 100, some web browsers misbehave. We can probably raise that if anyone wants us to. @jcjones

Staging

Let's Encrypt provides a staging environment you can use for testing, before using the production environment.

You already know that the production environment has strict rate limits. Using staging will allow you to get things right before issuing trusted certificates and reduce the chance of hitting the rate limits.

There are no specific limitations in the staging environment, except that issued certificates are not trusted (they are issued by Happy Hacker Fake CA) and the certificates are not submitted to the certificate transparency logs.

90-days Expiration

Let's Encrypt certificates currently have a ninety-day lifetime. Web standards do not require any minimum certificate lifetime. As of 2015, the Baseline Requirements specify a maximum certificate lifetime of 39 months. The Technical Advisory Board, chose a 90-day certificate lifetime to start with, with an expectation that people will want to auto-renew at the 60-day mark.

– @josh

Along with the decision to not support wildcard certificates, this is one of the most controversial policies. Hate it or love it, all SSL certificates issues by Let's Encrypt have a 90-day expiration. There is no exception and you can't obtain a certificate with a longer expiration, let's say 1 year (or longer), as you would normally do today from any other certificate authority.

The main goal is to encourage automation, as well decrease the risks in case the certificate is compromised or revoked.

Certificate for public IPs

It's not possible, and it will not be possible, to issue a certificate for an IP address.

Let's Encrypt has decided not to issue certificates for bare IP addresses even if this would be permitted by the Baseline Requirements.

Certificate Transparency

Let's Encrypt fully supports Certificate Transparency: all issued certificates are submitted to the Certificate Transparency logs. This is also discussed on the forum.

You can search, monitor and audit Let's Encrypt certificates using the crt.sh tool.

Clients

As I already mention, Let's Encrypt is committed into the development of an official ACME client, written in Python.

However, there is a long list of client implementations in several different programming languages. The list is currently divided into clients and libraries.

Libraries generally provide the low-level foundation to communicate with an ACME-compliant certificate authority. You can use a library in an existing project or to create your own tool/program.

A client is generally a tool or a command line script you can use to issue and manage a certificate, either manually or programmatically. Some libraries also offer a client component.

I personally contributed to the Let's Encrypt Go client (lego) and I had the chance to play with the Ruby ACME library. Both libraries are under development, but they already implement the majority of the methods to request a certificate.

In conclusion

Let's Encrypt certainly looks very promising, and the ability to have a fully automated issuance process for SSL certificates is a big step forward to facilitate the large-scale adoption of HTTPS.

Competition is generally good for the end users, and in this case we can expect the existing certificate authorities to modernize their issuance process to keep up with Let's Encrypt. However, it's also really unlikely that Let's Encrypt will replace the current market of SSL certificates, mostly because of the lack of support for some types of certificates currently widely adopted, such as the wildcard and EV certificates.

And this is probably one of the most important considerations: users have to understand that Let's Encrypt is not the solution to each problems. LetsEncrypt is not trying to be a one-size-fits-all certificate authority and there are a huge number of situations/configurations where Let's Encrypt will not and maybe should not be applied (cit).

There is still place for other, non free, certificate authorities. The hope, is that at these authorities will at least be more automated and open.

Related Posts