Error requesting SSL certificate for "naked"/apex domain alias

Hi there! I’m having trouble provisioning a Let’s Encrypt SSL certificate for one of our sites, and I’m not sure if the issue is with our DNS settings or Netlify.

The certificate works fine for the primary domain and www domain alias (,, and, but fails on the apex of the domain alias (, with this error:

SniCertificate::CertificatelnvalidError: Unable to verify challenge for Invalid response from 204

Here are the domain settings in Netlify: (Default subdomain) (Primary domain) 👍 (Redirects automatically to primary domain) 👍 (Domain alias) 👍 (Domain alias) 🚫 😢

And these are the DNS records:			A		CNAME			A		A

(The and domains are configured differently because they’re at separate registrars for legacy business reasons I hope to change soon. From everything I’ve read in Netlify’s docs though, it seems that using A records for both the www and apex domains records should work fine?)

I tried adding a _redirects file as suggested here, but it doesn’t seem to make any difference:* 302!* 302!* 302!* 302!

I can change DNS settings, but given the long feedback loop, I’m just trying to get a sense of what, if anything, I should be looking to change. I’ve been at this for a few days and am grasping at straws.

Thanks for any help!

@zac Welcome to the Netlify community.

Have you checked lately? Each of your custom domains seems to load fine with SSL here in Southern California, and your settings look good from what I can see.

Thanks, @gregraven!

It’s working on certain browsers for me, but not all, and I can’t narrow down any specific conditions that affect it. For example, Chrome works fine, but Firefox gives me this:

Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for The certificate is only valid for the following names: *,

I’ve also asked my remote team to test this, as well as from a VPN at different locations. Results vary, but mostly we’re getting the same error.

I tried to renew the certificate again this morning, and got the same error message as before:


One weird thing I noticed is that the error message above includes an IPv6 address (2607:f1c0:100f:f000::25e) which does not belong to Netlify. That IP actually points to the domain registrar and “old” hosting. A quick dig on the domain shows there is an AAAA record on the domain pointing to that same IP:

(I hadn’t noticed this before because running dig AAAA in my terminal doesn’t return any results, and I don’t have direct domain control panel access, I need to request any changes through the client’s IT administrator.)

Could this be the problem? It seems that Netlify (or I guess Let’s Encrypt) is using this AAAA record instead of the A record when trying to request/install the certificate?

If so, might the solution be to simply delete the old AAAA record at the domain registrar? (I don’t see any docs about pointing AAAA records at Netlify, so I assume that’s not supported?)

Thanks again!

@zac In the absence of documentation to the contrary, I would set up the DNS as recommended by Netlify.

Two other things:

  1. I just noticed in your initial post you reference both and – the difference being and Maybe you own each.

  2. Your DNS records make reference to a, which makes it look as though in addition to using Google DNS you have something at Don’t know anything about, but that doesn’t seem correct. I would think that any utility that looks at for authoritative information about your domain is going to be disappointed.

1 Like

For anyone else experiencing a similar situation, the issue turned out to be what I suspected in my previous reply: an old AAAA record was pointing to a different web host (not Netlify), and intercepting the attempt to request an SSL certificate. Removing the AAAA record and renewing the certificate fixed it.

Be sure to look closely at Netlify’s cryptic SniCertificate::CertificateInvalidError message. It actually includes the IP that Let’s Encrypt is trying to request a certificate for (circled red text, below)—but I didn’t realize that at first because IPv6 addresses are still a bit foreign to my eyes. That IP should have been pointing to Netlify, but it wasn’t. Once I identified that it was an IP address, I did a lookup to see where it lived, and it turned out that it belonged to our old web host.

That should have been the end of it, but it still took me a while to figure out that the AAAA record really actually existed, and this wasn’t some DNS caching quirk. For some reason, running dig AAAA in my terminal didn’t return any results—but checking it with Google’s Admin Toolbox did.

Thanks for your help and suggestions, @gregraven!

1 Like

Hi, @zac. Thanks for taking the time to share the root cause and solution.

1 Like