Cert shows as active, is treated as if expired

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:
I ran this command:
certbot certificates
It produced this output:
Found the following certs:
Certificate Name: paulbeard.org
Domains: paulbeard.org cloud.paulbeard.org www.paulbeard.org
Expiry Date: 2019-08-30 18:09:07+00:00 (VALID: 89 days)
My web server is (include version):

The operating system my web server runs on is (include version):
FreeBSD 11.3
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

certbot 0.34.2

openssl and my browser say
Verify return code: 10 (certificate has expired)

Also, certbot no longer edits nginx.conf to include the certs.

Hi @paulbeard

you have created some certificates: 5 identical with three domain names, one with only one domain name ( https://check-your-website.server-daten.de/?q=paulbeard.org#ct-logs ):

CertSpotter-Id Issuer not before not after Domain names LE-Duplicate next LE
943939145 CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US 2019-06-01 20:03:03 2019-08-30 20:03:03 paulbeard.org - 1 entries duplicate nr. 1
943810875 CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US 2019-06-01 18:09:07 2019-08-30 18:09:07 cloud.paulbeard.org, paulbeard.org, www.paulbeard.org - 3 entries duplicate nr. 5 next Letsencrypt certificate: 2019-06-08 01:02:57
943808736 CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US 2019-06-01 18:07:16 2019-08-30 18:07:16 cloud.paulbeard.org, paulbeard.org, www.paulbeard.org - 3 entries duplicate nr. 4
943807110 CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US 2019-06-01 18:05:52 2019-08-30 18:05:52 cloud.paulbeard.org, paulbeard.org, www.paulbeard.org - 3 entries duplicate nr. 3
943780695 CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US 2019-06-01 17:42:22 2019-08-30 17:42:22 cloud.paulbeard.org, paulbeard.org, www.paulbeard.org - 3 entries duplicate nr. 2
943535248 CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US 2019-06-01 01:02:57 2019-08-30 01:02:57 cloud.paulbeard.org, paulbeard.org, www.paulbeard.org - 3 entries duplicate nr. 1

But both connections use the certificate with one domain name:

expires in 89 days	paulbeard.org - 1 entry

The result: Your www version isn’t secure.

Domainname Http-Status redirect Sec. G
http://paulbeard.org/ 301 https://paulbeard.org/ 0.620 A
http://www.paulbeard.org/ 301 https://www.paulbeard.org/ 0.506 A
http://www.paulbeard.org/ 301 https://www.paulbeard.org/ 0.413 A
https://paulbeard.org/ 200 14.720 I
https://www.paulbeard.org/ 200 3.393 N
Certificate error: RemoteCertificateNameMismatch

So find the vHost with these three domains and change the Certificate informations.

Or try

certbot --reinstall -d paulbeard.org -d www.paulbeard.org -d cloud.paulbeard.org

Certbot should find the newest certificate and should install it.

Perhaps you have a wrong vHost configuration (duplicated entries). Then that may not work.

1 Like

This seems to be a problem…

There were too many requests of a given type :: Error creating new order :: too many certificates already issued for exact set of domains: cloud.paulbeard.org,paulbeard.org,www.paulbeard.org: see https://letsencrypt.org/docs/rate-limits/

No, this isn’t a problem. You have already created the certificate. But you don’t use it.

So your configuration is buggy, you have to fix it. Creating new certificates with a buggy configuration doesn’t help.

1 Like

That makes sense. But how to get it installed again? It was installed in my nginx.conf but I removed it when it wasn’t working properly (I have a lot of other issues going on that need resolving). Now it doesn’t install with certbot as it once did.

I should revoke all the existing ones and start over but that hasn’t worked so far.

Revocation doesn’t reset the limit and doesn’t fix anything. Please read

What says

nginx -T
certbot certificates

I didn’t expect it to reset the limit. What I do expect is for it to wipe out any superflous/extraneous cruft.

nginx T fails because there are no certs. Likewise certbot confirms that.

certbot certificates

Saving debug log to /var/log/letsencrypt/letsencrypt.log

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

No certs found.

The question now is how to get a cert and install it. This used to be pretty simple.

There is your certificate. If you have deleted it, you have to wait.

1 Like

the meta question is why I even have a webserver/domain…I guess I’ll ponder that while I wait. Not sure how long the wait is…seems odd that one domain’s certs would trigger the Certificates per Registered Domain (50 per week) limit. But whatever.

It’s triggering the Duplicate Certificate rate limit.

You could create 50 certificates for new combinations of (sub)domains.


How can I have a duplicate of a revoked/deleted certificate? I want to start over from scratch, as if I had never had a certificate before. I want all old files and dangling dependencies wiped clean. Is there no way to do that? If so, what needs to be done?

The rate limits are a measurement, by the CA, of certificates issued. Let’s Encrypt doesn’t know whether or not you’ve deleted your files. And revocation isn’t a factor, because a certificate costs the CA a similar amount of resources whether or not it’s revoked.

1 Like

So revocation is not really a thing. It’s just local deletion with no propagation to the CA that says “hey, this site has revoked this cert, let’s mark it as deleted/untrusted.”

No, revocation is something with the CA, and it does indicate that the certificate is untrusted (for clients that check OCSP). It just isn’t part of how Let’s Encrypt calculates rate limits.

1 Like

This was something I didn’t expect:

listen [::]:443 ssl ipv6only=on; # managed by Certbot

I have been OK with the config file edits by Certbot but I’m not sure about this.

I decided to simply shut down the server that is affected by all of this. Evidently, I no longer have the capacity to manage all of this…stuff as I used to. A lot can happen in 24 hours, apparently. 24 hours ago, everything was working. Now, not so much. Since I have no idea when I can get a certificate installed and working, with or without surprises, maybe it’s best to close up shop.

How can you actually lose certificates that were issued ? certbot saves them all.
You have a valid certificate:
you can get it back from /etc/letsencrypt/archive/ and install it again until the limit rate is no longer blocking you.

1 Like

That doesn't help if the certificate (and the private key) is deleted.

First Post:


If the private key is deleted, the download of the public certificate part doesn't help.

Never delete files if you don't have a backup.

1 Like

Agreed, but the private keys are saved in the archive, why whould anyone dig in the archive to delete files ? Most people don’t even know that certificate files are archived.

Edit: double checking: oh. I never noticed that the ‘live’ files are symlinked to the archive, not duplicated. That’s not great.


my best option seems to be to start over with the most basic nginx config and add back all the customizations til it breaks again. Right now browsers are saying I have certificates but that they are wrong. Not sure how that works. In future I will mak a timestamped copy of my configs so that I can recover from certbot edits that go wrong.

This seems conflicted: “you don’t have what you asked for but congratulations for it all the same.”

- Unable to install the certificate
Congratulations! Your certificate and chain have been saved at:
Your key file has been saved at:
Your cert will expire on 2019-08-31. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the “certonly” option. To non-interactively renew all of
your certificates, run “certbot renew”

The files exist, symlinks and all.

nginx -t

nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok

nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful