Failed authorization procedure - ubuntu 16.04 & nginx

There is also an IPv6 address for this host, yet it appears to be configured properly and responding to IPv6 requests with the same content as to IPv4 requests (so that’s great). Still, when doing the test that @rg305 suggests, it would be worth checking that IPv6 answers the same way as IPv4, too.

I ran the exact command you posted (changing the path to the correct 1, of course) and it is browseable on the net just fine:

is there anything specific I can do to check the responses between the two types of IP addresses?

Try from Internet:
curl -IkL4
curl -IkL6

Since Let’sEncrypt will prefer IPv6, you must ensure that IPv6 is working.

the 1st one worked fine, the second one produced an error from my local server:
-bash: No such file or directory

I then tried the second command from a server in a proper data center and it errors out with:
curl: (7) Couldn’t connect to server

DNS shows IPv4 + IPv6
Your server shows :80 + [::]:80
But I suspect the “gateway” is not participating with IPv6 flow.

You could either remove IPv6 entries from DNS or get the “gateway” configured properly.


the thing is, I do not have any AAAA records set for the domain name…I literally only have 2 records set in cloudflare, 1 A record for and 1 A record for…is cloudflare automatically proxying AAAA records?

It seems CloudFlare automatically adds AAAA records:

Addresses: 2400:cb00:2048:1::681f:43f9

If they truly act as a proxy/cache, then the backend of that connection could be IPv4/IPv6 and/or HTTP/HTTPS.
I don’t really know how CloudFlare works.
But they will need to provide an SSL cert to cover your domain; for the clients that will hit their servers for HTTPS.
Which at the moment they already are:

DNS Name=*


For dual-stack origins, Cloudflare prefers IPv4. (For IPv6-only origins, Cloudflare uses IPv6.) The IP version between the client and Cloudflare, and between Cloudflare and the origin, aren’t related.

Edit: By default, Cloudflare’s caching shouldn’t be an issue. They only cache certain file extensions. And even for those file extensions, 404 errors are only cached 5 minutes. But that’s all configurable, via Cloudflare’s settings and cache headers from the origin.

Edit: Actually, 404 errors can’t be cached for more than 5 minutes. I think.

But the clients will never see his cert - only the CloudFlare cert.

Can you explain this statement?
Even if possible (aka: MITM Transparent SSL Proxy); they would NOT be able to cache any SSL content since they can’t see it. Defeating the whole point of the CloudFlare solution.

yes…when my site was on the old server, I had a cert via let’s encrypt as well as a cloudflare issued cert for end-to-end encryption. when I moved to the new server, after not being able to get a cert issued cleanly from certbot, I set SSL in cloudflare from full (strict) to off. I’m still unable to get any certs from let’s encrypt…

Try adding one of these:
–preferred-challenges http
–preferred-challenges http-01

both failed with the same errors as before.

What do you see in your logs?
Both of these show 404:

Surprisingly this works:
redirects to

FYI: certbot won’t follow HTTPS redirects.

You seem to have two vhost files or are missing the server_alias for www
And you should probably turn CloudFlare SSL back on (if there is a less than strict mode, use it for now)

In NGINX use:

1 Like

ah, that was it!

I forgot to set up a redirect in nginx for www!

adding this to my vhost was the ticket:

server {
    return 301 $scheme://$request_uri;

thanks everyone for the help!

sorry to bump this again gents but I’m having another problem for a different cert renewal for a different domain name on the same server.

I’m trying to renew my certs. when I run the renew command:
certbot renew --post-hook “systemctl restart nginx ; systemctl restart postfix” >> /var/log/le-renew.log

I get the following:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert not yet due for renewal
Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1):
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
http-01 challenge for
Waiting for verification…
Cleaning up challenges
Unable to clean up challenge directory /path/to/site/public_html/.well-known/acme-challenge
Attempting to renew cert from /etc/letsencrypt/renewal/ produced an unexpected error: Failed authorization procedure. (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Timeout. Skipping.
Running post-hook command: systemctl restart nginx ; systemctl restart postfix
1 renew failure(s), 0 parse failure(s)

what would cause a timeout? I can manually browse to the directory: is set up for postfix and to use as a PTR record.

when originally generating the certs, I ran the following command:
certbot certonly --email --text --renew-by-default --agree-tos --webroot -w /path/to/site/public_html -d -d -d -w /path/to/site/2/public_html -d -w /path/to/site/3/public_html -d

If I run the above the generate a new cert with --dry-run and remove -d, it goes through just fine!

edited to add:
I don’t have anything set up in an nginx vhost for, but I believe because I have default_server set up for the main domain,, it sends anything that doesn’t have a vhost through the main domain. I run a near identical set up on another server and it works just fine!

If this is not how it works, forgive me as I’m a sys admin in training during my free time!

any help is greatly appreciated! has an IPv6 AAAA record but no web server responds at that address.

for some reason, my ipv6 address isn’t pinging from my server. contacting my host…

hopefully once that’s resolved, this will be fixed up!

thanks for the reply…

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