One in 30 domains in the same server application fails to generate a certificate

Hi all,

On 30/12/21 our combined SSL certificate for 30+ domains expired. There are about 30 domains within the same application, all pointing to the same IP address (, but one of them always fails to generate. When I'm in luck and repeat the process, it may potentially generate on the 3rd/4th attempt, which was the case for a few times last year or so. This domain we've had for 3 years, potentially it could have started happening when we switched the generating tool from X3 to R3, but maybe even before, I'm not sure.

Today, I'm not in luck, it simply won't generate it even on the 5th attempt and due to too many failures it'll kick me out for one hour (due to rate limits for subsequent failures). And the same happened a few times today when I repeated this. (By the time you read this, I might succeed in one of my further attempts, but there is still something wrong, because it never happened with any other domain, only this one).

I believe something's wrong with the domain itself (that I can't DNS manage myself, but I can get client to fix if there's anything to fix). An example of a 'good' domain (out of those 30 on the same SSL) is for instance

So right now, I had to take this domain out of the list to have at least those other 30 sites working. Which obviously isn't a solution.

The domain that fails:

I ran this client:

It produced this output:
type: urn:ietf:params:acme:error:unauthorized
detail: Invalid response from [2a07:7800::138]
status: 403
During secondary validation: Invalid response from [2a07:7800::138]

My web server + OS:
Windows Server 2016 v 1607 (OS Build 14393.3930)

I can login to a root shell on my machine.

I'm using IIS to manage my site.

Any idea what could be wrong? Thanks for any help!

Does not have an IPv6 address associated with the hostname (there is a CNAME, but not an AAAA record for the corresponding hostname).

DOES have an AAAA resource record associated with its hostname.

I don't know the AAAA status of the other 28 hostnames, but my guess is faulty IPv6 accessibility. In this case there was an invalid response from one of the secondary validation vantage points.


Hmm, a good point Osiris, there's definitely some logic to it. It looks like that none of the others have the AAAA record (I picked a few and checked via whois).
So - would you suggest asking the client to remove the AAAA entirely (won't this have any side effect?), or tell them to replace the value with:
that, according to the online converter, is the ipv6 version of our IP address:

I would not suggest such techniques. That was from years ago during the initial transitional period. Nowadays (if ever?) it doesn't have any benefit.

I would suggest to either FIX the IPv6 connectivity. Otherwise it's up to the client: either have a website that has flaky connectivity (situation now) or have a website that isn't reachable on IPv6 entirely (if the AAAA record is removed). The former isn't very good advertisement for your site if you'd ask me and the latter is only an issue for IPv6-only clients.


Thanks a lot, I'll see what we'll come up with and what the client agrees with.

1 Like

The client agreed to removing the AAAA record, which was the simplest and easiest workaround for now, and it worked. I was then able to generate the cert.
Thanks a lot for your help Osiris!


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