Lets Encrypt certificate submitted via Akamai

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

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.

1 Like

This is a partial answer:

Let’s Encrypt takes seconds.

I don’t know how long Akamai’s processes take.

If someone on this forum has experience with Akamai, they might be able to provide more information; if not, consider asking Akamai’s support.

1 Like


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 (\

1 Like

Oh. Sorry. Hello!

Can you post what your most recent requests to the API were, and what the responses were?

Are you polling one of the URLs?

Whether things succeed or fail, they shouldn’t take very long to transition to an end state.

Edit: 19:27 is over two hours in the future. Is your clock okay?


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.

It’s not what the CA sent byte-for-byte.

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.

1 Like

Not sure if I can share the API call.

But is there a way to check for a particular domain from your end or for a certificate as to why it snot pushed?

Certificate name -cert00060-azurecdn.akamaized.net
CA comment - 2020-04-16 19:27 GMT Let’s Encrypt: Order\u0027s status (\

Is there was to check using the domain name - www.devry.edu

Let’s Encrypt’s sysadmins can look up the logs. (I don’t work for Let’s Encrypt.)

The information the API returned to you probably includes enough information to work out what’s happening.

How detailed are your logs, anyway? Do they include the URLs? Error messages? Complete JSON requests and responses? Complete headers?

Do they include the rest of that sentence?

If you have most of the information, it would probably be possible to work out what’s going on, even if you’re not willing to post all of it.

If the client doesn’t support keeping detailed logs, it would help you if the ACME client authors can add support.

1 Like

So basically,

The call from my end includes the BatchID/CheckID, it also includes the domain that needs to be validated.

A snippet -

prod-www-devry-edu.akstd.azureedge.net__timestamp__1586917100729’)] pending_move_to_request_ids(0)="}

Hi @Aarushi, welcome to the forum!

It looks like there are two problems going on.

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?



Hi @jsha,

Thank you so much for looking into this.
I will check internally with the Akamai Certificate team and get this issue fixed.

Again appreciate your help.


HI @jsha

We are checking further on the Akamai POST.

Could you confirm regarding the CAA error once more.

$ dig premiersteel.com.cn CAA

; <<>> DiG 9.10.6 <<>> premiersteel.com.cn CAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2307
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 2

Thank you

1 Like

Hi @Swati! Welcome. :slight_smile:

I can confirm that from my laptop at home, I get a NOERRROR answer for this:

$ dig CAA premiersteel.com.cn 

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> CAA premiersteel.com.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41867
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;premiersteel.com.cn.           IN      CAA

premiersteel.com.cn.    3600    IN      SOA     ns1.myhostadmin.net. dnsconct.myhostadmin.net. 2019111839 3600 300 604800 3600

;; Query time: 300 msec
;; SERVER: 2001:558:feed::1#53(2001:558:feed::1)
;; WHEN: Thu Apr 16 15:56:56 PDT 2020
;; MSG SIZE  rcvd: 112

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.

Hi @jsha

Thank you for confirming this.
We will go back and ask the team to create a new order.

Thanks again.

1 Like

Hello @jsha

Is it not possible for Let’s Encrypt to manually approve the order since the error do not exist anymore?

Hi @athanikk! Welcome to the forum.

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!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.