For most browsers and operating systems, yes. See the compatibility list for more detail.
Today! Install the Certbot client to get started. The Let’s Encrypt CA service is ready for production and has successfully issued millions of certificates. The Certbot client is now in its beta test phase. Things are working, but you may run into some bumps along the way. Please report any issues and we’ll try to fix them!
Certbot will fetch Let’s Encrypt certificates that will be standard Domain Validation certificates, so you can use them for any server that uses a domain name, like web servers. You can also use these certificates for other TLS applications such as IMAPS.
No. Email encryption and code signing require a different type of certificate than the Let’s Encrypt CA is issuing.
The private key is always generated and managed on your own servers, not by the Let’s Encrypt certificate authority.
Certbot and Let’s Encrypt have no plans to issue EV certificates at this time.
Yes, the same certificate can apply to several different names using the Subject Alternative Name (SAN) mechanism. Certbot automatically requests certificates for multiple names when requested to do so. The resulting certificates will be accepted by browsers for any of the domain names listed in them.
Yes! Let’s Encrypt has begun issuing wildcard certificates in March 2018. Certbot has added support for wildcard certificates as of version 0.22.0. Obtaining a wildcard certificate requires using the DNS authentication method, either via
--manualor via a Certbot DNS plugin appropriate to your DNS provider.
Note that depending how you install Certbot, appropriate plugins to automate the process may not yet be available on your system. Information about the DNS plugins is available in the Certbot documentation.
Certificates obtained with
--manualcannot be renewed automatically with
certbot renew(unless you’ve provided a custom authorization script). However, certificates obtained with a Certbot DNS plugin can be renewed automatically. In order to obtain wildcard certificates that can be renewed without human intervention, you’ll need to use a Certbot DNS plugin that’s compatible with an API supported by your DNS provider, or a script that can make appropriate DNS record changes upon demand. Even if your regular DNS provider doesn’t support a compatible update mechanism, you can use a
CNAMEdelegation for the
_acme-challengerecord in your DNS zone to a different provider that does. You can also point
_acme-challengeto an acme-dns instance.
Note that depending how you install Certbot, appropriate plugins to automate the process may not yet be available on your system.
Please see Certbot documentation for more information about your situation.
We currently have Certbot support for major Linux and BSD variant operating systems. There are a large number of other client implementations available too.
This website provides information about the level of support for various web servers and operating systems, which varies and is increasing over time. On supported systems, the automated configuration makes it fast and easy to obtain, install, and automatically renew certificates.
If automated configuration is not supported for your web server, you can still get a certificate using Certbot and configure your server software manually. In this case, the certificate will not be renewed automatically.
Note that automated configuration is not required. It can be disabled if you prefer to configure your server software yourself.
Whether root is required to run Certbot or not depends on how you intend to use it.
If you’re asking this question because you have a hosting provider that doesn’t grant you root access, you’ll need to ensure first of all that you have a way to install a certificate if you get one. If the answer is “no”, ask your hosting provider to support Let’s Encrypt (many already do). If the answer is “yes”, or you’re asking the question for security reasons, read on…
The webroot and manual plugins work well without root privileges. However, you need to provide writable paths for Certbot’s working directories either by ensuring that
/var/lib/letsencrypt/are writable, or by picking different directories with the
Certbot’s Apache and Nginx plugins normally require root both for making temporary and persistent changes to webserver configurations, and to perform graceful reload events for those servers.
certbot-autoscript works on the assumption that root privileges will be used, both in order to install OS dependencies where required and because it needs to support all of the plugins mentioned above. The packaged versions of Certbot are more flexible, and some of the teams building these packages are working toward having Cerbot run with group rather than root privileges where possible.
Yes. You can obtain a certificate for an existing CSR, which means you may generate your own CSR using your own private key. However, Certbot will not accept a private key as input and generate a CSR for you.
See this post on the Let’s Encrypt community forums.
Yes, the ACME protocol is designed to perform server validation without any downtime. You can use the webroot mode in the Certbot client, which places a validation file at a specific location on your web server, or the Apache mode, which configures a temporary self-signed certificate for validation and gracefully reloads Apache.
The Let’s Encrypt CA doesn’t publish a list of IP addresses it uses to validate, because they may change at any time. In the future, it may validate from multiple IP addresses at once.
Yes, using the DNS-01 or TLS-ALPN-01 challenge. However, Certbot does not include support for TLS-ALPN-01 yet. If you’re using any Certbot with any method other than DNS authentication, your web server must listen on port 80, or at least be capable of doing so temporarily during certificate validation.
If you have an ISP or firewall that blocks port 80 and you can’t get it unblocked, you’ll need to use DNS authentication or a different Let’s Encrypt client.