Apache & Nginx SSL ongoing maintenance

This is not the end ...

Some on-going work you can automate, some you need to work at yourself.

Certificate renewal

The Let's Encrypt certificates are only valid for 90 days, you should look to renew what you have after 60 days.

The script RenewCertificates you can run via cron, there is a sample crontab in Renewal.crontab that you should arrange to be run by the user acme.

Put the list of certificate families into Renewals.list, update that list as you create new families. A name will be something like EXAMPLE or my-family ‐ do NOT put the .cnf suffix.

Note that all of the scripts can take the --list option.

Apache & Nginx will not notice the new certificates unless you restart it or reload the configuration. You need to arrange for this. I restart my Apache servers once/week ‐ which takes care of this.
The script ScriptToRestartWebServer can help with this.

Ensure that email for the user acme is forwarded somewhere where it will be read — otherwise any errors will not be noticed.

It can be hard to see what RenewCertificates is doing as it is run from cron:

• Create TRACEFILE into which errors will be appended. This must be writable by the user acme.
• Create VERBOSE for more chatty messages into TRACEFILE and also stderr (which is emailed).

Forcing Certificate renewal

RenewCertificates will not renew a certificate if it is less than 60 days old.

You can make it renew (in unusual circumstances) with a --force option, eg:

      $ bin/RenewCertificates --force --list Renewals
      

Let's Encrypt Chaining Certificate expiry

At the time of writing the cross signing, or chaining, certificate in lets-encrypt-x3-cross-signed.pem is due to expire in March 2021. After this it will need to be replaced; unless Let's Encrypt have managed to get their certificate installed into every TLS setup world wide.

The script RenewCertificates will generate a warning when this certificate has less than 90 days before it expires. At which point you will need to do something — as yet unknown.

Security related configuration changes

This is much harder.

The problem is that vulnerabilities can be found in configurations and code that was previously considered save & good practice. Eg a cypher might be found to be insecure.

• It is important that you keep your system updated; when you see a new ssl.conf installed (maybe as ssl.conf.rpmnew), compare with what you have and update appropriately. diff is great for this if your current file is not too far changed — which is why I suggested that you ''comment'' out lines with <IfModule ....

• Look at the Mozilla configuration generator

Miscellaneous

• You can check any web site's certificate with the script ShowSSLinfo, eg:

  $ sh bin/ShowSSLinfo www.phcomp.co.uk

  If you want to see everything, use the -v option, eg:

  $ sh bin/ShowSSLinfo -v www.phcomp.co.uk

• curl is another useful tool:

  $ curl -v https://www.phcomp.co.uk/

• Web browsers usually show something if you click on the green padlock.
• You can view the contents of a certificate file like this:

  $ openssl x509 -text -noout -in SignedCertificates/phcl.crt

  or

  $ sh bin/ShowSSLinfo --family phcl

• You can view the contents of all certificate files like this:

  $ sh bin/ShowSSLinfo --all-families

Next page: Chaining Let's Encrypt certificates

Return to How to Configure Let's Encrypt with acme_tiny.py