Privacy Error but can't renew the certificate

My domain is: www.spiretrading.com

I ran this command:
certbot renew --cert-name www.spiretrading.com -a nginx

It produced this output:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Processing /etc/letsencrypt/renewal/www.spiretrading.com.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Cert not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The following certs are not due for renewal yet:

/etc/letsencrypt/live/www.spiretrading.com/fullchain.pem expires on 2020-12-26 (skipped)

No renewals were attempted.

My web server is (include version): NGINX 1.17.10

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

I can login to a root shell on my machine: Yes

I'm using a control panel to manage my site: No

The version of my client is: certbot 0.40.0

I created some certificates for our site (spiretrading.com and www.spiretrading.com) back in may and renewed back in August (if I remember correctly). For some reason I realized that the certificate for www.spiretrading.com is actually not working. I am getting a NET::ERR_CERT_DATE_INVALID however, when I try to renew the certificate certbot tells me that the it is not due.

I honestly don't know what happened. Any clues?

2 Likes

Welcome Back to the Let's Encrypt Community, Author :slightly_smiling_face:

Please try this:

sudo systemctl reload nginx
3 Likes

Your "base" domain name spiretrading.com is using the correct certificate. However, your www subdomain www.spiretrading.com isn't using the renewed certificate.

Personally, I would have put both hostnames in the same certificate. There really isn't a very good reason not to do this with these hostnames.

I see you're putting -a nginx on the command line. How did you install the certificate(s) when you got them the first time? Did you use the nginx installer? Or did you (need to) install them manually? If it's the latter, you might have to reload nginx as @griffin pointed out.

In any case, I think you should put both hostnames in the same certificate. If everybody would use two certs for these two hostnames, Let's Encrypt would have quite a bigger load on their systems.

4 Likes

Thanks @griffin! And I feel kinda stupid now, because reloading actually fixed this. Man, I was reading the logs, and checking different browsers and trying to remember how I installed the certificate in the first place.. Well, always learning I guess.
@Osiris your suggestion sounds good! I installed the certificates manually, I am by no means a specialist, would you like to point out how I can do this?

3 Likes

You can just specify multiple hostnames on the command line with -d, either use a comma separated list (but I've never used that) or specify -d multiple times, once per hostname.

4 Likes

@Osiris

That's a great observation, Osiris! :star2:


@arthurlucena

Perhaps try the following to straighten things out:
certbot --cert-name www.spiretrading.com --nginx -d "www.spiretrading.com,spiretrading.com"

You can view your certificates with certbot certificates and note their names.

You can use the following to delete any unneeded certificates:
certbot delete --cert-name name


Complete Certificate History

3 Likes

All good, guys! I updated the certificate to cover for www and non-www as suggested and deleted the other one. Thanks both @Osiris and @griffin! You two saved my day.

3 Likes

You also have reload your nginx! You're a quick learner :wink:

4 Likes

@Osiris

The command I gave him fixed the reload permanently. :wink:

@arthurlucena

I checked your redirects too and they look fantastic!

You were intending to use spiretrading.com and not www.spiretrading.com, right?

:stars:

2 Likes

Actually :smiley: it seems like I did something wrong.

I tried to reload NGINX but I got an error. Checking the log I see this:
nginx[4086225]: nginx: [emerg] SSL_CTX_load_verify_locations("/etc/letsencrypt/live/spiretrading.com/chain.pem") failed (SSL: error:02001002:system library:fopen:No such file >

Assuming that it was something with the .conf file, since I deleted the duplicated certificate, right?
This is how it looks like:

#Redirect HTTP -> HTTPS
server {
if ($host = spiretrading.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot


if ($host = www.spiretrading.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot


listen 80;
server_name www.spiretrading.com spiretrading.com;

include snippets/letsencrypt.conf;
return 301 https://spiretrading.com$request_uri;

}

#Redirect WWW -> NON WWW
server {
listen 443 ssl http2;
server_name www.spiretrading.com;
ssl_certificate /etc/letsencrypt/live/www.spiretrading.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.spiretrading.com/privkey.pem; # managed by Certbot
ssl_trusted_certificate /etc/letsencrypt/live/www.spiretrading.com/chain.pem;
include snippets/ssl.conf;

return 301 https://spiretrading.com$request_uri;

}

server {
listen 443 ssl http2;
server_name spiretrading.com;

root /var/www/spiretrading.com;
index index.php;

#SSL parameters
ssl_certificate /etc/letsencrypt/live/www.spiretrading.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.spiretrading.com/privkey.pem; # managed by Certbot
ssl_trusted_certificate /etc/letsencrypt/live/spiretrading.com/chain.pem;
include snippets/ssl.conf;
include snippets/letsencrypt.conf;

   #here comes the rest of the file, omitted from this post

It's been a looong time since I touched this file. But taking the context here (updated the certificate and deleted the other one) how can I reflect the changes I did in this file as well? (assuming this is the problem that prevented me from reload NGINX)

2 Likes

Did you use the command I gave you?

There are some definite fixes needed here... :thinking:

I'll look into this once I'm back from lunch.

3 Likes

You mean the

certbot --cert-name www.spiretrading.com --nginx -d "www.spiretrading.com,spiretrading.com"

command? Yes, I used and it worked flawlessly.
But I feel I have to update this conf file as well. I created it back in April/May and have not touched since, so I'm a bit rusted. I remember I had to make the non-www version the "main" one and the www a redirect. But I think the changes in the certificate is the opposite, right?

3 Likes

Which do you want to use?

The certbot changes are conflicting with your own. We'll help you get things straightened out.

3 Likes

You have a mention of ssl_trusted_certificate which wasn't automatically updated by certbot.

4 Likes

I think the non-www version looks more elegant. But either one is fine, by me.

2 Likes

That's what we'll go with. :slightly_smiling_face:

3 Likes

@Osiris yes! I changed that line to point to www.spiretrading.com and no errors this time - wohoo \o/
@griffin feel free to suggest changes on this file! I'm always down to make improvements.

4 Likes

I left for food and missed the party? :flushed:

Back in a few. Coffee required.

If you're around @arthurlucena, can you show me the:

  • output of nginx -T
  • contents of snippets/ssl.conf
  • contents of snippets/letsencrypt.conf
3 Likes

Hey @griffin!

Here:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful 

(the rest of the output is basically all the .conf files I have on this server, should I paste it here?)

Here's the content for ssl.conf:

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

ssl_protocols TLSv1.2;
ssl_ciphers EECDH+AESGCM:EECDH+AES;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload";
#add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

and letsencrypt.conf

location ^~ /.well-known/acme-challenge/ {
	default_type "text/plain";
	root /var/www/letsencrypt;
}
3 Likes

Thanks for that! :slightly_smiling_face:

I should have had you run sudo nginx -T instead.

The goals of looking at sudo nginx -T are to:

  • confirm which configuration files are actually being used
  • determine which other configuration files need to be enumerated, if any

If you are confident that what you've already presented is all that is applicable, we can proceed.

3 Likes