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?
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!
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:
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.
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:
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/DCV.pm).
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.
