I´m probably not understanding something here and wanted to ask, if somebody could explain.
I set up an AWS ES domain and created a custom endpoint for it. I provided a ACM certificate which I uploaded upfront and created the domain with it.
Let´s say, the custom endpoint should be a subdomain of my existing ROUTE 53 Domain (eg. logging.my-r53-hosted.domain)
I didn´t do anything at Route 53, yet, just provide an imaginary subdomain as endpoint(example above).
Then what ? .....
When I create this subdomain on Route 53 as CNAME which points to the autocreated endpoint of AWS ES (eg. vpc-logging-72354762589234579.es.amazonaws.com) and curl the custom endpoint (logging.my-r53-hosted.domain) I´m getting just the aws certificate back, but not the one i provided before. That gives me a self signed cert warning. I can circumvent this with --insecure, but that´s obviously not what I want.
Can anybody explain how to do it right ?
Thanks all and again thanks for your patience :-)
Greetings!
Create a wild card certificate like *.youdomain.com in ACM.
While creating the ES cluster select the custom domain option and add Custom hostname as your subdomain (e.g: elasticsearch.yourdomain.com) And for certificate chose wildcard certificate from ACM.
If you have cogito auth for kibana You will need also need to follow these steps:
Go to Cognito pool
Under App integration > App client settings
Update Sign-in and sign-out URLs according to your subdomain.
Related
So, I've been trying to add my own domain to AWS API Gateway, but cannot add an ACM certificate. Even though I was issued a certificate from the AWS Certificate Manager, I can’t select it from the “Choose a certificate” drop-down selector. It only says “No certificates in eu-west-3 match the domain name you entered”.
Within the AWS Certificate Manager, I see that the status is ”Issued”. What am I doing wrong here? I must be missing something.
Information that might be useful:
Domain was bought through Google
The ARN of the certificate contains arn:aws:acm:eu-west-3:…. Also the url of both the API gateway and Certificate Manager console contains eu-west-3
The domain I want to use in API Gateway was pasted from the certificate domain field to avoid any typos.
For what is worth, the domain I want to use is actually a subdomain.
Thanks!!
When issuing the ACM, did you also enter subdomain in the list? Also, its really helpful to issue wild card ACM for domain. eg -
main domain - mydomain.com
sub domain - my.subdomain.com
wild card - *.mydomain.com
With wild card you can map it to any sub domain.
Usually, whenever issuing SSL, it's good to include wildcard asking with main domain. If main domain has different SSL, new wildcard for subdomain should not impact 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/
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 tried creating a Route 53 alias record but that didn't work.
It is possible as of November 2020:
Choose Edit domain.
To add a Custom endpoint, select the Enable custom endpoint check box.
For Custom hostname, enter your preferred custom endpoint hostname. Your custom endpoint hostname should be a fully qualified domain name (FQDN), such as www.yourdomain.com or example.yourdomain.com.
For AWS certificate, choose the SSL certificate that you want to use for your domain.
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-customendpoint.html
We don’t support custom SSL certificates, which means that a custom CNAME for an Elasticsearch Service endpoint such as mycluster.mycompanyname.example also is not supported.
Ref: https://www.elastic.co/guide/en/cloud/current/ec-faq.html#faq-dns
It is still not possible on September 2020:
Can I use a Custom SSL certificate?
We don’t support custom SSL certificates, which means that a custom CNAME for an Elasticsearch Service endpoint such as mycluster.mycompanyname.com also is not supported.
source
Create a wild card certificate like *.youdomain.com (for subdomain setup) or a domain certificate (e.g yourdomain.com) if you have a domain that you want to point to this cluster in ACM.
Assuming you are going with a subdomain setup. You can follow similar steps for domain setup.
While creating the ES cluster select the custom domain option and add Custom hostname as your subdomain (e.g: elasticsearch.yourdomain.com) And for certificate chose wildcard certificate from ACM. Or you can edit your cluster and do the same.
If you have cogito auth for kibana You will need also need to follow these steps:
Go to Cognito pool
Under App integration > App client settings
Update Sign-in and sign-out URLs according to your subdomain.
Adding more information to the answer by yurez's.
The following step is also important:
After you enable a custom endpoint for your OpenSearch Service domain, you must create a CNAME mapping in Amazon Route 53 (or your preferred DNS service provider) to route traffic to the custom endpoint and its subdomains. Create the CNAME from the custom endpoint (the name of the record e.g., example.yourdomain.com) to the auto-generated endpoint (the value of the record e.g., vpc-1b1b1b1b1b1b1b1b1b1b1b1b1.us-east-1.es.amazonaws.com). Without this mapping, your custom endpoint won't work.
Reference: Creating a custom endpoint for Amazon OpenSearch Service
You can use route 53 service of AWS, Create record with CNAME and put value as some friendly name like kibana.logs.com or whatever domain you owned.
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.