Subdomain - The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED)

[GoWilkes]

I'm having an unexpected SSL error that's apparently been going on for awhile, but I just now saw it. This is from AutoSSL, using the default Sectigo.

I have one domain and the cert is renewing properly. It has several subdomains, though, and some are renewing while some are not.

These renewed:
images.example.co
ww2.example.co

These did not:
i.example.co
inc.example.co

I also have example.net parked on top of example.co, and i.example.net and inc.example.net both renewed just fine. So the problem doesn't appear to be with the subdomain name itself.

The error message for both is the same:

10:23:21 PM ERROR TLS Status: Defective
ERROR Certificate expiry: 5/1/22, 8:37 PM UTC (88.24 days ago)
ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED).

No other domains are in the pending queue, either, so it's not an issue of having too many domains. Especially since these appear to have been failing for almost 3 months :-O

Any thoughts or suggestions?

 

[andrew.n]

It already has an SSL which is expired and was not issues by AutoSSL. Under Options (if I recall the name) you can select renew expired certificates issues by 3rd party in WHM in AutoSSL or under Manage SSL Hosts you can simply remove the expired certificate and then AutoSSL will install a new one correctly.

 

[GoWilkes]

But... it WAS issued by AutoSSL! I double checked, the registration was for R3 - Let's Encrypt.

I changed the setting under AutoSSL > Options to Allow AutoSSL to replace invalid or expiring non-AutoSSL certificates, but it still didn't renew. Then I deleted i.example.co under Manage SSL Hosts and after a few hours it finally renewed.

I have a verbose warning for inc.example.co, though, which I didn't delete. I'm not going to post the whole thing unless you want, but it starts with:

6:17:05 AM WARN The system failed to set up for Sectigo’s DCV (Domain Control Validation) for the certificate request for “example”’s website “inc.example.co” because of an error: Cpanel::Exception/(XID rsubj4) Can't use an undefined value as a subroutine reference at /usr/local/cpanel/Cpanel/CommandQueue.pm line 188. at /usr/local/cpanel/Cpanel/Rollback.pm line 155. Cpanel::Rollback::rollback(Cpanel::Rollback=ARRAY(0x2e35560), "Can't use an undefined value as a subroutine reference at /us"...) called at /usr/local/cpanel/Cpanel/CommandQueue.pm line 200

I'll delete the cert for that one tonight and see if it renews, I suspect that it will, but the warning makes me think that the problem is with a bug somewhere in the software.

 

[GoWilkes]

I spoke too soon... AutoSSL shows that the cert is there and valid, but browsers are still throwing an error that it's not secure. The certificate is issued and says it expires on 8/21/2022, but I see that the cert is issued to exampleinc.com (another domain I use) instead of example.co.

Looking at the DNS records for example.co, I have a ton of CNAME entries that make no sense:

_e4f159e2877da4fdead9e19623d7369b.i.example.co. 14400 CNAME 5ff2546f83098ae65493e83affa0bcce.6b0cf746245848bc87465cf58d838955.comodoca.com

There are over 90 of these, all with different random characters before the subdomain.

inc.example.co also has over 100 of these CNAME entries.

I have another subdomain of images.example.co that is identical to i.example.co; that subdomain works fine, and doesn't have any of these CNAME records. At least 4 years ago I used cPanel to create the subdomains i.example.co, i.example.net, and images.example.co all with a document root of /public_html/images; I haven't changed anything on my end since then.

What the heck is going on?

 

[GoWilkes]

Update: not only is it no better by 2am, now I see that i.example.co doesn't show up under Manage SSL Hosts anymore so I can't delete it and retry :-/ It's not listed under SSL Storage Manager, either.

There's nothing in the Pending Queue under Manage AutoSSL, so AutoSSL seems to think that it's all good.

 

[mtindor]

What happens if you WHM --> Manage AutoSSL --> Manager Users --> click "Check <User>" next to that particular user.

Normally it will run autossl again, just for that user, and generate a completely separate logfile just for that. You'll be able to go to Manage SSL --> Logs when it is done and see what's happening.

 

[GoWilkes]

Tried that, and the log first has a warning:

WARN Local HTTP DCV error (www.i.example.co): “www.i.example.co” does not resolve to any IP addresses on the internet.
WARN Local HTTP DCV error (www.inc.example.co): “www.inc.example.co” does not resolve to any IP addresses on the internet.

That's a weird one, because the warning is only written with the www in place. And I mentioned before that all of the subdomains for example.net (parked on top of example.co) renew just fine, so I don't think it's an Apache setting on my end. It COULD be, since I have a ton of custom Apache configuration... but I don't know how it could affect the .CO and not the parked .NET.

Anyway.

The last section of the log says:

12:24:31 AM Processing “exampleco”’s local DCV results …
12:24:31 AM Local DNS DCV OK: www.i.example.co (via example.co)
Local DNS DCV OK: www.inc.example.co (via example.co)
Analyzing “i.example.co”’s DCV results …
12:24:31 AM AutoSSL will request a new certificate.
12:24:31 AM Analyzing “inc.example.co”’s DCV results …
12:24:31 AM AutoSSL will request a new certificate.
12:24:31 AM The system will attempt to renew the SSL certificates for (i.example.co: i.example.co www.i.example.co) and (inc.example.co: inc.example.co www.inc.example.co).
12:24:33 AM The “cPanel (powered by Sectigo)” provider cannot currently accept incoming requests. The system will try again later.
12:24:35 AM The “cPanel (powered by Sectigo)” provider cannot currently accept incoming requests. The system will try again later.
The system has completed “exampleco”’s AutoSSL check.

