My domain is: fdr-tickets.supercars.com
Akamai manages our certs and every month we're asked to update the token from Let's Encrypt.
We use DNS token as validation method.
What exactly is the question here?
Looking at the two most recent certificates issued which include your hostname (old vs new) we can see two new hostnames were introduced (fdr-tickets.allblacks.com and seasontickets.motorpointarenanottingham.com) which was probably the reason why Akamai issued a new certificate.
And currently valid authorizations for a certain hostname is valid for 30 days, so after 30 days the hostname needs to be validated again.
4 Likes
Thank you for your answer.
The other hostnames/domains we have don’t need to be validated as frequently as fdr-tickets.supercars.com so we’re puzzled.
Is there a documentation that hostname validation occurs within 30 days? I thought it was 90. Can we extend the number of days?
1 Like
Any validation process which involves manually updating tokens is probably the most difficult way to approach things. Let's Encrypt is designed all around automation. I'm not that familiar with Akamai's offerings, but if they're terminating your TLS then I would expect them to be able to get certificates all themselves, or that all they'd need you to do is to CNAME the _acme-challenge DNS name to them so that they could update it automatically whenever needed.
The 30 days before needing to revalidate a name is an implementation detail that they're mentioned the possibility of shortening in the past. But that's just for if you want a new certificate for an existing name, which one usually only needs when you're adding a new name onto a certificate.
The 90 days is the current certificate length and can't be changed. (Though they've talked about letting people get shorter certificates eventually.) The common recommendation is to renew 30 days in advance of expiration, so that you would need to get a new certificate every 60 days. But again, in most cases that's just automated and you would never notice.
6 Likes
It might be that this specific hostname was still valid from a previous certificate issuance, i.e., within the 30 days.
I'm not sure I understand what you mean by this, but the FAQ mentions that valid authorizations are cached for 30 days: FAQ - Let's Encrypt.
That's the validity of the certificate which is something entirely different than an authorization. See How It Works - Let's Encrypt for more information.
No.
This also puzzles me: why would you require to "update the token" manually to begin with? Automation is key to the success of the ACME protocol.
3 Likes
Thank you for sharing. Akamai just fetches the new certs for us after we take care of the validations unfortunately.
I’m still just baffled why it’s only this domain that’s constantly getting new tokens for validation. The others are still valid for more than a month it seems.
1 Like
Can you elaborate how other hostnames are still valid after 30 days please? I have no idea.
The hostname in question gets validated monthly but the others we don’t get prompted every month
Not after 30 days, but if you issue a new certificate within 30 days, then a new authorization is not required. If you issue certificates regularly, i.e., within 30 days (which is the case for fdr-tickets.supercars.com, it's possible to skip the authorization once, but not after 30 days.
Then maybe those hostnames are automated? I dunno, ask Akamai 
I see there still is a TXT RR present at _acme-challenge.fdr-tickets.supercars.com.. So probably not automated, as usually any automated service would also automatically remove the TXT RR.
5 Likes
I'm just going to second this. It sounds like Akamai (or at least how your systems are integrated with Akamai) has a weird way of doing things that we on this forum aren't familiar with.
8 Likes
What’s a TXT RR? 
Oh. I get the first R in RR but not the second.
RR=Resource Record
But, can you give example domain name that does not have this problem?
I agree with my fellow volunteers that this is better directed to Akamai
It looks like you already CNAME to something they might control and so could setup automated renewal for you. Is that "dvsan.ticketek.edgekey.net" something of theirs?
Do you use DNS validation for the other domains that work? Because there is also an HTTP Challenge maybe those others use that?
fdr-tickets.supercars.com. 300 IN CNAME dvsan.ticketek.edgekey.net.
supercars.com. 172800 IN NS ns-1071.awsdns-05.org.
supercars.com. 172800 IN NS ns-1724.awsdns-23.co.uk.
supercars.com. 172800 IN NS ns-662.awsdns-18.net.
supercars.com. 172800 IN NS ns-70.awsdns-08.com.
;; Received 227 bytes from 205.251.192.70#53(ns-70.awsdns-08.com) in 2 ms
6 Likes
The subdomain tickets.supercars.com doesn't need to have the acme challenge txt record updated as much. Also, tickets.nzc.nz.
Thanks all for the help here. I'm learning a lot as we go.
We use DNS validation for those that work, yes. The http token, does it not expire after 30 days like a DNS one?
1 Like
Tokens are ephemeral strings used for challenges and are used for, but a distinct entity from authorizations.
3 Likes
If these are also hosted by Akamai, it sounds like Akamai has different sets of procedures for some reason, with different levels of automation! As was mentioned before, Akamai probably could automate this entire process for you so that you wouldn't need to create TXT records manually at all. And it seems plausible that they actually did do that with some domains, but not with others!
No, I don't know why that would be, but it could be something about different workflows from different products or different customer acquisition paths, or slightly different plans or services.
Let's Encrypt always makes you prove control of your domain name(s), using one of three technical methods periodically in order to issue certificates. As was noted here, that proof lasts for a certain period of time after it's performed, but then expires; the certificates themselves also expire after a (different, longer) period of time. So, there's no way to perform the proof once and for all and have it last forever. (That's different from some other services where you prove control of your domain name by creating a particular DNS record and then that never has to change. In this regard, Let's Encrypt is following industry rules specific to publicly-trusted digital certificates.)
This process, including the proof of domain control, is ideally supposed to be completely automated by software so that human beings don't have to do things like manually create new TXT records. Different companies and hosting setups have had different degrees of follow-through on that automation ideal so far. 
7 Likes
I am puzzled why tickets.supercars.com would be any different than fdr-tickets.supercars.com. They both appear on the same cert so are subject to the same expiration and auth caching. (see recent cert history here).
I suppose if one of these names was added to this (large) cert at a different time the auth caching may be skewed from the other.
One disadvantage of having a cert with so many names is it often has to be re-issued entirely if a name needs to be added or removed. And that is happening here. Perhaps it is just a quirk of timing with the auth cache and issuing such a large cert so often. Using a large cert was a choice made by Akamai. It's not wrong it just has its own pros and cons.
The other mystery is why this can't be automated when using Route53 for DNS. A good question for Akamai.
5 Likes
As an aside, if you are manually proving domain control using DNS your system is broken and you need to step back and review the processes. A manual renewal step will bite you eventually, usually when someone goes on vacation. You need to speak to Akamai and escalate this as a complaint about their process, because if your domain points at their edge servers then at the very least they must be able to do http domain validation on your behalf.
If they need help I'll fix it for them for $1M, that's like one customer contract right?
5 Likes
It turns out we were pointed to the wrong edge server DNS for fdr-tickets.supercars.com. I can see the other hostnames are pointed on the right one. Though I'm still baffled how that impacts the authorizations for that hostname unlike the others.
Just guessing but if there is a right and wrong edge server then perhaps the right edge server can answer http challenges (or tls-alpn-01) and it only falls back to DNS validation (asking you for a TXT record to be set) if it knows you're not pointing to it, or if previous validations have failed.
To really get to the bottom of it you'd need to raise the question directly with the Akamai Certificate team.
5 Likes