Incorrect email notification of cert expiration

My domain is: activedecisionsupport.com

The certificate being used is current, as verified in crt.sh and “view certificate” of the browser:

image

But since I renewed it on Sep 14, I’ve received two emails indicating expiration of *.activedecisionsupport.com (“will expire in 9 days (on 28 Sep 20 22:20 +0000)”). Both the certificate and the crt.sh output above indicate both the main domain and the wildcard.

This domain is still relatively new to letsencrypt, and I had done some troubleshooting on the first cert generation, so I wonder if it’s possible that I have effectively-duplicate certs? One that I recently acquired (I did certbot renew, but my bash history doesn’t have it … I must have led with a space accidentally)

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

If it helps with anything, my /etc/letsencrypt/accounts contains two accounts:

./acme-v02.api.letsencrypt.org/directory/ed.../{meta.json,...}
./acme-staging-v02.api.letsencrypt.org/directory/ee.../{meta.json,...}

I thought that that was fine, with a different account on the staging/test server, but perhaps I’m mistaken.

This is related to

but neither seems right.

Thank you.

2 Likes

Welcome to the Let’s Encrypt Community :slightly_smiling_face:

Based on https://crt.sh/?q=activedecisionsupport.com

I can clearly see that the email refers to an older certificate (below the ones you’ve shown).

The second account is for the staging (testing) environment.

You can view your certificates using:
sudo certbot certificates

1 Like

You have a cert for just your wildcard hostname issued earlier. I guess this was a faulty cert, as it doesn’t include the “bare” domain name, like the certs issued after it.

However, LE doesn’t know you don’t use it any longer (I assume) and as this specific set of hostnames hasn’t been renewed, you’re getting a warning.

3 Likes

That’s what I suspected, but I’m not (yet) proficient enough to distinguish the details in the list. That helps me recognize now what that entry is (as well as 3021538125). Thank you, griffin and Osiris!

(FYI, certbot certificates confirmed what I “knew”, that my current certificates were valid. It did not help me to identify which certificate(s) the email was referencing.)

3 Likes

How many certificates were issued that match that specific expiration date?

2 Likes

Four, some of which look valid.


I didn’t assume that I should be comparing the email with the “Common name” or the “Matching identities” components in the output from crt.sh, so it seemed reasonable to suspect that I was missing something. I’m deducing from Osiris’ comment that a test-certificate (that I thought was on staging, but apparently not) was what is triggering the notifications.

Am I missing something else, @rg305?

2 Likes

The minute hand on your watch.
The first two (are identical) and are 18 minutes off.
The second two (are identical) and match the time shown on the email.

I will admit that putting more information on the email will be helpful.
But the notice is true and accurate nonetheless.

2 Likes

The reason I had you view your certificates with certbot was to see if you had any duplicate certificate entries that might generate unnecessary certificates at renewal.

You’re mostly right about that. You need to look at the Common Name (CN) and Subject Alternative Names (SANs) in the certificate itself. Usually the CN is a SAN.

Test certificates (from staging) are not logged on crt.sh. The pairs of certificates consist of a poisoned precertificate (bottom) and the real certificate (top).

2 Likes

@griffin thanks, that’s very helpful. I was initially comparing the email with the crt.sh front page, now I see I need to look deeper for the SAN. Great information!

3 Likes

I had to learn that one the hard way myself. @Osiris beat that one into me good. :wink:

This is ESPECIALLY important when the certificate includes domains unrelated to your search, as is often the case with Cloudflare certificates and such that conglomerate unrelated domains from completely different owners.

2 Likes

(FYI, in case there’s confusion, I created this new account and swapped the “username” and “name” fields in my head, having just a random string for login uid purposes … “9Z2K28FBNQYErsjpX5rN” is not a readable username, but I thought my “Name” would be displayed instead. Allow me to introduce myself, “r2evans”. :slight_smile: )

3 Likes

Nice to meet you, Bill. :slightly_smiling_face:

Before I forget, and you probably already realized this, for your benefit try not to generate a bunch of identical certificates (same domains, but public keys likely vary). You can run up against the rate limits. If anything were to happen to your certificates and private keys, this can give you a royal headache. If you’re testing getting certificates, you can add --dry-run to use the staging environment, which has much higher limits, does not save the “fake” certificates it generates, and won’t limit your ability to get a real certificate later.

2 Likes

Where’s the anonymity in that ? - LOL

2 Likes

@rg305

Maybe his real name is Serge? We all know your real name is Relentless MacGyver.

2 Likes

Or Diana, nobody on the internet knows :wink:

3 Likes

Oh no!
Time to move again - dang witness protection…

2 Likes

That’s why I shifted between “real” and “staging/temp”, because in testing I hit a rate-limit or two. This is oddly not my first domain with LE, but it’s the first where I went wildcard and did anything non-trivial. Thanks.

2 Likes

As I said before, it’s not paranoia if they really are after you… :scream:

1 Like

Hey!
Only paranoid will survive!!
You will see!!!

[or maybe you won’t]

2 Likes

I thought you might have. Most people who have generated 5 certificates in 1 day have tried to generate 6 certificates. I’m sure Rudy noticed this too and didn’t club you for it. Some people here will. Hard. I speak of the juggernaut…

2 Likes