As per title, for some reason I'm unable to connect the deployed app on Amplify to a custom domain provided on Route 53.
Here's the app deployed with Amplify: https://master.dwog1beoc1uv7.amplifyapp.com/
On Route 53, I created a hosted zone and added a CNAME record which should connect the custom domain to the domain where amplify hosts the app:
I then went to Amplify and added a new domain for the application:
If I now go back to Route 53, I can see the records have been automatically updated as followed:
Although everything seem setup properly, the custom domain (http://alessiopetrin.com/) doesn't work just yet.
If I test the record on Route 53, all seem fine:
I understand I should allow some time for the DNS propagation to take effect (up to 24h for what AWS states), but the time is almost up and I can't see it working, which make me think something is off.
As per second screenshot, I can see on Amplify that is waiting me to add the CNAME record in order to activate the domain, so I may think that could be the missing piece; Problem is the record has been assigned automatically already on Route 53, so not really sure if I should add the record somewhere else as well?
Apologise if I'm asking something obvious, and thank you in advance for the help!
The records added by Amplify are correct. I executed dig command on your domain and observed "SERVFAIL" status. This error is due to the mismatch in the name servers.
The following name servers are used currently.
ns1.dynadot.com
ns2.dynadot.com
Ref: https://www.whois.com/whois/alessiopetrin.com
Please set the name servers to the NS record of hosted zone (https://i.stack.imgur.com/U6Lj8.png). Refer below docs:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-name-servers-glue-records.html#domain-name-servers-glue-records-adding-changing
Then, delete the domain from amplify and try re-adding it. It should work.
Be careful that the require cname ask by aws to generate the SSL is mandatory and should has the following form :
An obvious error in Route53 is that Value/Route traffic goes to https://master.dwog1beoc1uv7.amplifyapp.com/. When you add CNAMEs, you don't add the protocol, but only the domain name. It should be master.dwog1beoc1uv7.amplifyapp.com
EDIT
There is a problem with the Cloudfront Distribution. I can't tell, if this is because something you did or it is an amplify problem. You need to somehow debug the distribution. Go to Cloudfront service in AWS console and locate your distribution. Some things to check:
Alternate domain is correct (your custom domain)
SSL certificate is correct
Go to behaviors tab and click edit:
An S3 bucket with your code should be used as an origin
There should be no caching on Headers
Related
I'm automating a deployment of a static site to AWS, including the following:
Uploading static content to an S3 bucket.
Creating a hosted zone in Route 53.
Creating an SSL/TLS certificate in ACM.
Placing the certificate validation records in Route 53.
Creating a CloudFront distribution using the ACM certificate.
Adding Route 53 records to point to the CloudFront distribution.
Everything seems to be automatable, but there's a little snag: at step #5, creating the CloudFront distribution, the certificate has just been created and hasn't been validated yet, so creation of the CloudFront distribution fails. Moreover even waiting for validation won't help, because to be validated the domain's DNS must be updated to point to the name servers for the hosted zone, which aren't known until step #2 when the hosted zone is created.
As I am using a third-party domain registrar, I don't know ahead of time what name pervers to indicate for the domain until completion of step #2. But then step #5 cannot complete until the certificate is validated, which requires updating the name servers with my domain registrar. So I have a chicken-and-egg problem.
Is there any way to tell CloudFound to create the distribution even though the domain is "invalid" (not yet validated), so that after everything is finished I can go update my domain registrar with the name servers for the created hosted zone? Or must I stop this automated process in the middle after creation of the hosted zone, and then come back and complete it later after updating the name servers?
Any other ideas to work around this problem? (Yes, I know I can use Route 53 to register the domain as well, and then probably update the name servers automatically, but I want my automated tool to work with third-party registrars.)
I don't believe you will be able to configure Cloudfront until the domain is registered and AWS can validate that you control the DNS.
There are a few security issues that AWS has been working to resolve - see https://aws.amazon.com/blogs/security/enhanced-domain-protections-for-amazon-cloudfront-requests/ - and it sounds like you will be prevented from doing what you are attempting to do.
I recommend your steps should be:
Create an S3 Bucket
Upload your static content to the bucket.
Create a "placeholder" CloudFront Distribution using bucket from Step 1 (no cert needed; this is your egg)
Create your hosted zone in Route 53.(old step 2)
Create an SSL/TLS certificate in ACM. (old step 3)
Place the certificate validation records in Route 53 (old step 4)
Update your CloudFront Distribution created in step 3 when your cert is done. your chicken!
and on.. remaining automation steps to complete
The minimal requirements for creating a CloudFront web distribution are small. One bucket will do. Go into the console and try for yourself, its simple. Once the distribution is created it can sit idle until your other steps are complete with AWS and your third-party registrar. Then you update the distribution with your fully baked cert. Because this is possible via the console, and all console actions are backed by API calls, means that you can automate this.
Take a look at the create CloudFront API call requirements compared to the update CloudFront API requirements. You can create a distribution without a valid certificate. However for updates to that placeholder distribution, you will need all of the required fields, to include the ViewerCertificate.
Keep in mind when building your automated tool, if you get stuck with the API, try the action in the console to determine/reverse engineer the values needed to pass into the API calls.
I'm following the serverless-stack guide and have a website hosted in an Amazon S3 bucket. I purchased a domain using GoDaddy and I have set up cloudfront to work with this bucket, then have used AWS certificate manager to generate SSL certificates for my domain (both www.my_domain.com and my_domain.com).
In GoDaddy I then configured DNS forwarding to point to my cloudfront resource.
This all works nicely, and if I go to my_domain.com in a browser then I see my website.
However, I can't get SSL working. If I go to the https:// version of my website then I see a not secure error in the chrome address bar which shows a certificate pointing to shortener.secureserver.net rather than my own website.
Could someone point me at a way around this? Looking through S.E. and using google it seems that Amazon's route53 might be able to help, but I can't figure out how to do this.
Thanks!
(edit) To make things more clear, this is what I see in Chrome if I connect to https://my_website.com or to https://www.my_website.com
The warning message:
The certificate details:
What I do not understand is why, after configuring an AWS certificate for my domain, I see a certificate for shortner.secureserver.com rather than a certificate for my_website.com.
Go daddy has problems and does not redirect to https, There are two ways, the first is to change domain registrar and the second is the easiest, which is: Create a hosted zone on AWS router 53 with your domain name
Create 2 type A records, one for the root (of your domain) and one for www that point to your cloudfront. Router 53 allows you to create a type A record without having an IP, because it directly points to a cloudfront instance that you indicate, that's the best
Then in go daddy it gives you the option to change name servers and puts the ones assigned by aws in hosted zone with the record that says NS and you put those 4 in Godaddy, replacing the ones that had
Note: SAVE THE NAME SERVERS THAT YOU HAVE IN GO DADDY BEFORE REPLACING THEM, IN CASE YOU HAVE ANY PROBLEM, YOU CAN REPLACE THEM AGAIN
You have to wait at least a few hours until all the name servers are updated, you can use the who.is page to see if the DNS have already been updated with those of aws.
It turns out that this is not possible with GoDaddy. If anyone else reading this has a similar problem, only current solution is to cancel your domain registration and register with someone else.
(edit) As #aavrug mentions in their comment, Amazon now have a guide for this.
When you defined your CloudFront you can defined whether you want to use, and you can choose HTTPS only. In this case HTTP requests will be automatically redirected to HTTPS. Have in mind CloudFront changes may take a while to be replicated and your browser cache it as well, so the best way is to make a change, wait for the deployment and then check it in a new cognito browser.
It goes without saying that your certificate must be valid and verified as well.
It might be something wrong with your certificate or with your domain.
If you serving your content over HTTPS you must provide a SSL Certificate in Cloudfront. Have you done that?
Have you added your domain on Alternative Domain Names (CNAMEs)?
Please have a look on the image below:
-> AWS provides Free SSL Certificates to be used with Cloudfront, so you might want to use it (easier than you import your SSL from go daddy).
You can create a free SSL certificate on AWS and easily attach it to your cloudfront distribution.
-> You can also transfer your domains to AWS Route53. It is easy to integrate with any AWS Service and easy to use/maintain :)
I wrote a complete guide on my blog telling how you can add Custom SSL and attach custom domain to Cloudfront distribution, it might be useful :)
https://lucasfsantos.com/posts/deploy-react-angular-cloudfront/
at the first place, we hosted our React App on the S3 to which we assigned CloudFront distribution and then we connected it to somedomain.com domain.
The thing is that for marketing tests we had to change A-record in Route53 to point to a totally different server than AWS. So the problem is that some of the users already used our React App with ServiceWorker that was hosted on S3, and even that we changed A-records to point to different server - they still see AWS cached version.
We have no idea where is the problem, and if we should change something in Route 53 or Cloudfront?
I have come across this before, but don't have a good explanation as to why it happened.
I had to remove the domain from the CloudFront distribution before I got all traffic being sent correctly to the new record in Route 53.
After removing the domain from the CloudFront config, traffic immediately started being sent to the value in the A record in Route 53.
Hope this helps.
Our project is deployed on Elastic Beanstalk and I want to run this on HTTPs. I created my certificate on AWS Certificate Manager and choose DNS verification option. I added provided data in my Godaddy DNS records. Below is my sample data
Domain Name | Record Name | Record Type | Record Value
example.com | _8046ecb910c52234234234234232ecae.example.com. | CNAME | _81b05686qweerttcxsaxasdadas5a566.tljzshvwok.acm-validations.aws.
*.example.com | _8046ecb910c52234234234234232ecae.example.com. | CNAME | _81b05686qweerttcxsaxasdadas5a566.tljzshvwok.acm-validations.aws.
AWS has given my two records for example.com and *.example.com but both records are same. So I added one CNAME record in Godaddy DNS entries. I waited for three days and my certificate was still in pending state which in the end expired. I created a new one and I have been waiting for 24 hours and it is still in pending state. I cannot use Email verification method as I am not owner of this domain.
An apparently common error is to paste the entire hostname into a box that does not expect an FQDN, thus creating a record that actually looks like this in DNS (though you may not observe it this way on the screen):
_8046ecb910c52234234234234232ecae.example.com.example.com
For the "hostname," just use _8046ecb910c52234234234234232ecae when creating the record.
After creating it, use dig or nslookup to verify that it resolves as expected.
I had similar issue with AWS certificate in 'Pending validation' state for quite some time. After few tries I finally got it to get in 'Success' state. It might vary by domain registrar , in my case it was NameCheap.
Refer the screenshots from AWS ACM and NameCheap to follow the step that got it working for me:
I also had this issue and waited a day but still Pending Validation. I followed answers here but still got confused and Pending Validation so I decided to share the step by step of what worked for me in NameCheap.
In AWS:
Export the DNS configuration file. It will have something like this.
Domain Name,Record Name,Record Type,Record Value
mysite.io,_beocc4be975f27599f5d77f87af84321.mysite.io.,CNAME,_6ae531c5dad6c5ceeefd65a73d532881.dumrqilasr.acm-validations.aws.
In NameCheap:
Choose "Domain" tab > NameServers - Choose NameCheap Basic DNS
Choose "Advanced DNS" tab > Host Records
Under Type, choose "CNAME record"
Under Host, use the value in "Record Name". Do not include the domain name.
_beocc4be975f27599f5d77f87af84321.
Under Value, use the value in "Record Value". Copy everything.
_6ae531c5dad6c5ceeefd65a73d532881.dumrqilasr.acm-validations.aws.
Under TTL, choose "Automatic"
Save the settings by clicking the check icon right beside TTL.
In AWS:
Refresh the AWS Certificate Manager after 2-5 minutes. It should only take a few minutes for Amazon status to change from Pending Validation to Issued.
I have the same pending-forever issue with the domain which I registered at Freenom because I forgot to set the name servers from AWS Route 53 to Freenom.
Name servers from AWS Route 53:
*(ns means name server)
Set the name servers above to Freenom:
Then, it was validated from pending. However, even if I set name servers to Freenom, it sometimes takes a forever time to be validated. In this case, I delete the request and make a new request a few hours later again, then, it is validated properly.
Optionally saying, we registered the domains at the domain providers like GoDaddy, Namecheap, Freenow and so on, then, we need to set the name servers from AWS Route 53 to GoDaddy, Namecheap, Freenow and so on. Finally, our domains will be validated from AWS Certificate Manager.
I needed the same solution as #Kai - had to add the NS records to the primary domain. But my situation was a little bit different:
I'm using AWS Route53 for my domains
with the root domain (example.com.au) in a different AWS account
and a subdomain (subdomain.example.com.au) in the account where I'm creating the certificate
Because it's all within AWS I could just click the "create record in Route 53" button to get the verification record automatically added... but the certificate would not resolve
THE PROBLEM : the subdomain was not resolving through to the root domain
HOW I FOUND IT : dig +trace subdomain.example.com.au
that SHOULD return a string of responses from . then au. then com.au. then example.com.au. and finally subdomain.example.com.au.
it did not return the subdomain record, which was the clue that the link between the subdomain and the root domain was not correct.
adding the NS records from the subdomain as a CNAME record on the root domain (similar to Kai's answer) caused the validation to complete almost immediately.
That is my api gw with cloudflare! It works already.
I did setup the Cognito Hosted UI, but currently, to be able to access the login screen, we have to visit this pretty ugly link
https://{...}.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id={...}&redirect_uri={...}
Thats not exactly what we want, we would prefer something much cleaner (such as login.ourdomain.com, with all parameters which are not relevant to our customers obscured). We hope for something like Route 53, where we can setup nice links for our Elastic Beanstalk apps.
So I would like to ask - is this possible? And how? The information on this subject is very scarce - in one post, we learned that TLS certificate is necessary for this. We have it, but still have no idea how to set it up.
Thanks a lot.
Yes it is possible to use your own domain for this. I'm going to assume you want a subdomain e.g. id.your-domain.com.
First you need to have a certificate in Amazon's "AWS Certificate Manager" for the subdomain you want to use. You can create or import a certificate in the ACM and it is quite easy to do using the console if your domain is registered via AWS. In my experience the certificate MUST be in the us-east-1 region no matter which region your user pool is in.
Once you have the certificate in the ACM go to your domain config for the hosted UI and there is a section "Your own domain" where you can enter the subdomain and select the appropriate certificate. When you click the button to create it will create a cloudfront distribution for this subdomain (with the AWS hosted UI) and give you the address of the distribution (Alias target) - copy this down. Note that it may take a few minutes for the cloudfront distribution to spin up.
Go to route53 (or however you configure DNS) and add in a record set for the domain. It should be an A record, which is an alias to the cloudfront distribution you noted above (Alias target). Create the record and go make a coffee and in 15 minutes DNS and cloudfront have hopefully sorted themselves out and you can use your domain for the hosted UI.
e.g. https://<your-domain>/login?response_type=token&client_id=<client-id>&redirect_uri=<redirect-uri>