Hi @cPanelAnthony,
I thought I replied, but I don’t see it now. I must have forgotten to post it. In any case, I did open a ticket #94392864 and received a very quick reply from Thomas. He pointed me to an article about the situation, which I had read. I had mistakenly thought this had been resolved in 100.0.5 but apparently not. So, I now have instruction to force it if I don’t want to wait until the 3 day auto renewal. Seeing how that would be Christmas Day, I'll probably force it ahead of time. Thanks again.
Running on 100.0.5 and ever since, some of my customers domains certfs are not renewing. PLEASE HELP.
Can you open a ticket using the link in my signature so we can investigate the SSL issues? If you cannot, your web hosting provider should be able to open one on your behalf.
What do you exactly mean by version 100? Bug was introduced in version 100, and it was still not fixed in 100.0.5.
What is exact version with a fix and when it will be in release?
Just confirmed as well. 100.5 did not autorenew service certs. Account certs are renewing, but with lots of errors. I am excluding a lot of cpanel-generated subdomains from the renewals.
Manually running /usr/local/cpanel/bin/checkallsslcerts, per the support article posted above, did renew my service certificates.
Off to check my other servers....
I'm also running cPanel v100.0.5 and have this issue as well. Last year, I never ran into this problem and everyone's domains certs were automatically renewed. Now I get daily notifications of "Potential reduced AutoSSL coverage" with the following information:
AutoSSL would normally renew this certificate now, but 6 of the website’s secured domains just failed DCV. To provide you with more time to resolve these problems, AutoSSL will defer the renewal until Jan 18, 2022 at 12:00:00 AM UTC. After that time, AutoSSL will request a replacement certificate that excludes any domains that fail DCV. At the time of this notice, the certificate will expire in 3 days, 4 hours, 1 minute, and 15 seconds
For domains not pointed to our name-servers, however the root and www records are pointed to the server IP, we noticed these warnings as of recently.. webmail. cpcontacts. cpanel. mail. etc.. might not be pointed to our web server in lets say GoDaddy DNS, but the email does validate that the main domain name and www records are. Something is going on here...? Occasionally we are gettin calls from customers that their website is showing a certificate warning?! Again, this has never happened before so a recently cPanel release must have caused these issues.
AutoSSL would normally renew this certificate now, but 6 of the website’s secured domains just failed DCV. To provide you with more time to resolve these problems, AutoSSL will defer the renewal until Jan 18, 2022 at 12:00:00 AM UTC. After that time, AutoSSL will request a replacement certificate that excludes any domains that fail DCV. At the time of this notice, the certificate will expire in 3 days, 4 hours, 1 minute, and 15 seconds
For domains not pointed to our name-servers, however the root and www records are pointed to the server IP, we noticed these warnings as of recently.. webmail. cpcontacts. cpanel. mail. etc.. might not be pointed to our web server in lets say GoDaddy DNS, but the email does validate that the main domain name and www records are. Something is going on here...? Occasionally we are gettin calls from customers that their website is showing a certificate warning?! Again, this has never happened before so a recently cPanel release must have caused these issues.
Pleased to say the work around - cPanel - worked for me and got my service certificates updated.
Worth noting, as much as it shouldn't matter if the certificate isn't renewed until three days before the expiration, in reality it does. Had a call from a customer this afternoon (which is why I became aware of this) because on his Mac it was giving him an error due to the certificate being close to expiring, and it seems in Apple land that makes it dodgy, so without him expressly choosing the "it's OK, I trust this" style option it wouldn't let him collect his email.
Worth noting, as much as it shouldn't matter if the certificate isn't renewed until three days before the expiration, in reality it does. Had a call from a customer this afternoon (which is why I became aware of this) because on his Mac it was giving him an error due to the certificate being close to expiring, and it seems in Apple land that makes it dodgy, so without him expressly choosing the "it's OK, I trust this" style option it wouldn't let him collect his email.
Noticed the same thing over the last couple of months. The work around is to go into the relevant site's cPanel and open the "SSL/TLS Status" app. Within that you can see the status of autossl for each host name, and select to exclude any from being included in AutoSSL that don't actually exist. If you don't see that app, you need to ensure the "SSL Host Installer" feature is enabled for that account, and no as far as I can find there's no way to bulk make the change or do it from within WHM annoyingly.
FWIW, lately we've been seeing A LOT of:
...in our AutoSSL logs. Seemingly sticky to certain domains.
How is this solved when it's still happening? Excluding parts of those that failed isn't really a permanent solution. What if some of them are needed? Can a CPanel admin re-open this ticket please?
Just to confirm this issue *IS NOT* fixed in 10.0.7.
As the OP, I'm seeing the same issue on a different server to the original post running 10.0.7:
[2022-01-23 21:02:32 +0000] - Processing command `/usr/local/cpanel/bin/checkallsslcerts --allow-retry --verbose`
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will check for the certificate for the “cpanel” service.
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will attempt to verify that the certificate for the “cpanel” service is still valid using OCSP (Online Certificate Status Protocol).
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The “cpanel” service’s certificate will expire soon (Feb 10, 2022). If this certificate remains installed on Feb 7, 2022, the system will attempt to replace it.
I agree with Whipworks, pls re-open asap.
@bellwood - the "provider cannot currently accept incoming requests" is definitely a known issue with Sectigo's network. We're hoping they resolve that soon, but switching to Let's Encrypt, if possible for your domains, will get things working quickly.
@whipworks and @qcomber - the error in qcomber's output isn't the same as the original issue. The original problem was that the validation was failing, but the notice you posted is just letting you know the SSL will be renwed when it gets closer to the expiration date. If you're seeing problems specifically with the DCV validation portion of the renewals, that would be related to CPANEL-39321.
The fix was included with 100.0.5.
If I'm misunderstanding what you're seeing on your end, let me know and I can do some additional testing.
@whipworks and @qcomber - the error in qcomber's output isn't the same as the original issue. The original problem was that the validation was failing, but the notice you posted is just letting you know the SSL will be renwed when it gets closer to the expiration date. If you're seeing problems specifically with the DCV validation portion of the renewals, that would be related to CPANEL-39321.
The fix was included with 100.0.5.
If I'm misunderstanding what you're seeing on your end, let me know and I can do some additional testing.
Thanks for your reply Rex.
The checkallsslcerts logs in my posts in this thread show exactly the same output, indicating it's the same issue.
November 2021 on machine 'A':
[2021-11-25 03:30:31 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will check for the certificate for the “exim” service.
[2021-11-25 03:30:31 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will attempt to verify that the certificate for the “exim” service is still valid using OCSP (Online Certificate Status Protocol).
[2021-11-25 03:30:31 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The “exim” service’s certificate will expire soon (Nov 28, 2021). If this certificate remains installed on Nov 25, 2021, the system will attempt to replace it.
January 2022 on machine 'B':
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will check for the certificate for the “cpanel” service.
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will attempt to verify that the certificate for the “cpanel” service is still valid using OCSP (Online Certificate Status Protocol).
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The “cpanel” service’s certificate will expire soon (Feb 10, 2022). If this certificate remains installed on Feb 7, 2022, the system will attempt to replace it.
My original post and the reason for starting this thread is all about COBRA-13510. The fix you mentioned "CPANEL-39321: Adjust hostname SSL certs’ DCV for ancestor/implicit DCV change" doesn't appear to address the COBRA-13510, hence the continued issue. Quote from cPanel: "When /usr/local/cpanel/bin/checkallsslcerts runs it thinks cPanel provided hostname certificates are third-party SSL certificates, which causes the SSL to be renewed three days prior to expiration. We've opened an internal case for our development team to investigate this further. For reference, the case number is COBRA-13510. Follow this article to receive an email notification when a solution is published in the product.". This article includes a workaround which I'm very reluctant to run as it will result in cert outages on live services which are in constant use. This is therefore is a low quality solution, even if the outage is very shortlived.
The problem is compounded because there are also issues with the date comparisons in checkallsslcerts resulting, more by luck I think with my last experience, in the renewal happening with just a few hours to spare. This is entirely unsatisfactory. Also unnecessary when the auto-renewal as apart of UPCP would be happening 1 month (25 days I think it is) in advance, if COBRA-13510 had been addressed.
Please advise.
The checkallsslcerts logs in my posts in this thread show exactly the same output, indicating it's the same issue.
November 2021 on machine 'A':
[2021-11-25 03:30:31 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will check for the certificate for the “exim” service.
[2021-11-25 03:30:31 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will attempt to verify that the certificate for the “exim” service is still valid using OCSP (Online Certificate Status Protocol).
[2021-11-25 03:30:31 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The “exim” service’s certificate will expire soon (Nov 28, 2021). If this certificate remains installed on Nov 25, 2021, the system will attempt to replace it.
January 2022 on machine 'B':
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will check for the certificate for the “cpanel” service.
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The system will attempt to verify that the certificate for the “cpanel” service is still valid using OCSP (Online Certificate Status Protocol).
[2022-01-23 21:02:34 +0000] [/usr/local/cpanel/bin/checkallsslcerts] The “cpanel” service’s certificate will expire soon (Feb 10, 2022). If this certificate remains installed on Feb 7, 2022, the system will attempt to replace it.
My original post and the reason for starting this thread is all about COBRA-13510. The fix you mentioned "CPANEL-39321: Adjust hostname SSL certs’ DCV for ancestor/implicit DCV change" doesn't appear to address the COBRA-13510, hence the continued issue. Quote from cPanel: "When /usr/local/cpanel/bin/checkallsslcerts runs it thinks cPanel provided hostname certificates are third-party SSL certificates, which causes the SSL to be renewed three days prior to expiration. We've opened an internal case for our development team to investigate this further. For reference, the case number is COBRA-13510. Follow this article to receive an email notification when a solution is published in the product.". This article includes a workaround which I'm very reluctant to run as it will result in cert outages on live services which are in constant use. This is therefore is a low quality solution, even if the outage is very shortlived.
The problem is compounded because there are also issues with the date comparisons in checkallsslcerts resulting, more by luck I think with my last experience, in the renewal happening with just a few hours to spare. This is entirely unsatisfactory. Also unnecessary when the auto-renewal as apart of UPCP would be happening 1 month (25 days I think it is) in advance, if COBRA-13510 had been addressed.
Please advise.
Thanks for the reply @cPRex. We have ver 100.0.7
| domain.ca: AutoSSL would normally renew this certificate now, but 5 of the website’s secured domains just failed DCV. To provide you with more time to resolve these problems, AutoSSL will defer the renewal until Jan 29, 2022 at 12:00:00 AM UTC. After that time, AutoSSL will request a replacement certificate that excludes any domains that fail DCV. At the time of this notice, the certificate will expire in 6 days, 14 hours, 3 minutes, and 50 seconds. cpcontacts.domain.ca (checked on Jan 25, 2022 at 9:56:04 AM UTC) DNS DCV: No local authority: “cpcontacts.domain.ca”; HTTP DCV: “cpcontacts.domain.ca” does not resolve to any IP addresses on the internet. As an example of what we still get. There's 4 of them that failed. I didn't want to post all of them. |
whipworks,
I think your issue is resolved simply by switching off autossl for subdomains which fail DNS, or fixing the DNS issues, and is unrelated to this thread which concerns auto renewal of service ssl certificates
Cheers.
Last edited:
Alright - so I think I know what caused the confusion here, and it's something that seems to happen whenever we get two related cases in the same thread.
CPANEL-39321 has already been fixed in v100, but COBRA-13510 is only fixed in v102. We're waiting on the team to do a backport to v100, and that is likely going to get worked on next week. So unless you're running Current, you won't see that fix on your system.
I hope that clears things up!
CPANEL-39321 has already been fixed in v100, but COBRA-13510 is only fixed in v102. We're waiting on the team to do a backport to v100, and that is likely going to get worked on next week. So unless you're running Current, you won't see that fix on your system.
I hope that clears things up!
