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.
Related
I have a ALB set up behind a cloudfront distro. I have a rule to redirect an HTTP request to URL A to URL B which is not on AWS infrastructure.
When I query the ALB directly for URL A, the load balancer properly redirects to URL B. When I query a cloudfront endpoint for URL A, I get a 403 error back. Per the troubleshoot 403s aws doc, it seems the issue is that I don't have an alternate CNAME configured for URL B. However, since it's not on my SAN certificate that's associated with my CloudFront distro, I can't add it to the list of alternate CNAMES. is there a workaround to allow requests to URL A to properly travel through my cloudfront distro and get redirected? It doesn't make sense to me that I can't do this for an HTTP request.
verified that the ALB can be queried directly and redirect works
tried to add an alternate cname for http domain
removed wacl on alb to make sure that wasn't blocking it
I have an application that runs fine in AWS App Runner and can be found here: https://iyarles.net
However, it's not accessible via the naked domain name iyarles.net.
Clarification comment: If I goto iyarles.net in my browser (edge), the request times out. If I goto iyarles.net, my website loads fine.
The App Runner service has a custom domain configured and my hosted zone has the 2 certificate validation records and the alias record pointing to my service.
A few weeks ago I transferred my domain from Google Domains to Route 53. It was originally a redirect from iyarles.net or any other subdomain (with or without https://) to the default domain for my service.
How can I replicate the previous behavior? What exactly are these alias records doing?
When you type the hostname into the browsers address bar, browsers will assume you want to make a plain HTTP request.
When you explicitly include the https: scheme, browsers will make a secure HTTP request.
Your server is running an encrypted service on port 433. It is not running a plain service on port 80.
It times out if you type http://iyarles.net too.
The issue is that the custom domain configured in AWS App Runner is not accessible via the naked domain name, iyarles.net. To replicate the previous behavior, you will need to create an Alias Record in your hosted zone in Route 53, which will point your domain name to the service URL.
The Alias Record is used to route traffic from a domain name to the service URL. It will ensure that any requests to the domain name will be routed to the service URL, thereby allowing your application to be accessible via the naked domain name.
It is important to note that you will also need to create two Certificate Validation Records in your hosted zone in Route 53. These records are used to validate the SSL Certificate for your domain name, which is necessary for HTTPS connections.
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 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).
i recently migrated my application to AWS and setup a cname for www.domain.com and a redirect for the domain.com to redirect to www.domain.com.
The problem is, an external service was using a path on the naked domain.com (something like domain.com/external/service/) But with the redirect all HTTP POST data is being dropped with the redirect and i cant change the url that the external service is calling.
To fix this, i have setup my naked domain on route53 to point to my elastic load balancer where my app is located. I set up an A record pointed at my elastic load balancer using an alias.
Its been two days now and my naked domain still redirects to www. and therefore the external service is down. Any ideas on what i could do?
I am taking a long shot - there are different possible problems:
You are forwarding naked domain via A record to ELB, but your EC2 instace (say Apache) is still doing a redirect (not DNS, but http 301) back to www.
Check the DNS TTL. If the TTL is too large (say 48 hrs), then it takes that time. You need to wait longer.
Is Route53 fully managing your DNS? One possibility is that, somebody else like Godaddy is still doing the DNS for you - so nobody is contacting Route53 for the change to reflect.