Live folder has oldest cert being used by node.js


#1

I have no problem when navigating to my website (https works great). Auto renew is working nicely too!

But, today I started up my node.js app that uses the certificates for websocket connections and I get denied access

WebSocket network error: Unacceptable TLS certificate

In my code the letsencrypt file locations are hard coded:

    key:require('fs').readFileSync('/etc/letsencrypt/live/digitalgoodsprovider.com/privkey.pem','utf8')
,	cert:require('fs').readFileSync('/etc/letsencrypt/live/digitalgoodsprovider.com/fullchain.pem','utf8')
,	ca:require('fs').readFileSync('/etc/letsencrypt/lets-encrypt-x3-cross-signed.pem','utf8')

I went to look in /etc/letsencrypt/live and I see 3 folders

digitalgoodsprovider.com’ <----oldest creation date
’digitalgoodsprovider.com-0001’
‘digitalgoodsprovider.com-0002’ <----newest creation date

This naturally will always inevitably break my code because my code will end up pointing to an outdated bunch of certs.

Also I can imagine what would happen If I left my server running over a long period (in production), when the code first boots up It will be pointing to the correct certs but it will always point to the same ones so it will eventually become unaccessible

What is the best practice?


#2

Those -0001 and -0002 directories are generated when you change something in the list of domains contained in the certificate. Current certbot versions will ask you what to do: “expand” the current certificate or generate a new one (which will end up getting such a trailing number).

How was your certificate generated and how do you renew it?


#3

30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log


#4

     


#5

certbot made it …


#6

Obviously, but what command did you use? With which options? Did you indeed remove or add hostnames from the certificate between “‘digitalgoodsprovider.com’ <----oldest creation date” and the -0001 folders?


#7

err I did no human interaction whatsoever.

certbot has just been doing its thing for a couple of weeks


#8

Please show us “ls -l /etc/letsencrypt/live”, the contents of all of the files in /etc/letsencrypt/renewal and the command(s) you ran to issue the certificate(s) in the first place.


#9

I swapped the file names around ‘digitalgoodsprovider.com’ is now swapped with ‘_digitalgoodsprovider.com-0002’

ls -l /etc/letsencrypt/live
total 0
drwxr-xr-x 2 root root 75 Mar 5 18:09 digitalgoodsprovider.com
drwxr-xr-x 2 root root 75 Feb 14 14:08 _digitalgoodsprovider.com-0001
drwxr-xr-x 2 root root 75 Feb 14 14:15 _digitalgoodsprovider.com-0002

ls -l /etc/letsencrypt/renewal
total 12
-rw-r–r-- 1 root root 478 Feb 14 14:08 digitalgoodsprovider.com-0001.conf
-rwxr-xr-x 1 root root 478 Feb 14 14:15 digitalgoodsprovider.com-0002.conf
-rw-r–r-- 1 root root 458 Jul 29 2016 digitalgoodsprovider.com.conf

and the command(s) you ran to issue the certificate(s) in the first place … that was ages ago (i have no idea)


#10

Also… do you have the output of the “certbot renew” cron jobs saved anywhere? And what do the log files in /var/log/letsencrypt contain?


#11

In any case… Going by the record of your certificates on https://crt.sh/?q=%digitalgoodsprovider.com, you’ve issued certificates containing three different sets of hostnames. The first certificates for each are:

https://crt.sh/?id=17540866
https://crt.sh/?id=18642462
https://crt.sh/?id=58257327

That could be expected to produce 2-3 different Certbot lineages, as you apparently have.

Each of them seems to be renewed occasionally (though i haven’t checked if it’s on the expected 60 day schedule), but one of them expired yesterday:

https://crt.sh/?id=58257327

If that’s been renewed again in the last several hours it may or may not be visible yet on that website, though.


#12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.