Finally I found some time to set up a Let’s Encrypt certificate for this server.
It's damn easy, even if you dislike Let’s Encrypts Apache auto configuration or web server downtimes.
To prevent Let’s Encrypt to mess with any of our configuration we will only run it in
Let’s Encrypts validates with so called acme-challenges that the server requesting a certificate is also legitimate to do so.
Let's say you request a certificate for
Let’s Encrypts will look at
http://example.com/.well-known/acme-challenge/ for a valid acme-response.
So either Let’s Encrypts modifies your current configuration or starts its own Http server (and therefore you have to stop yours) to reply to the challenge. bad
Luckily it comes with a third way to reply to the challenges.
webroot mode you can specify a path where the acme-challenge should be placed and therefore allows you to use your default web server (In my case Apache).
The command letsencrypt-auto certonly --webroot -w /var/www/letsencrypt -d example.com request a new certificate for
example.com and will place the challenges in
Now we only have to tell our web server to serve request for
For Apache web servers this can be easily done by adding a
letsencrypt.conf file to
/etc/apache2/conf-enabled/ with following content:
1 2 3
<IfModule mod_alias.c> Alias /.well-known/acme-challenge /var/www/letsencrypt/.well-known/acme-challenge </IfModule>
The advantage of such a global alias is, that even if you have multiple (sub-)domains the response to the acme-challenge will work.
Also if your (sub-)domain comes already with an own
/.well-known/ folder (like e.g. owncloud), this will not break their set up (since we only aliased the
PS: Use the staging environment for testing (include --staging) so you don't run into rate limits while testing. This happened to me and now I have to wait a week before I can finally roll out the new certificate.