It's 1:10am now, so that was about 45 minutes ago. I guess I'll just have to wait until tomorrow.

 

[mtindor]

Tried that, and the log first has a warning:

WARN Local HTTP DCV error (www.i.example.co): “www.i.example.co” does not resolve to any IP addresses on the internet.
WARN Local HTTP DCV error (www.inc.example.co): “www.inc.example.co” does not resolve to any IP addresses on the internet.

This seems self-explanatory. Are you using the hosting servers nameservers in /etc/resolv.conf or are you using external resolvers (like Google's, etc)? AutoSSL is going to be querying whatever nameservers you have listed in /etc/resolv.conf.

I'm suspecting that even though you have these domains installed locally on your cpanel, the authoritative nameservers for these domains may not be your nameservers but some external nameservers. And if that is the case, you need to make sure to add the appropriate A-records for those hostnames in the DNS Zone(s) on the authoritative nameserver(s).

Mike

 

[cPRex]

You're always welcome to make a ticket for these issues as well!

 

[andrew.n]

@GoWilkes: Submitting a ticket might be the best way to figure this out as cPRex mentioned

 

[GoWilkes]

@mtindor, /etc/resolv.conf only has 2 lines, for my server's nameservers. Both appear correct, and the last modified date was March 19. Since this issue began in May, it doesn't appear to have anything to do with that file.

I suspect that the 90+ CNAMEs in my DNS are at least part of this issue.

It's 1:30pm now. There's nothing new in the log files since 12:24am, and there's still no cert, so I have to assume it's not going to install.

I guess I'll create a ticket, but I was really hoping to have it solved publicly in case it's happening to others. Before posting I found several other people having similar problems in the past that were resolved after submitting a ticket, but no resolutions were ever posted on what was actually done :-/

 

[cPRex]

Post the ticket number so I can follow along and I'll be sure to post the resolution.

 

[GoWilkes]

Just now submitted, ticket # 94471050

 

[cPRex]

Thanks for that - I'm following along with that ticket on my end now.

 

[jazee]

I just had the same issue. I just happened to visit a website on my server and the cert was 5 days expired! I did a manual AutoSSL check on the account and also contacted Cpanel support. It renewed about 15 minutes after the manual check. Cpanel support sent me this link:

AutoSSL Runs not Completing - cPanel (powered by Sectigo) cannot currently accept incoming requests

My response was:

The article you linked to said to just wait for Sectigo to fix the issue. The certificate expired 5+ days ago. Don't you think over 5 days is long enough for them to fix the issue? Doesn't AutoSSL attempt to renew the cert once a day automatically? If so, does that really mean Sectigo was down for 5 days. I find that hard to believe. It only renewed now after I did a manual check. I want to make sure this doesn't happen again. I also got no CPanel warning about the cert not being renewed and/or being expired for the account? I just happened to discover it when going to the website myself.

 

[cPRex]

@GoWilkes - it looks like they found some www entries missing that was keeping the SSL from being issued.

@jazee - if Sectigo is overloaded, there isn't anything we can do on our end. This has been an issue for most of this year, and we're looking into possible workarounds.

 

[GoWilkes]

@jazee, mine was apparently messed up for 3 months, and I didn't get any emails about it either! But like Rex implied, when it's relying on a third party sometimes things go wrong that are out of their control.

Why we didn't get notified, though, is a whole 'nother problem that I can't answer.

A smarter person would buy a certificate for $15 /year and eliminate all of this stress:

PositiveSSL DV - Buy Great Value SSL Certificates from Sectigo CA

Secure your website effectively in a quick and cost-effective way with Sectigo PositiveSSL certificates that offers latest encryption and fast issuance.

www.servertastic.com

Unfortunately for me, I'd have to buy over 100 of them! So that becomes impractical. But maybe it'd be a solution for you.

@cPRex, you're right, I had a reply last night that the www CNAMES (www.i.example.co and www.inc.example.co) were required and the source of the problem. The tech analyst added those CNAMEs, and then it renewed last night.

Questions that are as of yet unresolved are:

1. What caused those CNAMEs to disappear in the first place?

2. What do I do now about the 200+ CNAME records that are for comodoca.com?

I asked the tech, and I'll post back with any resolution.

 

[GoWilkes]

Re: the 200+ CNAME records, I found this:

https://support.cpanel.net/hc/en-us/articles/5468490760471-stale-comodoca-com-CNAME-records-exist-when-there-are-does-not-resolve-to-any-IP-AutoSSL-errors

It looks like a known bug reported about 4 months ago, and the only resolution is to delete them all manually. I'm not sure if I need to leave ANY of them or if they all should be deleted, though. And if I need to leave one, I don't know which one to leave.

 

[cPRex]

Anything with the word "Comodo" can be removed at this point.

 

[GoWilkes]

Thanks @cPRex. I spent the last hour removing all of them, and so far all seems well.

One thing I wanted to mention, mainly for future readers:

The tech analyst added a CNAME for www.i.example.co that pointed to i.example.co, and www.inc.example.co that pointed to inc.example.co. This works fine, but an A record would process slightly faster than a CNAME (about 300ms).

So a better solution would have been to add both as an A instead of a CNAME, and then point them to the primary IP of the server.

WHM creates a CNAME record by default for www.example.co that points to example.co, but I've been changing those CNAMEs to A records for about 2 years now. In theory the DNS lookups would be cached by the browser so it only affects the first visit, but still, it only takes a minute to do.