[CPANEL-39321] Service SSL Certificates expire in 11 days, but not auto renewing
I'm receiving daily emails saying that the cPanel service certificates are due to expire on the 11/28/21:
'You need to install a new certificate as soon as possible. You can do this with WHM"s "Manage Service SSL Certificates" interface at
Manage Service SSL Certificates | cPanel & WHM Documentation states that cPanel issues free certs for these host services and that upcp should auto install a new cert if they are due to expire within 25 days. However, after 'Processing command `/usr/local/cpanel/bin/checkallsslcerts --allow-retry --verbose`' the upcp logs state '[2021-11-11 03:30:37 +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.'
On other machines I have running cPanel, these service certs seem to get updated automatically without the service certificate expiry emails being sent. I'm concerned that there's something stopping auto renewal and they will not renew even after the 25th.
Please advise.
-
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? 0 -
Just confirming this IS fixed as of version 100!
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 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.0 -
@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. 0 -
deleted 0 -
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. 0 -
@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.
Thanks for the reply @cPRex. We have ver 100.0.7domain.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. 0 -
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.0 -
@qcomber - let me look into this again and I'll have another update soon! 0 -
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! 0 -
Many thanks Rex, What do I need to do to resolve this before Feb 7, 2022? 0 -
You don't need to do anything to get that working - since the SSL expires on the 10th, the system will query for a replacement on the 7th and it will be installed automatically. 0 -
So I'm back to square 1 " either: - another 'seat of the pants palaver bricking it to a last minute crescendo' on 10th Feb; or
- run the manual workaround which may or may not be successful and will definitely result in a period of service certificate outage.
0 -
At this time they haven't been resolved, but with your situation you'll get the SSL renewed on the 7th as expected. If for some unlikely reason that doesn't happen, a ticket to our support team then will resolve the issue. 0 -
Just to say that my last experience of waiting until 3 days before was highly stressful as it didn't happen until about 3 hours before expiry, as per my previous posts. But - Good news! Since Rex's last post I have continued to receive the dreaded 'The SSL certificate for "cpanel" on host.domain.com" will expire in less than 30 days.' emails on each daily upcp cron execution. Service ssl certs are due to expire on the 9th Feb i.e. in 6 days. However, today I was given a new yellow box in WHM at the top right 'click here to update to 10.0.8' - which I duly did. Part of this update runs checkallsslcerts which has now installed the service ssl certs without issue *more than* 3 days before expiry - confirmed in the logs. Also confirmed on another server which was experiencing the same issue, but with expiry in 23 days. Phew, no more seat of the pants last minute crescendo stress. For me, this thread is now solved. Thanks Rex & Anthony. 0 -
Thanks for the post -- have also been getting stressed by this issue. I've been getting emails now for a few weeks that one of my server's free cpanel/whm hostname certificates would expire in under 30 days. This one was already a 90-day hostname certificate. At midnight last night, by my watch it was within the 3-day timeframe; however running checkallsslcerts again returned only the same message today, on February 6th, at 3:20 PM EDT that: [quote]The "cpanel" service's certificate will expire soon (February 9, 2022). If this certificate remains installed on Feb 6, 2022, the system will attempt to replace it.
That is the message I get on February 6th, server time Eastern, but I can't see anything else happening even with the --verbose option. Unsure if the script is using a date other than the server's Eastern Time?0 -
AutoSSL is failing and some of our SSL certificates have now expired as a result! This error appears in the AutoSSL logs for the domains that have expired: "The response to the HTTP (Hypertext Transfer Protocol) "POST" request from " indicated an error (500, Internal Server Error): 0 -
@Reado - if these are domain SSLs for websites, switch to the Let's Encrypt provider. @horizon2021 - if you can't get the hostname SSL to issue, please submit a ticket to our team and we'll see if we can get that working for you. 0 -
That is the message I get on February 6th, server time Eastern, but I can't see anything else happening even with the --verbose option. Unsure if the script is using a date other than the server's Eastern Time?
On the 7th running checkallsslcerts would try to renew and fail (whereas before the 7th it was not even trying saying it would wait until 3 days before the 9th, although the hostname cert was set to expire at 11:59 on the 8th.) I ran the checkallsslcerts script manually about 10 times and then it grabbed the hostname cert successfully finally.0 -
This is so annoying. I have clients complaining that their website is showing an SSL error. I keep getting the following email alerts almost daily with the subject line containing, "Potential reduced AutoSSL coverage". After 3 or so days, the website cert will expire and I have to go into WHM and select "Manage Auto SSL" and then choose 'Run AutoSSL for all users'. That solves the problem for now.., but I have to keep doing this.. Should I enable, 'Allow AutoSSL to replace invalid or expiring non-AutoSSL certificates.'??? This is getting very annoying.. 0 -
@kingsburyweb - yes, if you choose that option that may help with this issue. You can find more specifics about that warning message here: Potential reduced AutoSSL coverage notification 0 -
few months ago, an issue with LE, temporal fix was swtiching to sectigo.... not temporal fix is to switch to LE... what a mess. 0
Please sign in to leave a comment.
Comments
51 comments