0

Since a few days I'm having trouble renewing my letsencrypt.org certificate for my web server.

The documentation of letsencrypt tools might be good or bad - that's impossible to say because there's certbot, letsencrypt, certbot-auto, letsencrypt-auto, /etc/certbot which can be installed or run from the source directory or a inexisting and various subcommands which all somehow claim to do the job and then all fail with incomprehensive output with such nice variation of the ever turning wheel of nonsense feedback as:

  • Use of --agree-dev-preview is deprecated. Saving debug log to /var/log/letsencrypt/letsencrypt.log in the HEAD of the master branch of https://github.com/letsencrypt/letsencrypt - are you shipping scripts that don't work?
  • Failed authorization procedure. [hostname] (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://[hostname]/.well-known/acme-challenge/JwhGtVHZ7x6pfBztDgYL-IRQXfa1JLwhAn84Hrzi_xo: Error getting validation data - no comment needed

  • The official guide at https://certbot.eff.org/#ubuntutzesty-apache for Ubuntu 17.04 and Apache2 fails due to

    Use of --agree-dev-preview is deprecated.
Use of --agree-dev-preview is deprecated.
Too many flags setting configurators/installers/authenticators 'webroot' -> 'apache'

    which leaves me clueless of whether there's any sense in pursuing this

https://community.letsencrypt.org/t/renew-all-certificate-using-cron/21162/6 tries to explain that, but fails as anything that's no in SE format. The information is outdated and everything that's said is contradicated.

The documentation like man letsencrypt is hardly usable, at least not if you want to understand what you're doing - not mandatory, but very helpful in computer administration - it says e.g. By default, it will attempt to use a webserver both for obtaining and installing the cert - not really sure how a web server is supposed to do the steps involved...

I'm using Ubuntu 17.04.

Improve this question
1
  • 2
    Your question reads like a rant. I'd try to streamline it a little. Using certbot (from the PPA) should be enough; just call certbot renew. You should show what specific command you were trying to run and what the error message you got was. Why is “no comment needed” with regard to the second error you show? Isn't that worth investigating? Have you looked at related threads? And you say that you're having trouble renewing since a few days … has this worked before? What do you think has changed?
    – slhck
    Commented Aug 13, 2017 at 18:19

2 Answers 2

Reset to default
0

My own server runs with 

# Renew Let's Encrypt cert
0  5    * * *   root     /usr/bin/certbot renew --quiet

(this is the Ubuntu flavor of crontab). Seems to work so far. I followed the instructions at https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04 and it was straightforward.

Improve this answer
5
  • The only issue with this is that if you have a webserver running on port 443 (and hey, you have SSL certs, why not right?) you have to stop the webserver, call certbot to renew, and restart the webserver. I write a little wrapper script that does this, and then call that script from cron.
    – ivanivan
    Commented Aug 14, 2017 at 0:54
  • No you don't... from the instructions above: Because we installed our certificates using the --apache plugin, Apache will also be reloaded to ensure the new certificates are used
    – xenoid
    Commented Aug 14, 2017 at 9:05
  • I don't let letsencrypt or anything else mess with my apache config... standalone only. just wish it could be set up to use a different port for new certs, so the apache server just needs reloading instead of stopping. of course, my stuff is super low traffic, so stopping the webserver for 30 seconds is no big deal. Its just something for folks to be aware of....
    – ivanivan
    Commented Aug 14, 2017 at 12:26
  • I don't quite get it... You don't need to stop your server to get a new cert since the bot doesn't use the server for this, and once the cert is obtained all is needed is an Apache reload to take it in account. I don't see anything changed in my apache config to obtain a new cert.
    – xenoid
    Commented Aug 14, 2017 at 16:31
  • I use the certonly --standalone options - so it tries to listen on *:443. Which conflicts with the apache2 server, which means that in my use case I have to stop the apache2 server, renew my cert (or get a new one) and restart apache.
    – ivanivan
    Commented Aug 14, 2017 at 21:44
0

And the secret is: one needs to configure Apache (e.g. in /etc/apache2/apache2.conf) to allow reading the directory by adding

Alias /.well-known/acme-challenge/ /var/www/html/.well-known/acme-challenge/
<Directory "/var/www/html/.well-known/acme-challenge/">
    Options None
    AllowOverride None
    ForceType text/plain
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
</Directory>

(from https://community.letsencrypt.org/t/apache-multidomain-webroot/10663/2).

I'm not really sure why this script is associated with automation if I have to figure out all these secrets manually - this issue could have been resolved automatically or at least be pointed out by a helpful error message.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .