Cert date invalid after changing to webroot method

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
azabot.stream

I ran this command:
certbot certonly --webroot -w /var/www/html -d azabot.stream
After that I ran certbot and selected to replace the existing cert.

It produced this output:
all commands said they were successful
certbot certificates tells me:
Certificate Name: azabot.stream
Domains: azabot.stream
Expirary Date: 2019-06-22 13:40:05
Certificate Path: /etc/letsencrypt/live/azabot.stream/fullchain.pem
Private Key Path: /etc/letsencrypt/live/azabot.stream/privkey.pem

My web server is (include version):
apache/2.4.18 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 16.04.5 LTS

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):
yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
0.28.0

When I go to my site now I am getting NET::ERR_CERT_DATE_INVALID.
According to ssllabs everything looks good (I think?). I am not sure what I broke, but before I burn it all to the ground and start over I thought I would ask here what I might be missing.

Hi @azazael

looks all good. Ssllabs shows a Grade A ( SSL Server Test: azabot.stream (Powered by Qualys SSL Labs) ), my own tool has the (relevant) Grade B ( https://check-your-website.server-daten.de/?q=azabot.stream ).

Your www version goes (CNAME) to parkingpage.namecheap.com, looks like a firewall.

Your new Letsencrypt certificate is valid, no chain errors:

CN=azabot.stream
	25.03.2019
	23.06.2019
expires in 90 days	azabot.stream - 1 entry

The only thing: You don't have a redirect http -> https.

So your error

looks like a caching problem of your browser.

Perhaps remove the CNAME to that parking page and create one certificate with both domain names, then add a redirect www -> non-www.

So I removed the CNAME that was there and added one for www.azabot.stream, I told it to redirect all www calls to the same call without www, and on the server I told it to redirect all traffic to https://

I now can browse to the https://azabot.stream and see it is fine, but as soon as I put a port number behind it (used for communications to another website) I get the expired cert error. I am going to just chalk that up to a bad cached cert somewhere (I get it across all browsers). My thought is that since it works with no port it is fine, right? Do I (or should I) still need to make a cert for www.azabot.stream?

If you want to use the same certificate with non-standard ports, you have to configure these vHosts. So these vHosts use the certificate, not the standard certificate.

Or you change your standard port 443 vHost, so this vHost uses the certificate.

If you have a www dns entry, your server should answer (port 80 and 443), so you need a certificate. And it's a little bit country-specific. Some users add never www, some users add www every time. A server should handle all these situations correct -> one certificate with both domain names, then a redirect to the preferred version.

Is this something different with webroot or the new TLS? Before the big change I didn't have to worry about that (at least I don't think I did). The port i use is specific to a secondary process and can't easily be changed. I will look into vHosts tomorrow morning I guess. Thanks.

No, it's only your server configuration.

But if you have something like

ServerName azabot.stream
ServerAlias www.azabot.stream

it's easy for Certbot to find your correct vHost.

So the default vHost is unchanged -> the certificate works only with that specific vHost.

But you can change it.

There are rows like

SSLCertificateFile /etc/ssl/certs/apache.crt
SSLCertificateKeyFile /etc/ssl/private/apache.key

in your vHost. Copy these to your default host.

Incase anyone else stumbles across this problem and needs help, a lot of what was said here was good advice. Ultimately my problem was that the port I was trying to hit was being hosted by a node.js program. I hadn’t restarted the program since I redid the cert. I tried again tonight to go to the site, and had the same issue as before. After restarting my node.js program the site works perfectly fine now.

Thank you all for the help.

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