I allow users to map a custom domain to my site which tracks when someone they send an email to gets opened using a CNAME DNS entry. So open.mywebsite.com is mapped to open.userwebsite.com
When a user gets an email I need to display the image using HTTTPS, I have set up a HTTP to HTTPs redirect using google cloud load balancer and have a SSL cert for open.mywebsite.com. The problem is my SSL certificate is not valid for open.userwebsite.com and as such the tracking image does not always load or shows an cert error.
I'm not sure if it is possible to have a SSL cert that would be valid for both the user website and my website without any warning? Or if anyone could suggest an alternative networking / DNS configuration?
Related
I have my Github Pages set up with a custom domain: mark.gg. This domain is set in the CNAME file in the repository. The Enforce HTTPS option is also on.
I use Cloudflare for DNS and for the mark.gg domain I have the four A records and one www subdomain CNAME record set to point to Github. Everything works fine if I access my site on www.mark.gg, mark.gg, http://mark.gg, https://www.mark.gg.
In the Crypto section of Cloudflare I have SSL set to Full, Always Use HTTPS set to On, Onion Routing set to On, and Opportunistic Encryption set to On.
I'm having issues getting order domains to redirect to mark.gg through Cloudflare. For example for my markcerqueira.com domain, my current DNS setup is:
The 1.2.3.4 is a dummy IP address. The key here is I have the traffic routing through Cloudflare so I can have it trigger a Forwarding URL Page Rule:
I used to have just one Page Rule that forwarded *markcerqueira.com/* to https://www.mark.gg and that didn't work so this image is just the most recent stab in the dark.
The Page Rule works as I see the address updated to mark.gg when I visit markcerqueira.com but I get an insecure connection error: SSL_ERROR_BAD_CERT_DOMAIN.
At this point, unsure if I'm just missing some option or what I'm trying to do is impossible via just solely Cloudflare.
The issue was rooted in the SSL setting available in the Crypto tab. I had SSL set to Flexible under the (very incorrect) assumption that Flexible SSL would be less error-prone compared to Full or Full (Strict). Flexible SSL forbids HTTPS at the origin which is what Enforce HTTPS via GitHub Pages enables. Turning the setting to Full or Full (Strict) clears up my redirect issue. For good measure here are all the Crypto settings I have configured for my redirecting domain that currently work without issue:
SSL - Full (Strict)
Always Use HTTPS - On
Authenticated Origin Pulls - On
Minimum TLS Version - TLS 1.0
Opportunistic Encryption - On
Onion Routing - On
Automatic HTTPS Rewrites - On
I am using guthub pages to host a simple website with a custom domain. To manage the the DNS I am using CloudFlare.
I had pages rules setup on CloudFlare for forwarding to my google drive file:
example.com/pdf Foreward rule code 301 https://drive.google.com/file/d/ZZZZZZZZZZZZZZZZZZZ
A while back I enabled HTTPS for my custom domain. Domain is assigned to the guthub page using CNAME and on the github settings page I have enabled Forced HTTPS
I only recently noticed my short links to the google drive files were down.
Is this due to HTTPS? Can replicate forwarding to foreign domain effect without compromising on HTTPS?
You need to make sure that site-wide SSL is reflected in the rule, because Cloudflare first enforces the SSL and only then processes the rules.
https://example.com/pdf 301 https://drive.google.com/file/.........
I am setting a webhooks for a Facebook application, and they required a call back url, this url must be in https
I do have a server with a call back website but it is not https, it is in http protocol
Any idea to bypass that? (work around? )
There's no way to bypass it.
However, if you don't want to buy SSL certificate for your domain, you can configure your domain name with CloudFlare and use their universal ssl.
I have used it with facebook webhooks and it works very well. It's free and very easy to configure.
The free plan allows you to use Flexible SSL. As per the docs:
Flexible SSL: secure connection between your visitor and CloudFlare, but no secure connection between CloudFlare and your web server. You don't need to have an SSL certificate on your web server, but your visitors still see the site as being HTTPS enabled.
I need to develop a Facebook app, and while I request my SSL certificate, I need to start the project because I have few time to deliver it.
Is it possible to use localhost as the "Secure Canvas URL"? This field requires that the URL begins with https, so I don't know the correct way to do it (in the case that using localhost is allowed).
First of all you need to set up your server to answer HTTPS requests.
Then you create a self-signed SSL certificate – not sure if that works for the domain name localhost, but I’d recommend setting up a local domain, such as mytest.local anyway (the .local being the important part here), make your server listen to that, and your system resolve it to your local IP address, f.e. via its hosts file.
And then you tell your browser to accept that self-signed certificate … and you’re good to go.
Recently, the company I work for changed their name, and therefore is changing its domain name. Previously, we redirected all requests on port 80 of our web server to https : //www .olddomain.com, so that all pages were sent over SSL. Now that we have changed, our SSL certificate for www. olddomain.com has expired, and we want to redirect all requests for https : //www. olddomain.com to https : //www. newdomain.com (in case anyone bookmarked us as https : //.....).
I have tried every redirection method I know, mod_rewrite, DNS forwarding, etc, but I cannot get https : //www.olddomain.com to redirect to https : //www.newdomain.com, it says that the site is untrusted.
We are running Apache 2.2 on linux.
Any help would be appreciated.
Thanks!
Not to dive into unnecessary details - if certificate itself has expired, you won't be able to make trusted connection with it, browser will always warn. To make it transparent, you'd have to renew/buy valid certificate for old domain, or force any possible website user to first download, install and trust your own RootCA certificate (obviously impossible). Theoretically there are some browser-supported HTTPS protocol extensions to deal with original construction of https, but even if they were implemented it still won't "help" for outdated certificate. It is problem with certificate itself, not really with virtual server hostname / certificate common name recognition and matching for which such protocol extensions are conceptually planned/designed.
You should have been performing domain migration during time when old certificate was still valid. Have a look here CNAME SSL certificates as well.