Is there a way to validate domain control without using the email process? As I need to be able to add additional domains to the certificate for new clients...
The problem I'm facing is I can't add to the existing AWS certificate and have to create a new one with all the domains. When I do that everyone for every domain get's emailed and asked to confirm at:
administrator#domain.com
hostmaster#domain.com
admin#domain.com
postmaster#domain.com
webmaster#domain.com
So I have had to register a seperate certificate and upload it to ACM instead which is not ideal. Mainly as it's limited to 99 domains and was hoping to automate the whole process.
Is this possible with AWS?
Thank you.
Q: Are any other methods for validating a domain or approving a certificate supported?
Not at this time.
https://aws.amazon.com/certificate-manager/faqs/#provisioning
Having so many domains on one certificate isn't really a good practice, for other reasons, as well.
You're making your certificate physically longer and longer, wasting some amount of bandwidth, because the cert is sent to every connecting client, on every new connection.
Renewals will also be messy, if any of the domains on the cert are no longer pointing to your site, because auto-renewal requires that the issued cert be reachable on the Internet for each hostname.
ACM tries to automatically renew your Amazon-issued SSL/TLS certificates before they expire so that no action is required from you. To renew your certificate automatically, the following must be true:
ACM must be able to establish an HTTPS connection with each domain in the certificate.
For each connection, the certificate that is returned must match the one that ACM is renewing.
http://docs.aws.amazon.com/acm/latest/userguide/configure-domain-for-automatic-validation.html
One cleaner solution (the one I am using) is to provision each domain's cert individually, and attach each one to its own CloudFront distribution, pointing that to your origin server (which I assume in this context to be an ELB) and whitelisting all headers for forwarding to the origin, which bypasses caching and causes CloudFront to function as a simple but distributed reverse proxy. Setting "compress objects automatically" in CloudFront may also save some bandwidth charges, and even with caching disabled, CloudFront should improve the responsiveness of your sites by keeping traffic on the AWS network for more of the path between origin and viewer.
Related
When I create an ELB (i.e. Application Load Balancer), Amazon gives it a DNS name e.g.:
myalb-1472119708.eu-central-1.elb.amazonaws.com
Now, I would like to terminate TLS/SSL on my ALB, however, I don't want to attach my own certificate (e.g. from the Certificate Manager), I am ok with accessing my application via the default DNS name (of the ALB) through HTTPS:
https://myalb-1472119708.eu-central-1.elb.amazonaws.com
However, with the default configuration I can access my app via HTTP only:
http://myalb-1472119708.eu-central-1.elb.amazonaws.com
Does AWS support this (rhetorical question)? Any plans to add this feature in the near future? Thanks.
UPDATE:
After all it's not a hard feature to implement. Moreover, SSL is the de facto standard for running (secure) web apps today. I believe, AWS can issue wildcard certificates for the ELB in every region, e.g.:
*.eu-central-1.elb.amazonaws.com
And then attach it to every ALB by default. Or publish a list of certificates' ARNs for every region. This would free developers from extra effort (buying a domain, registering a certificate in ACM) for their non-production projects.
At the time of this writing, the only way to resolve this is by running your ALB/ELB behind CloudFront, which (unlike ALB) gives you a TLS certificate by default:
User -> CloudFront edge location (HTTPS) -> ALB (HTTP) -> Backend (HTTP)
Although CloudFront incurs extra costs, apart from the ability to cache static content, CloudFront gives you faster TLS termination, which happens at its edge locations, thus reducing latency on the first two TLS handshake roundtrips (2 in theory, but practically 3 in case of low-bandwidth clients).
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 know that you can add your own certificate to the domain and point that domain to the AWS Elastic Load Balancer. In my case I don't have domain, but would like still use secure HTTPS/SSL connection when talking client <-> backend. Is it possible to enable HTTPS connection directly to ELB, i.e instead of using http://some-random-url-here.eu-west-1.elb.amazonaws.com I would like to use https://some-random-url-here.eu-west-1.elb.amazonaws.com
That would mean, that AWS would need to provide the cert for the *.elb.amazonaws.com domain. I remember at least long time ago this was possible, but maybe my memory does not serve me right?
Memory does not serve you right. This is not possible now and would not have been possible in the past. ELBs don't have, and it is not possible to obtain, a certificate like this (including from Amazon Certificate Manager).
In fact, 3rd party providers like Let's Encrypt also have protections to prevent you from obtaining certificates like this, since amazonaws.com is not your domain.
You will need a domain that you control.
I am looking for some advice as how to most cost efficiently setup SSL for a subdomain e.g https://images.example.com.
Images are hosted in AWS S3 and I have a cloudfront distribution pointing to that bucket.
I have purchased a single domain SSL cert from Comodo and successfully added it to my cloudfront distribution. That part was easy as pie.
However, when loading images on the subdomain I get a "Not secure / certificate invalid" in the browser bar.
Is this because I require a wildcard SSL cert?
I have not tested that the SSL cert works on the main domain. Reason being there is currently a production site that I don't want to interfere with.
Before I rush out and purchase a much more expensive wildcard SSL cert, I want to make sure it is required.
I have a single subdomain for image hosting. I don't expect to ever ad more subdomains. What if I just purchase two single domain certs?
What are my options?
Try using ACM (https://aws.amazon.com/certificate-manager/ ) to issue an AWS issued wildcard certificate for your domain and use that instead?
As to why your existing cert won't work - does it have the domain in the cert (eg images.domain.com) as either the primary domain or as a SAN? If not, it won't work.
If you don't want to use a wildcard, you can use an ACM cert (or a cert you purchase from somewhere else) and issue it for the domain subdomain only? You don't have to use a wildcard but from a cost point of view if you are purchasing them, its often more cost-effective (although there are of course security concerns to consider). If you are using ACM, the certs are free - either domain specific or wildcard.
I’m using an Amazon EC2 instance to host my web application. The EC2 instance is in the APAC region. I wanted to use an SSL certificate from Amazon Certificate Manager.
For the above scenario, I have to go for either Elastic Load Balancing option or CloudFront.
Since my instance is in APAC region, I cannot go for Elastic Load Balancing, as load balancing is available only for instances in US East (N. Virginia) region.
The other option is to go for CloudFront. CloudFront option would have been easier if I was hosting my web application using Amazon S3 bucket. But I’m using an EC2 instance.
I requested and got an ACM certificate in the US East (N. Virginia) region.
I went ahead with CloudFront, and gave in my domain name (example.com) in the origin field, in the origin path; I gave the location of the application directory (/application), and filled in the http and https ports.
When the CloudFront distribution was deployed, I could only see the default self-signed certificate for the web application, and not the ACM certificate.
Your comments and suggestions are welcome to solve this issue. Thank you.
I went ahead with CloudFront, and gave in my domain name (example.com) in the origin field,
This is incorrect. The origin needs to be a hostname that CloudFront can use to contact the EC2 instance. It can't be your domain name, because once you finish this setup, your domain name will point directly at CloudFront, so CloudFront can't use this to access the instance.
Here, use the public DNS hostname for your instance, which you'll find in the console. It will look something lke ec2-x-x-x-x.aws-region.compute.amazonaws.com.
in the origin path; I gave the location of the application directory (/application),
This, too, is incorrect. The origin path should be left blank. Origin path is string you want CloudFront to prepend to every request. If you set this to /foo and the browser requests /bar then your web server will see the request as coming in for the page /foo/bar. Probably not what you want.
and filled in the http and https ports.
Here, you will need to set the origin protocol policy to HTTP Only. CloudFront will not make a back-end connection to your server using HTTPS unless you have a certificate on the server that is valid and not self-signed. The connection between the browser and CloudFront can still be HTTPS, but without a valid certificate on the instance, CloudFront will refuse to make an HTTPS connection on the back side.
Also, under the Cache Behaviors, you will need to configure CloudFront to either forward all request headers to the origin server (which also disables caching, so you may not want this) or you at least need to whitelist the Host: header so your origin server recognizes the request. Add any other headers you need to see, such as Referer.
Enable query string forwarding if you need it. Otherwise CloudFront will strip ?your=query&strings=off_the_requests and your server will never see them.
If your site uses cookies, configure the cookies you need CloudFront to forward, or forward all cookies.
That should have your CloudFront distribution configured, but is not yet live on your site.
When the CloudFront distribution was deployed,
This only means that CloudFront has deployed your settings to all of its edge locations around the world, and is ready for traffic, not that it is actually going to receive any.
I could only see the default self-signed certificate for the web application, and not the ACM certificate.
Right, because you didn't actually change the DNS for "example.com" to point to CloudFront instead of to your web server.
Once the distribution is ready, you need to send traffic to it. In Route 53, find the A record for your site, which will have the EC2 instance's IP address in the box, and the "Alias" radio button set to "No." Change this to Yes, and then select the CloudFront distribution from the list of alias targets that appears. Save the changes.
Now... after the old DNS entry's time to live (TTL) timer expires, close your browser (all browser windows), close your eyes, cross your fingers, open your eyes, open your browser, and hit your site.
...which should be served via CloudFront, with the ACM certificate.
This probably sounds complicated, but should be something you can do in far less time that it took me to type this all out.
Elastic Load Balancer is available in all the regions. The assumption that it is available only in US East is wrong. Check it out, maybe this alone solves your issue.
About SSL termination, you can enable the service on the ELB.
If in single node, you can SSL terminate on the web server itself, a cheaper solution.
Firstly, thank you so much for taking your time and helping me with the query. I proceeded with your suggestions.
'Also, under the Cache Behaviors, you will need to configure CloudFront to either forward all request headers to the origin server (which also disables caching, so you may not want this) or you at least need to whitelist the Host: header so your origin server recognizes the request. Add any other headers you need to see, such as Referer.'
I don't know what you mean by whitelisting the host. Under the whitelist box, what value do I have to give?
Since I wasn't sure about whitelisting the header, I proceeded with allow all header. And I forwarded all cookies.
In the origin settings, I don’t know what to give in the header name and header value. So, I gave the header name as ‘header1’, and value as my domain name ‘www(.)example(.)com’.
I have made the DNS change in Route 53 as you have suggested.
Now when I click www(.)example(.)com, I’m able to see https://www.example(.)com with a valid ACM certificate.
However, when I tried to access my application, https://www(.)example(.)com/application, the webpage is navigating to https://ec2-x-x-x-x.ap-southeast-1.compute.amazonaws.com/application/, and it’s showing the self-signed cert again.
I’m guessing there is some problem with DNS configuration in Amazon Route 53. Can you please tell me what changes do I have to do so that when I hit my application I can see a valid certificate?
Also, when I hit my application, my URL is changing to show ec2-x-x-x-x, instead of my domain name? Can you please tell me how to correct that?
Thank you so much.