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
Related
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?
I have a REST API on a Hetzner server which uses Varnish. I am trying to set up Cloudfront to use as the CDN for it. After reading around, I currently have the following setup:
Hetzner / Varnish
A main API route api.mydomain.com.
Config in Varnish for cdn-api.mydomain.com to also act as a route to the same API.
In the DNS for the domain in Hetzner, for cdn-api.mydomain.com I have
added the name servers for Route 53.
Route 53
Hosted zone called cdn-api.mydomain.com.
An A record with name prod.cdn-api.mydomain.com which points to my Cloudfront distribution.
An A record with name cdn-api.mydomain.com which points to the IP address of the server.
Cloudfront Distribution
Has the alternate domain name prod.cdn-api.mydomain.com.
Has the origin domain of cdn-api.mydomain.com
Protocol for origin is HTTP only
What I think should happen
Make a request to prod.cdn-api.mydomain.com.
Route 53 forwards to the Cloudfront distribution.
CloudFront looks to origin cdn-api.mydomain.com.
Origin cdn-api.mydomain.com looks to IP address of Hetzner.
Hetzner receives request, Varnish allows the domain through, sends back data to Cloudfront.
What actually happens
If I make a request straight to cdn-api.mydomain.com from Postman, it works if I turn off SSL.
If I turn on SSL, I get the error SSL Error: Hostname/IP does not match certificate's altnames, saying that cdn-api.mydomain.com is not on the certificates of the server.
If I make a request to prod.cdn-api.mydomain.com, I get the error Error: Exceeded maxRedirects. Probably stuck in a redirect loop. Which may be due to the same certs error.
Cloudflare
As a comparison, we have Cloudflare set up as the CDN for a different domain on the same Hetzner server. It has:
A main API route api.myotherdomain.com
In Hetzner a CNAME for cdn-api.myotherdomain.com with value cdn-api.myotherdomain.com.cdn.cloudflare.net.
In Cloudflare, an A record for cdn-api.myotherdomain.com which points to the IP address of the server.
cdn-api.myotherdomain.com is set up in Varnish as an entry point, but is not on the list of certificates of the server.
This all works fine including with SSL enabled.
It would be good to understand what I'm doing wrong here.
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 using Github Pages as my hosting site for my domain. The pages are hosted at username.github.io. As per github pages documentation I have put the CNAME file in the root directory pointing to example.com
And in my godaddy DNS manager I have added CNAME www to username.github.io
Later I switched to CloudFlare to use the Universal Free SSL for my Github Custom Domain page.
Currently the CloudFlare DNS Manager includes these two items:
A exmaple.com 192.30.252.153
CNAME www username.github.io
Since I have enabled SSL in cloudfare and redirect http (naked or otherwise) addresses to https, I have put a Page Rule as http://*example.com/* with Always use https turned on.
Now all types of addresses are getting redirected to https://example.com (this is my end requirement)
However the 301 redirection from http://www.example.com to https://example.com is happening this way:
http://www.example.com to
https://www.example.com/ to
http://example.com/ to
https://example.com/
This multiple redirection will affect the site loading speed if a user types the address as www.example.com. And (possibly?) these multiple redirections will affect page ranking in search sites.
Hence is it not better to put direct 301 instead of multiple? Or using multiple redirection is what normally all web-masters do in a situation like this?
If no, then someone please guide me to enable the 301 redirection from http://www.example.com directly to https://example.com/ without any multiple redirections.
You can set Page Rules in CloudFlare and change the order to your intended effect.
If this is still problematic you can also enable HSTS which will require the browser to access the HTTPS version after the first time you visit the site. This also makes the site more secure by not allowing anyone to man-in-the-middle your secure connections.
I created an S3 bucket and enabled "Redirect all requests to another host name" under "Static Website Hosting".
This works and when I visit http://www.XXXX.com.s3-website-us-east-1.amazonaws.com, I am redirected to my end destination.
If however, I try to access the same URL over HTTPS: https://www.XXXX.com.s3-website-us-east-1.amazonaws.com, the connection times out.
Is it possible to specify an SSL certificate to use so that the redirect can handle HTTPS traffic?
With S3 by itself, no, it isn't possible. The web site endpoints don't speak SSL at all, and the REST endpoints don't handle redirects or allow any cert other than the *.s3(-region).amazonaws.com cert.
However, you can do it with CloudFront and S3 combined, if your clients support SNI.
Create a CloudFront distribution, configured with your hostname and SSL certificate, but don't use an "S3 Origin." Use a "custom origin" and that origin is your S3 web site endpoint hostname, with all requests forwarded to the origin using http (even though it's https on the front end).
If you are not familiar with CloudFront, this probably sounds a little convoluted, but I use it for exactly this purpose (among others).
Requests hit CloudFront, which allows you to use your own SSL cert... and then CloudFront forwards the request to S3, which returns the redirect, which CloudFront will cache and return to the requester (as well as to future requesters hitting the same CloudFront edge location).
The cost for this extra layer is negligible and you should not see any meaningful change in performance (if anything, there's potential for a slight speed improvement).