Mixed Inputs Regarding SSL Cert Expiry Date
Hello All,
So a couple of days ago I got the 'red screen of shame' when trying to visit my site. The message was the security certificate expired 12 days ago.
So I checked through ssl checker and got a more detailed input. There was a cert expiration message and the None of the common names in the certificate match the name that was entered message.
I logged into the server and checked the cert status with
sudo certbot certificates and it said (VALID: 48 days).
It passed the auto updater test and when I tried to use ./letsencrypt-auto renew I got Cert not yet due for renewal. So I did a force renewal with sudo certbot renew --force-renewal and got the Congratulations, all renewals succeeded.
Checking the cert again showed Expiry date changed from 40 days to 89 days so I know the cert got updated. Yet SSL Checker still shows the same unrelated expiry date with the server Valid from May 1, 2018 to July 30, 2018 input and the browser still blocks the site and says the cert expired.
I don't understand why I see the cert is valid and has not expired but outside of the server there is a different expiry date which is not auto updated?
Thanks
2 Replies
Two possibilities come to mind:
- You need to restart the webserver. The webserver may have the old certificate loaded into memory, even though the actual certificate file has been changed out by certbot. Not sure what you're running but it could be any of:
systemctl restart nginx
service nginx restart
systemctl restart apache2
service apache2 restart
Newer certbot versions also have flags to restart services if a certificate was renewed successfully. For newer certbot versions the syntax is --deploy-hook "systemctl restart nginx" and older versions it's --renew-hook "systemctl restart nginx". You can take these and turn it into a cron job to help avoid this problem in the future.
- Your webserver vhost configuration is somehow loading the wrong certificate. If this message from sslchecker is correct, then the domain name that the presented certificate is signed for is not correct:
"None of the common names in the certificate match the name that was entered"
"Common Names" is SSL-speak for your domain name, such as www.example.com or example.com. The most common cause for this type of problem I've seen is that the webserver was using a default "bogus" SSL certificate, which it will provide when SSL certificate directive is missing or not parsed in the vhost configuration.
Double check the SSL certificate path and key you have set in your webserver vhost configuration to confirm.
Lastly if you'd like to consider expert assistance with this task or any other projects, you could hire the Linode Professional Services team, of which I'm a member. We can be reached by hitting the "Get a Quote" button here:
Thanks so much,
You helped me solve the problem and here's how I did it (in case anyone else reads this thread).
It seems it was the second problem you've indicated. And editing the /etc/nginx/nginx.conf file and adding the server block the following lines:
ssl_certificate /etc/letsencrypt/live/my-domain/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/my-domain/privkey.pem;
Solved it.
p.s make sure you are adding this to the right server block the
listen 443 ssl one.