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: www.devry.edu
Issue:
Certificate Pending via Akamai Portal for more than 24 hours.
Is there a time frame/ ETA on how long Let’s Encrypt will take to validate and respond back to Akamai for a shred cert.
I am from Akamai, we have sent a validated shared cert, have been waiting Lets Encrypt to get back.
Last Comment we see is - 2020-04-16 19:27 GMT Let’s Encrypt: Order\u0027s status (\
I felt the same thing - the time is 2 hours in the future but that is the comment from the CA that we have received, I wasnt sure if that was something Let’s Encrypt was suggesting as the propagation time or…
I am checking for the URL - www.devry.edu which is part of the shared cert.
E.g. the timestamp strings from Let’s Encrypt are formatted like 2020-04-16T18:11:15Z. Even if the “19:27” time came from one of the Let’s Encrypt API endpoints, at the very least your software ran it through some conversion routines.
Can you post complete logs of your client’s interactions with the API? And information about the implementation? The Let’s Encrypt sysadmins may be able to look up the server-side logs, but only your ACME client knows the complete context about what it’s thinking.
Edit: The third word in the “Order’s status …” error message you referenced is the most important.
The order (request to issue a certificate) containing www.devry.edu contains a number of other domains. There was an error checking CAA for one of the other domains:
DNS problem: SERVFAIL looking up CAA for premiersteel.com.cn - the domain's nameservers may be malfunctioning
In general there are two solutions to that:
Contact the domain own about fixing their authoritative server so it returns correctly. More info about CAA is here.
Remove that domain from the request so it can proceed for the other domains.
There’s a secondary problem, though: After the Akamai software tried to finalize the order by sending a POST to /acme/finalize/<order id> and received an error, that order took on the status “invalid.” That’s expected. However, the Akamai software keeps trying to finalize that same order rather than creating a new order with the same names. I think that may be a bug in the Akamai software specific to the ACMEv2 implementation - can you check in with the rest of your team?
So that suggests that the authoritative DNS servers for premiersteel.com.cn don't always return SERVFAIL for this CAA query. Also, looking at our logs, it seems we have successfully looked up CAA records for this hostname in the past.
My recommendation is: Try to get your system to create a new order with the same hostnames. I think there's a good chance the SERVFAIL here was a temporary blip for the authoritative DNS servers for premiersteel.com.cn and the check will succeed next time.
It’s not possible for Let’s Encrypt to manually approve orders. Our whole system is automated. We believe that results in a system with less opportunity for mistakes.
However, it’s easy for an ACME client to submit a new order!