In the mean time since my last post, things are changing in the Let’s Encrypt world - they’re officially out of beta (https://letsencrypt.org/2016/04/12/leaving-beta-new-sponsors.html) and there’s name changes (pending). Tooling has evolved as well (https://www.eff.org/deeplinks/2016/05/announcing-certbot-new-tls-robot).

That is however not the scope of this update to my original post here Let’s encrypt tls certificate in Domino. This post is about how to automatically renew your certificates.

There’s a slightly annoying thing with the certificates delivered by Let’s Encrypt: they are only valid for 3 months. So you have to renew them every 3 months.
I’ve done that manually so far, but obviously automating this is the better option. Wouldn’t it be nice if this all went automatically :-)

Update your tooling

Update your Letsencrypt client tooling to Certbot.

Get it here and follow the instructions based on your OS.
https://certbot.eff.org/

Certbot continues to use the configuration directories created earlier, so no worries there.

Check if your certificates require updating

The certbot-auto tool checks your certificates and decides if it’s necessary to update them. Note that if to run certbot to just check that your certificates require updating, it’s not necessary to stop the http server !

./certbot-auto renew  

Check the output, to see if it’s necessary to update. There’s no need to continue if the certificates don’t require updating .

Update your certificates

To actually update your certificates, you do need to stop the http server.
To renew, the http server on Domino needs to be stopped. You can do that using the pre-hook option :

./certbot-auto renew --pre-hook "su - notes -c \"/opt/ibm/domino/bin/server -c 'tell http quit'\""  

This update the certificates in your letsencrypt store.

Copy the certificates

Now copy these renewed certificates to a temporary location. I copy them because the kyrtool (running as notes user) cannot process the certificates directly from the /etc/letsencrypt/live/… location because of read rights.

cp /etc/letsencrypt/live/gwbasics.be/cert.pem /tmp/cert.pem  
cp /etc/letsencrypt/live/gwbasics.be/fullchain.pem /tmp/fullchain.pem  
cp /etc/letsencrypt/live/gwbasics.be/privkey.pem /tmp/privkey.pem

Update the certificates in the Domino keyring

Run the kyrtool command against the Keyring you configured in the Domino SSL configuration. Check the previous post about this : Let’s encrypt tls certificate in Domino

su - notes -c "/opt/ibm/domino/bin/tools/startup kyrtool =/local/notesdata/notes.ini import roots -k /local/notesdata/keyring2.kyr -i /tmp/fullchain.pem"  
su - notes -c "/opt/ibm/domino/bin/tools/startup kyrtool =/local/notesdata/notes.ini import keys -k /local/notesdata/keyring2.kyr -i /tmp/privkey.pem"  
su - notes -c "/opt/ibm/domino/bin/tools/startup kyrtool =/local/notesdata/notes.ini import certs -k /local/notesdata/keyring2.kyr -i /tmp/cert.pem"  

Remove the certificate file in tmp !

Restart the http server

Restart the http server in Domino, and the updated certificate is now available in the browser.

su - notes -c "/opt/ibm/domino/bin/server -c 'load http'"  

Note that if you use this method on a Domino server running extensions (eg. a Traveler server, a Sametime server) you likely have to restart more tasks than just http.

Here’s a sample script putting it all together.

This script is a sample you can use and adapt.

The guys at certbot recommend to check for updates 2 times a day - to cater for certificate redraws from Certbot .
I’ve scheduled it once every 2 days, using crontab.

This script relies on the certbot-auto tool to fail, when actually updating the certificate from Letsencrypt. In that case, it will stop the HTTP server running, and copy the certificates so the kyrtool can import them.

certbot-renew-public.sh

Update on chaining problems

After renewing my certificates, I ran into problems - specifically the mobile browser (on Android) did not accept the certificate anymore. Verifying the SSL configuration using SSL Labs, I was surprised to only receive a “B” .
After googling a little bit , I came to the conclusion that there’s changes in the certificate chain , and that these apparently are not reflected in the fullchain.pem.

Verification

Using SSL Lab (https://www.ssllabs.com/ssltest/ - SSL Labs provides “deep analysis of the configuration of any SSL web server on the public Internet “) you can see if you reach at least “A”.

Image:Let’s encrypt certifates for Domino Part 2 - renew certificates (UPDATED)

If you don’t have an A, most likely you run into the chaining problem I encountered : you need to have “none” chain issues , and the X3 certificate needs to be sent by server as well.

Image:Let’s encrypt certifates for Domino Part 2 - renew certificates (UPDATED)

In my case (when there were chaining issues), this complained about a missing “Let’s Encrypt Authority X3”. I’ve verified the stores, and they still used the X1 Authority.

Manually updating trusts

So… it appears to me that the fullchain.pem does not contain the correct (new) chain, or that the kyrtool does not import it correctly.
Anyway, I’ve manually updated the trusts , by downloading the new X3 and X4 certificates from here https://letsencrypt.org/certificates/.

Download the X3 and X4 certificates, to a temporary location on your server (eg. /tmp)

lets-encrypt-x3-cross-signed.pem  
lets-encrypt-x3-cross-signed.pem  

Import these into your keyring :

su - notes -c "/opt/ibm/domino/bin/tools/startup kyrtool =/local/notesdata/notes.ini import roots -k /local/notesdata/keyring2.kyr -i /tmp/lets-encrypt-x3-cross-signed.pem"  
su - notes -c "/opt/ibm/domino/bin/tools/startup kyrtool =/local/notesdata/notes.ini import roots -k /local/notesdata/keyring2.kyr -i /tmp/lets-encrypt-x4-cross-signed.pem"  

You can check the certificates and the trusted roots :

su - notes -c "/opt/ibm/domino/bin/tools/startup kyrtool =/local/notesdata/notes.ini show certs -k /local/notesdata/keyring2.kyr"  
su - notes -c "/opt/ibm/domino/bin/tools/startup kyrtool =/local/notesdata/notes.ini show roots -k /local/notesdata/keyring2.kyr"  

Restart the HTTP server, and everything is OK.

I expect that this problem will be resolved at some time in the future, so this manual steps is no longer necessary, but for now, this works.