This FAQ is divided into the following sections:
Let’s Encrypt is a global Certificate Authority (CA). We let people and organizations around the world obtain, renew, and manage SSL/TLS certificates. Our certificates can be used by websites to enable secure HTTPS connections.
Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.
To get started using Let’s Encrypt, please visit our Getting Started page.
We do not charge a fee for our certificates. Let’s Encrypt is a nonprofit, our mission is to create a more secure and privacy-respecting Web by promoting the widespread adoption of HTTPS. Our services are free and easy to use so that every website can deploy HTTPS.
We require support from generous sponsors, grantmakers, and individuals in order to provide our services for free across the globe. If you’re interested in supporting us please consider donating or becoming a sponsor.
In some cases, integrators (e.g. hosting providers) will charge a nominal fee that reflects the administrative and management costs they incur to provide Let’s Encrypt certificates.
Let’s Encrypt is run by a small team and relies on automation to keep costs down. That being the case, we are not able to offer direct support to our subscribers. We do have some great support options though:
Here’s a video we like about the power of great community support.
We recommend reporting such sites to Google Safe Browsing and the Microsoft Smart Screen program, which are able to more effectively protect users. Here are the reporting URLs:
If you’d like to read more about our policies and rationale, you can do so here:
https://letsencrypt.org/2015/10/29/phishing-and-malware.html
For most browsers and operating systems, yes. See the compatibility list for more detail.
Let’s Encrypt certificates are standard Domain Validation certificates, so you can use them for any server that uses a domain name, like web servers, mail servers, FTP servers, and many more.
Email encryption and code signing require a different type of certificate that Let’s Encrypt does not issue.
No. Never.
The private key is always generated and managed on your own servers, not by the Let’s Encrypt Certificate Authority.
Our certificates are valid for 90 days. You can read about why here.
There is no way to adjust this, there are no exceptions. We recommend automatically renewing your certificates every 60 days.
We have no plans to issue OV or EV certificates.
Yes, the same certificate can contain several different names using the Subject Alternative Name (SAN) mechanism.
Yes. Wildcard issuance must be done via ACMEv2 using the DNS-01 challenge. See this post for more technical information.
There are a large number of ACME clients available. Chances are something works well on your operating system. We recommend starting with Certbot.
Yes, but not all clients support this feature. Certbot does.
This is normal and anticipated. During the certificate issuance process, Let’s Encrypt will validate control of your domain from multiple network perspectives. After successful validation, your certificate will be submitted to numerous Certificate Transparency (CT) logs. See here for more details about why this is necessary. Shortly after the certificate is submitted to CT, automated CT crawling bots will be able to discover your domain, attempt to access it, and generate further traffic in your webserver logs.
We don’t publish a list of IP addresses we use to validate, and these IP addresses may change at any time. Note that we now validate from multiple IP addresses.
Once you successfully complete the challenges for a domain, the resulting authorization is cached for your account to use again later. Cached authorizations last for 30 days from the time of validation. If the certificate you requested has all of the necessary authorizations cached then validation will not happen again until the relevant cached authorizations expire.
We ask that ACME clients perform routine renewals at random times to avoid spikes in traffic at set times of the day, such as exactly midnight UTC, or the first second of each hour or minute. When the service is too busy, clients will be asked to try again later, so randomizing renewal times can help avoid unnecessary retries.
Longtime security researcher and practitioner, Ivan Ristić, published a configuration guide that provides useful information about what you should consider as you set up your TLS configuration.
For more extensive background and greater detail, we recommend Bulletproof TLS and PKI, also written by Ristić.