I am responsible for running friends' website. It's using a free tool, call it T, which did a ton of configuration work for me. nginx config, for example, is managed by T. And same for SSL business, Let's Encrypt certs are managed by it. It has a bunch of cron jobs, including one for updating certs. So I kind of sold my soul to the devil ) And then it all broke.
The cert it offers to the browser is Not Before Oct 27 (18), and Not After Jan 25 (19). Exploring the config folder - which is managed by T - I've noticed this:
-rw-r----- 1 root admin 1887 Oct 27 04:43 <domain>.nginx.conf~ -rw-r--r-- 1 root root 3247 Oct 27 05:25 <domain>.key -rw-r--r-- 1 root root 1777 Oct 27 05:25 <domain>.csr -rw-r--r-- 1 root root 2053 Oct 27 05:25 <domain>.crt -rw-r--r-- 1 root root 4361 Oct 27 05:33 webalizer.<domain>.conf -rw-r----- 1 root admin 2030 Nov 17 17:37 <domain>.nginx.conf -rw-r----- 1 root root 3243 Jan 25 16:34 ssl.<domain>.key -rw-r----- 1 root root 2248 Jan 25 16:34 ssl.<domain>.crt -rw-r----- 1 root root 3896 Jan 25 16:34 ssl.<domain>.pem -rw-r----- 1 root root 1647 Jan 25 16:34 ssl.<domain>.ca drwxr-x--x 3 root root 4096 Jan 25 16:34 . -rw-r----- 1 root admin 2036 Jan 25 16:34 <domain>.nginx.ssl.conf
T has a script for renewing the SSL certs, which I ran manually when I tried to fix the situation - but it's running on the cron anyway, so obviously that wasn't the problem. But then I noticed the times: ssl..key/pem/crt files are being updated daily; the .* files of same extensions are stuck on the date when now-expired cert was created.
As nginx.conf files all this time were also managed by T, I'm obviously lacking a lot of knowledge here. I see these lines in .nginx.conf:
ssl_certificate /home/admin/conf/web/ssl.credo.press.pem; ssl_certificate_key /home/admin/conf/web/ssl.credo.press.key;
ok, so it looks like it's using the ones which are updated properly for public/private SSL keys.. but browsers see an expired cert, so something's amiss. Any ideas of what might it be?