Monthly renewals

Server
1

I’ve found the --apache mode just too much trouble. It didn’t try to fix the existing conf file but added a new 000*.conf one. Now that I know the 3 (important) lines it needs to add/alter in your conf file I changed them myself and just run

#!/bin/sh

sudo service apache2 stop

/opt/letsencrypt/letsencrypt-auto certonly --standalone --email richard.nixon@example.com --agree-tos -d `hostname`

sudo service apache2 start

once to start and every month from a crontab. Hopefully this will work for renewing the certs and won’t run into any “rate limiting” problems when all the crontabs run at the same time each month.

2

So, can you specify the three lines in question?

3

Ah, assuming you already had all the ssl-enabling bits there (I had been using a cert signed by my own (untrusted) CA) the 3 lines that point at the certs and key are

    #   A self-signed (snakeoil) certificate can be created by installing
    #   the ssl-cert package. See
    #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
    #   If both key and certificate are stored in the same file, only the
    #   SSLCertificateFile directive is needed.
    SSLCertificateFile /etc/letsencrypt/live/<hostname>/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/<hostname>/privkey.pem

    #   Server Certificate Chain:
    #   Point SSLCertificateChainFile at a file containing the
    #   concatenation of PEM encoded CA certificates which form the
    #   certificate chain for the server certificate. Alternatively
    #   the referenced file can be the same as SSLCertificateFile
    #   when the CA certificates are directly appended to the server
    #   certificate for convenience.
    SSLCertificateChainFile /etc/letsencrypt/live/<hostname>/chain.pem

replacing the hostname bit with the DNS name of your server, of course.

1 Like
5

I assumed this was the answer, but it is always better when someone gives all of the details. Thank you.

6

I thought if you use “–standalone” mode it takes over 443 while it’s doing its thing.

7

In this case it is actually necessary to fully stop apache (or nginx, if nginx were used instead of apache) so that letsencrypt-auto can start its standalone server to prove domain ownership.
In the case of the --webroot variant it would only be necessary to reload apache after letsencrypt-auto has run.

@crazee Actually in your case - since you already have properly configured the SSL part of your virtualhost - you might consider using the --webroot variant, as that would only need a reload of apache afterwards.

8

Well I didn’t try playing with --webroot 'cuz the roots are in different places on different servers and I’d rather not have someone adding unknown stuff there. Some of them have nothing in / to speak of – they serve up other resources to the user-facing servers.

In any case the script I used seems to work fine for now.