autoSSL DCV vs Let's Encrypt DCV


Newbie here. Started with autoSSL in cPanel and hit an issue I can’t get around. For many reasons I must redirect non-www domains to www. This has to do with using AWS S3 as an alias along with Route 53, to keep hardcoded IP addresses out of A records. I can’t unwind this now.

I have root access to my Apache/CentOS hosting service. I normally use WHM/cPanel, and gave autoSSL a try - but ran into this problem:

When autoSSL does the domain validation, it writes the file to .well-known/pki-validation/ – then it requests the file from the domain/URI – without the www prepended. My routing then sends it to the URI with www, along with a 302 redirect.

autoSSL then says “sorry I detected a redirect. Certificate issue failed” (paraphrasing here…)

I can’t get around this. If I try to get Let’s Encrypt up (via Certbot) – am I going to run into this same issue with DCV?


The Let’s Encrypt authentication servers follow redirects just fine.


Autossl is showing you that issue due to their settings, however certbot would not have this issue.

P.S. autossl behavior could be modified by the host… but it would still not change the status.


Thanks…I believe the sensitivity to redirects is on the Comodo side (the provider for cPanel/autoSSL). I have some more questions about my use case overall; will post another topic…thanks!


If you’re not aware, there is an AutoSSL provider available for Let’s Encrypt.

In my experience AutoSSL tends to make some assumptions about DCV to the benefit of the Comodo provider (like the non-existence of IPv6 …), but it might still work for you - probably worth a try rather than falling back to Certbot.


Thanks - I tried it. The problem here is not that Let’s Encrypt can or cannot follow redirects for the DCV. It appears that the problem is cPanel/autoSSL itself. I am still getting this autoSSL error:

WARN Local DCV error ( The system queried for a temporary file at “”, which was redirected from “”. The web server responded with the following error: 404 (Not Found). A DNS (Domain Name System) or web server misconfiguration may exist. The domain “” resolved to an IP address “” that does not exist on this server.

So long story/short - I can’t stay on AWS with S3 as an alias for the A record - it will always introduce a 301 redirect. I’m going to have to go back to hardcoding my server’s IP address in all my customer’s A records…sigh…

I tried this with one of my customer domains as an experiment and it worked fine. It just stinks that I have to abandon AWS S3 as a key part of my routing topology.


This seemed suspicious to me.

I can confirm that Comodo doesn’t work. The important log message:

ERROR “cPanel (powered by Comodo)” forbids DCV HTTP redirections.

I tried the same with the Let’s Encrypt provider. No warning message as with Comodo, but I think the local DCV check reporting a 404 is bogus. cPanel never actually generates the supposed DCV request to the local server.

So I popped open Wireshark to see wtf is going on.

The first local DCV check goes out to S3 and receives a valid 301 redirect.

However, after the redirect, the cPanel server followed the redirect, except it didn’t use the IP of the redirect target. It used the IP of the initial host it sent the request to:

This is a bug in AutoSSL’s local DCV check. It’s losing track of which IP to send the subsequent request to and is sending it to S3 again.

Hate to quote myself, but:

Report this to cPanel, if you want.


Wow - thanks for that awesome diagnostic…very cool. I was doing similar with CURL and saw that the redirect did report AWS S3 as the server/IP – and figured that what autoSSL was doing was saying hey…if we get a redirect and the server IP also changes – then full stop. I think if the IP address of the redirect matches the original then it will work. Apparently starting in early 2018 they tightened this, and it’s driving the CloudFlare users nuts as well.

I can report it but I have a feeling they will say it’s working as designed. Maybe I’m wrong.


It’s not upto AutoSSL to determine what the redirect policy of the CA is. If this was an intentional policy, then why would they send another request at all, that was guaranteed to fail? I believe they will accept it as a bug.

I think they just overlooked this when they were dealing with cPanel servers behind NAT interfaces (from what I can tell of the code in /usr/local/cpanel/Cpanel/SSL/


Makes sense. Thanks again, I really appreciate the thought put into this.

I will report it as you describe; no idea if/how/when they will consider the request. In the meantime I have a workaround of hardcoding the IP address in my Route53 A records…lousy workaround but it does work.


Note that the newest release of the AutoSSL/LE provider will forgo the “pre-flight” HTTP check that seems to have caused the issue here.

That said, thank you for this analysis.

The grand majority of cP administrators use the default (Comodo-backed) AutoSSL provider; however, cP does actively maintain its LE plugin.


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