Let’s Encrypt is a Certificate Authority intended to be free, automated, and open.
- 1 Why
- 2 How To
- 3 IndieWeb Examples
- 4 Other Independent Examples
- 5 Renewal
- 6 Limitations
- 7 Criticism
- 8 Self Description
- 9 See Also
You should use LetsEncrypt because it's the simplest way to setup easy-to-maintain HTTPS support on your indie web site.
Set up without root access
gRegor Morrill has used https://github.com/diafygi/letsencrypt-nosudo, an interactive Python script that does not require sudo/root. The host will need to install the generated certificate for you, though. This is a good option if you do not have root access or do not want to trust the letsencrypt script with root access. Since it's an interactive process, I do not believe it can be automated.
Martijn van der Ven
Daniel Goldsmith uses LetsEncrypt on nginx for his indieweb sites:
- ViewFromAscraeus uses LetsEncrypt with Hugo (previously pelican) since Jan 2016
- Arbitary uses it with Kyle Mahan's Woodwind
Kartik Prabhu uses letsencrypt on kartikprabhu.com
Vika uses Let's Encrypt for her main site (https://fireburn.ru) via acme.sh with a customised cron script to renew certificates, but is planning to move to simp_le when she installs NixOS on her server (simp_le is integrated into NixOS).
Other Independent Examples
Template:mwunsch is using it on abstractfactory.tv
Letsencrypt certificates are valid for only 90 days. As such, it becomes important to streamline the process of renewing the certificate. If you get certbot from your distro as a package, it might already ship with cron/timer entries, but you likely will still have to adjust the renewal-hook as below.
Aaron Parecki uses the following method to renew certificates using a cron job.
Create a file,
/path/to/renew-letsencrypt.sh that includes the following. This will renew all pending certificates, and reload nginx.
/path/to/certbot-auto renew --no-self-upgrade --post-hook "/usr/local/sbin/nginx -s reload"
--no-self-upgrade flag will tell the client not to update itself, which is sometimes a long process and might require user input.
Add the following line to your crontab, which renews all soon-expiring certificates at 12:18am:
18 0 * * 0 /path/to/renew-letsencrypt.sh 2>&1
Jonny Barnes uses a systemd timer to renew certificates.
Create a service file, which will invoke the certbot client and renew expiring certificates.
[Unit] Description=Renew Let’s Encrypt leaf certificates [Service] Type=simple ExecStart=/path/to/certbot/certbot-auto renew --quiet --must-staple --post-hook 'systemctl restart nginx'
We need to run this every day, so we will set up a timer to do so. The certbot client will only renew certs that are in their last month.
[Unit] Description=Renewal of Let’s Encrypt Certs [Timer] OnCalendar=daily RandomizedDelaySec=360 Unit=certbot.service [Install] WantedBy=timers.target
Next just enable and start the timer like you would a systemd service,
sudo systemctl enable certbot.timer && sudo systemctl start certbot.timer.
Requires control over your own server
You have to have at least some control over your webserver.
Domain aliasing is not supported, e.g. if you have your own domain and use WordPress.com to serve it.
Similarly your own domain on *.github.io.
- E.g. Template:mwunsch is unable to use LetsEncrypt on his own site markwunsch.com because it is hosted on GitHub.
Short renewal intervals
A LetsEncrypt certificate is only valid for 90 days, since they aim for users to automate the renewal process as much as possible. If you can't run a LetsEncrypt client on your server (because you use shared hosting, where you only can upload certs manually) you therefore have to do a manual process more often than with CAs that give certs with longer lifespans.
On the other hand, requiring that you renew your certs every 90 days (instead of the typical 1 year) encourages people to automate the process, or at least become more familiar with the process so that it doesn't become a thing you have to re-learn every year.
Easy to misconfigure
- Consider moving this to HTTPS#Criticism, as it may be independent of Let's Encrypt.
It appears the configuration of Let's Encrypt certificates is not foolproof, by evidence of examples of sites misconfigured Let's Encrypt certs, especially by web developers. E.g.
- https://puckipedia.com/ (which forces http to redirect to https) invalid as of 2018-07-03:
puckipedia.com uses an invalid security certificate.
The certificate is only valid for dl.puckipedia.com.
Error code: SSL_ERROR_BAD_CERT_DOMAIN
From their about site:
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.
- https://httpd.apache.org/docs/trunk/mod/mod_md.html A work-in-progress Apache module (Managed Domains) to add native support for Let's Encrypt in Apache