I am trying to set cognito up with a custom domain.
I have a registered domain name, hosted zone with route53. let's say mydomain.com.
I also created certs for mydomain.com, *.mydomain.com in us-east-1 (N.Virginia) as document instructs.
When I tried my domain, cognito gave me an error saying that I must have an A record. I tried creating an Alias A record. But I don't have an actual Target. I just was to use something like auth.mydomain.com for logging in.
Since I couldn't make sense of an alias record I created a regular A record and set the target to a dummy ip 1.1.1.1,
Since I read that the target isn't really relevant for cognito.
At first it didn't work. But I thought that it's dns proportion thing and I tested it the next day and was able to add the domain to cognito.
My questions are:
Did I do right? Is it ok to set the A record to a dummy ip as long as my domain doesn't actually point to anything?
Is it possible to remove it after the association with cognito?
Why did it only work after a day? Is this DNA caching/propogation time?
Would that be the case with alias record? Or since alias is AWS aware it would be instant?
Thanks!
Generally speaking, your DNS should have an Apex (A) record pointing to something. If there's nothing yet, and although it is 100% not best practice, then yes, 1.1.1.1 will work (or anything, really).
Once you add your A record, head over to Amazon Certificate Manager to create your ACM certificate for your domain. Make sure your ACM certificate covers your subdomain, and verify it using DNS method. Verification takes about 5 minutes and once your certificate is verified, you'll be able to head over to the Cognito console to set up your custom domain using the certificate you just created.
Related
I have access to a number of AWS accounts belonging to a client, and would like to set up a public certificate using DNS validation. I believe this means I also need to set up DNS too.
I have two accounts:
dsc-staging (contains new cert, local DNS for subdomain)
eds-staging (contains root of new subdomain)
The new cert/DNS shall be:
gatekeeper.s.aws.example.com
This is set up in account dsc-staging. I have gone through the "DNS validation" option, and it says that it is pending. To start with there is no DNS for this name in either account, so this would eventually fail if left like that.
So, in the same account, I have created a HostedZone in Route 53, which creates default NS and SOA records.
Now, in the other account, eds-staging, there are existing records for:
s.aws.example.internal (NS record with four rows in a single value)
s.aws.example.internal (SOA record)
I have added the validation record in here, as a CNAME. (I am informed that it would be OK to have put the validation record in the local Route 53, but I have chosen for now to do it here).
Now, I believe that I need to inform AWS how to connect gatekeeper.s.aws.example.com with the known internal name s.aws.example.internal, which already exists, and is used by other things. I believe the process of connecting the two is called "delegation". I was given some instructions to take the NS records from the local account for gatekeeper.s.aws.example.com and copy them to the parent domain s.aws.example.internal in the other account.
However, the AWS UI in Route 53 seems to disallow adding another NS record - is it because one already exists? If so can I just add my four records under the existing four (ie. in the same record)?
I believe that if I wire up this DNS so that it is resolvable, the certificate will automatically become validate-able, and that will happen automatically. Is this assumption correct?
I would break it down like this:
Register or transfer the domain to your AWS master billing account. This is the only account that registers domains.
In each sub account eg dev prod, create a R53 hosted zone for the top level domain provisioned in step 1. Make sure the NS servers in step 1 are assigned to the zone here. Pay close attention that they agree both on name AND number of servers - usually 4.
Create a ACM cert request for the root AND wild card domain EG example.com and *.example.com. Request DNS validation. Key here is to include the wild card. This means it will work for any host name in the domain.
In ACM, request that the service create the R53 validation DNS records for you. This is only possible if you have done step 2 in the same account.
Wait for approval. It can take a few mins, to all day. Check back every hour or so.
This process, if followed exactly, will always provide a validated ACM cert that works for any AWS supported service, for both the root domain and any subhost under it.
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/
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>
I'm trying to set a CNAME on Cloudflare to point to an Amazon API Gateway endpoint. The CNAME is for use when referring to one of my subdomains. The gateway in turn points to the IP of a server on DigitalOcean. I am very new to Amazon web services and would appreciate if someone could give me an overview of the correct configuration for the DNS, Amazon Gateway and Cloudfront (which I think is needed to expose the gateway to DNS servers external to Amazon). Any help would be much appreciated.
UPDATE
I've been going at this for a while now and not making much progress. Does anyone have an idea if this is a viable approach or how else it might be done?
UPDATE2
I thought I needed to add the CNAME record to cloudFlare and just ended up in a redirect loop, observed by:
curl -L -i -v https://sub.mydomain.com/
NOTE: It seems this method doesn't work anymore as AWS now only accepts certificates from certain authorities. I haven't tested it myself, but the answer by Gunar looks promising.
There are several reasons why it doens't work to simply point Cloudflare at your API Gateway domain and call it a day:
API Gateway uses shared hosting so it uses the domain name to figure out what API to send requests to. It has no way of knowing that api.yourdomain.com belongs to your API.
API Gateway requires that you use https, but the certificate that it uses is only valid for the default domain.
There is a solution, however. Here are the steps that I followed when I recently set this up:
Generate an origin certificate from the crypto tab of the Cloudflare dashboard.
Import the certificate to AWS Certificate manager in the us-east-1 region, even if your API is located in a different region. If you are prompted for the certificate chain you can copy it from here.
Add your custom domain in the API Gateway console and select the certificate you just added. Check the AWS support article for more information on how to do this.
It usually takes about 45 minutes for the custom domain to finish initializing. Once it's done it will give you a new Cloudfront URL. Go ahead and make sure your API still works through this new URL.
Go to the Cloudflare DNS tab and setup a CNAME record pointing to Cloudfront URL you just created.
Switch to the crypto tab and set your SSL mode to "Full (Strict)". If you skip this step you'll get a redirect loop.
That's it. Enjoy your new highly available API served from your custom domain!
Set up Amazon's API Gateway Custom Domain with CloudFlare
In your AWS management console go to the API Gateway service and select Custom Domain Names from the left menu.
Click the Create button.
Log into CloudFlare, select your domain and open the Crypto tab
Go to SSL and set your SSL mode to "Full (Strict)" to avoid a redirect loop.
Go to Origin Certificates and click Create Certificate
Let CloudFlare generate a private key and a CSR and choose RSA as the private key type
Make sure that the hostname for your custom API domain is covered. (e.g. api.mydomain.com. You can specifically configure this custom domain or use a wildcard such as *.mydomain.com as is configured by default.
Pick PEM as the key format which is selected by default.
In AWS switch to region US-EAST-1 and goto the Certificate Manager.
Click Import a Certificate.
Copy the certificate body from your CloudFlare certificate to Certificate body to the configuration of the custom domain in the AWS Management Console.
Copy the Private key to the certificate private key field in the console
In the certificate chain copy the Cloudflare Origin CA - RSA Root which can be found here.
Enter your custom domain name in the AWS console and a name for your certificate
Now the custom domain name will be created in AWS CloudFront. It can take up to an hour before the domain becomes active.
The next thing you need to do is set up the mappings of the custom domain in the AWS Console.
The final step is to create a new CNAME Record in CloudFlare to link your domain to the CloudFront url. When you open the settings page of your custom domain in the AWS console copy the Distribution domain name. This is the domain you need to use when creating the new CNAME Record.
Source
I couldn't get any of the other answers to work. So I ended up having AWS generate the certificate instead of using a Cloudflare Origin one. That's because AWS wouldn't accept my Cloudflare certificate, even when the chain was provided. I couldn't see Cloudflare in Mozilla's Certificate Authority list (which is what AWS relies on, according to the docs) so I guess that makes sense.
Here's the outline of my solution:
Create AWS Route53 Zone
Create AWS ACM Certificate (must be in us-east-1) with validation method DNS
Create Cloudflare DNS Record with the output of (2)
Create AWS API Gateway Domain Name
Create Cloudflare DNS CNAME Record pointing '#' (root domain) to the Cloudfront domain name from step (4)
Create AWS API Gateway Base Path Mapping
This should be roughly it. May this help someone. Feel free to ask questions.
Both existing answers to this question are correct, but if the issue still persists even after following these directions perfectly, try going into the API Gateway settings, navigate to "Custom Domain Name" and configure the Base Path Mappings.
This was the missing step that solved all my problems.