I’m having issues with some subdomains forcing HTTPS even when they don’t have or need a certificate. The strange thing is this is only happening on a few domains, but works perfectly on most of them even when the settings are identical as far as I can tell.
Specifically I set up a subdomain as an alias of sendgrid.net to allow link tracking. Sendgrid rewrites the url’s in the emails to point to that subdomain and then redirects the user to the actual url. This Sendgrid server supports HTTP only.
For most domains when I click on a link in an email to the links.domainname.com it redirects me to the actual url with no problems. For a few domains it redirects to HTTPS which then causes a “Your connection is not private NET::ERR_CERT_COMMON_NAME_INVALID” error in Chrome. I don’t think this is happening on Sendgrid’s servers, so it must be Cloudflare.
I am using Cloudflare only for CNAME flattening and managing DNS entries so nearly everything is disabled or left at default settings. Traffic is not routed through Cloudflare on any subdomains. SSL is set to flexible and all certificates are installed directly on the various servers we use.
Any ideas what I should check and what the difference might be that causes some domains to work fine and some don’t? Thank you!
Ignore the spaces in domain names because the spam filter is catching them.
http:// links.domainname .com is the link url they click on in the email which is an alias of sendgrid .net. This link gets changed to https:// links.domainname .com which doesn’t work because sendgrid’s server doesn’t have our domain’s SSL certificate so they get a security warning. On domains where this does work, it hits the http:// links.domainname .com, tracks the click, and then instantly redirects to https:// domainname .com and works fine.
Alright, I am still not quite sure I understood the whole picture but from WHAT I understand I have the impression you have HTTP links in your email, which suddenly get rewritten to HTTPS ones. Is that correct?
Have you checked how and where that rewrite takes place? Can you post such a link? That would make it easier.
The links in the email show as http:// the redirection to https:// happens in the browser when the connection is made. This is the server http://links.illuminent.com/ which without a redirect url should show “404 Not Found nginx” but instead in Chrome shows a security warning.
Well, a redirect does not simply happen (unless here is HSTS magic involved ). Can you check if you get that redirect from your server? Can you post such a link that gets rewritten?
I only see one zone under this account on Cloudflare and all of it’s DNS records are so Cloudflare isn’t proxying any traffic for those host names. Instead we are simply returning whatever the value is in DNS. So if there’s an error it isn’t being generated by Cloudflare.
Although in your DNS you have a bunch of CNAME entries that don’t appear to make any sense. They are in the format of otherdomain.com so that translates to a DNS entry of otherdomain.com.mydomain.com which is technically a valid DNS entry… but uncommon enough that I think it represents something other than what was perhaps intended.
Thank you for your help. I think we found the problem was the the naked https://illuminent.com domain (which is on a completely different server and has nothing to do with sendgrid or the subdomain we are linking to) had this in the HTTP headers: strict-transport-security: max-age=31536000; includeSubDomains which apparently is still checked even if you are never visiting the naked domain.
). Can you check if you get that redirect from your server? Can you post such a link that gets rewritten?
so Cloudflare isn’t proxying any traffic for those host names. Instead we are simply returning whatever the value is in DNS. So if there’s an error it isn’t being generated by Cloudflare.