AWS Certificate Manager: Deploy SSL/TLS-Based Apps on AWS
aws.amazon.com
aws.amazon.com
http://aws.amazon.com/certificate-manager/pricing/
https://docs.aws.amazon.com/acm/latest/userguide/acm-certifi...
That said, SSL certs and domain renewals are the least interesting but high importance items of running an online business. As I'm already heavily deployed on AWS, I have no problem having them handle all of this for me, for what is free to me. (yes yes, not technically free)
http://security.stackexchange.com/questions/16085/how-to-get...
If a third party controls your keys, certificate pinning is useless to prevent against attacks from that third party or governmental agencies.
Not sure if this approach is common in native applications that pin to keys as well.
Still very cool!
Now, 5 days later, AWS lets me create one for free in 3 minutes, with zero hassles. I cannot select it in beanstalk yet, but I am sure that will come. I am consistently amazed by how frequently AWS satisfies needs I barely knew (or didn't know) I had.
option_settings: aws:elb:listener:80: ListenerEnabled: false aws:elb:listener:443: InstancePort: "80" InstanceProtocol: "HTTP" ListenerProtocol: "HTTPS" SSLCertificateID: "<replace with ACM cert ARN>"
The only thing I can think of is that AWS Certificate Manager only validates by email addresses which can be problematic if you don't have MX records or don't have control over it(Maybe a large organization where the people who do control those email addresses won't click simple verification links)
It seems a bit inconsistent as to when it will use the email on the whois record for the validation too. For some subdomains I try it will allow validation using the whois address, other times it's just the common aliases@sub.domain.com(which requires an mx record) So I guess if you're nesting deeper than one subdomain(e.g. abc.def.example.com) then maybe it'd be easier to get letsencrypt set up than try to get mx records for abc.def.example.com.
Shameless Plug/Disclaimer: I had been working on a tool to make it dead simple to use Lets-Encrypt certificates for CloudFront/ELBs and handled autorenewal via Lambda. I'm not sure there is any use for this now that this exists though.
If you had on-premise servers, or a different/more secure host vs. intermediary/load-balancer, I could see the value of end to end. (especially if you have a long-lived cert, a pinned cert, EV, whatever).
(and of course crypto between the intermediary and the servers, if it's not on a physically secured LAN segment)
Great!
Of course, it does look like they support wildcard certs, so it probably won't be cheap.
EDIT: Removed EV reference, these are DV only.
The official client doesn't support it yet though; you'll have to use alternative clients.
[1]: https://twitter.com/letsencrypt/status/689919523164721152
does this solve that ? Am I now able to bake letsencrypt in my docker images ?
With DNS-based validation you have to create a TXT record on your domain with a random token. If you can automate creation of TXT records from your setup, that would be an option to solve the challenge. The rate limit issue still applies.
This creates issues come renewal time, but a few tweaks to the renewal config (/etc/letsencrypt/renewal/your.domain.conf) fixes that
https://github.com/DanielDent/docker-nginx-ssl-proxy
My solution is to simply include a self-signed dummy keypair that gets replaced by the letsencrypt keys when they get issued.
An alternative approach would be to remove the SSL listener entirely until the certificate is issued.
Does the DNS based validation make this better in any way?
I assume you mean Let's Encrypt's newly announced DNS validation approach to issuance? I think that would only add unnecessary complexity here.
There are other setups where that will be nice to have, but I don't think this is one of them.
Certs are free
https://docs.aws.amazon.com/acm/latest/userguide/setup-websi...
> Currently, ACM Certificates are associated with Elastic Load Balancing load balancers or Amazon CloudFront distributions. Although you install your website on an Amazon EC2 instance, you do not deploy an ACM Certificate there. Instead, deploy the ACM Certificate on your Elastic Load Balancing load balancer or on your CloudFront distribution.
Ideally ACM certificate issuance and deployment would be two separate things, and this would be a general-purpose CA, which just happens to have integrated deployment tools for ELB and CloudFront.
BTW, it looks like there might be a lot of people flagging this post (raced to position 1, but then quickly dropped to position 5).
I'm not opposed to people flagging things or anything, but I'm curious as to why a post like this would be heavily flagged, if that is indeed what is happening.
The only confusing part was that port 443 was blocked in ELB by default (which made it look like it didn't work but got fixed easily as soon as I figured it out). I've never seen an easier way to do this till date.
They probably are going to roll out this feature everywhere.
EDIT: Just got a cert from the new service. Here's a screenshot of the cert chain. Amazon is issuing them: https://imgur.com/VGos0eY
Amazon had applied to be a Root Certificate Authority to Mozilla and Android since June 2015 [1]. And it's been in pending for public discussion recently [2], which is one step away from being inclusion by Mozilla[3](aka becoming a root CA).
Once they are vetted and being included in Mozilla's Root CA program, they will be accepted by Firefox browser and on Linux. And after vetted in Android, it will be accepted by Google Chrome/Chromium browsers.[4]
[0] http://i.imgur.com/s2Uijes.png
[1] http://www.geekwire.com/2015/amazon-wants-to-be-your-ssl-cer...
[2] https://mozillacaprogram.secure.force.com/CA/PendingCACertif...
[3] https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
[4] https://www.chromium.org/Home/chromium-security/root-ca-poli...
option_settings: aws:elb:listener:80: ListenerEnabled: false aws:elb:listener:443: InstancePort: "80" InstanceProtocol: "HTTP" ListenerProtocol: "HTTPS" SSLCertificateID: "<replace with ACM cert ARN>"
As long as AWS provides an API to provision certificates, that would be awesome. I use Nginx, and need access to the private key and cert.
Go interface (the docs haven't been updated as of yet):
https://github.com/aws/aws-sdk-go/blob/87b1e60a50b09e4812dee...
And the changelog from the Ruby project:
https://github.com/aws/aws-sdk-ruby/blob/8ed439546619f78263f...
Still incredibly exciting and a great feature for Amazon solutions!
The Extended Validation certs gives you the green lock AND the name of the organization. The EV assures you that the company you're doing business with has been vetted...but customers don't know and most have not been educated about the differences in encryption and trust.
By contrast, a normal SSL cert is issued just by confirming control of one of the domain's email addresses.
Technically, it's the the difference between the baseline requirements (for all certs) and the EV requirements (required only for EV), which are at https://cabforum.org/wp-content/uploads/EV-V1_5_7.pdf. In order to get an EV cert, you must pass those requirements, specifically:
- government information sources
- qualified independent information sources
- all domain names must be inspected by a human
- phone calls to your office
Additionally Google mandates Certificate Transparency for EV, so all EV certs have CT as a result.
EV is also required for .onion services, because what would be the point of anonymity unless you actually knew who you were talking to.
In the 90s it took a long a long time for certs to be issued: you'd fax ID to VeriSign, they'd verify your identity and sign your certificate.
DV was introduced by Geotrust as a way of saving money for CAs: DV just means you can register a domain: even if the domain seems like it belongs to a particular legal entity, DV makes no assurances that it does. People can and do get DV certs that seem like they're for major companies all the time. The process is entirely automated, and nobody is asserting any identity: https://google.com.mg and https://google.com.im exist, they're not Google, and that's fine because DV certs don't assert identity.
EV does actually assert a connection between the certificate and a specific legal identity, which is encoded in the certificate, signed and displayed in the browser. EV isn't perfect: you could attempt to be verified as another company. However it is the only type of certificate that assures an actual identity to browsers.
Disclaimer: I work for a startup that's created significantly faster, more painless EV validation. We think it's important that Alice knows she's talking to Bob.
- Why do we need a local client app to issue certificates? Is there a web interface in development? Is there a technical reason for it to work this way?
- Why does it issue 3 month certs? Beta period? (This is reason enough to pay btw, If I did not screw something up to end up with short term certs)
So it can verify domain ownership automatically.
> Why does it issue 3 month certs?
Because it verifies domain ownership automatically.
The local client is there to make sure that the authentication process can be automated and not require your manual intervention.
The client takes care of solving the ownership challenge, provisioning the certificate and configuring your web server (if you want it to). It also helps with renewal, in a way that it can be automated completely.
The entire process uses an open protocol (ACME), and there are a number of alternatives out there. If you like web-based ones, look at https://gethttpsforfree.com/
> - Why does it issue 3 month certs? Beta period? (This is reason enough to pay btw, If I did not screw something up to end up with short term certs)
This is likely to stay even after the beta. The reasoning behind it is that Let's Encrypt makes it easy to automate renewal, and shorter renewal periods will encourage users to configure and use automation as opposed to doing it once a year and then forgetting about it. It also reduces the time frame in which you're vulnerable in case your key is exposed at some point. (CRL and OCSP solve this only in theory.)
They are even considering shortening them to less than 3 months. I think the goal there is to ensure people automate it who would otherwise try and do it manually.
As for the 90 day limit, we aren't too worried. We'll add domains often enough we shouldn't have to worry about it. and it can always be automated.
IIRC, it is to encourage automation, and short term certificates are somewhat more secure (shorter period of use if one leaks and it isn't revoked; shorter period to attack the keys [shouldn't be an issue in any reasonable time period, but it can't hurt to limit it] etc.)
Now what happens when you have to do a rotation because of another attack that makes it possible to leak private keys?
If I'm a startup, why should I shirk away from paying 9.99 for a RapidSSL certificate from namecheap and have it working reliably through Ansible/Puppet/Docker... and rather muck about with the chance that my server SSL cert may go down because my letsencrypt client was outdated or something.
Or worse, I have a wordpress site running on a PHP host - the best case scenario is that they agree to use a certificate I buy. Running a python based client ?
That's not to say that they don't have some other motive for the 90 day expiry, but I don't think they need the support of major CAs for what they're doing at the moment.
Even if they do get into Browser roots now, there are hundreds of millions of mobile devices out there that will not accept Letsencrypt without a cross sign. Lets face it Letsencrypt is dead in the water without Identrust (or someone similar).
Its not a bug, it's a feature.
This is important, considering that certificate revocation is not a universally solved problem, and that Let's Encrypt is aiming to radically increase the amount of certificate issues as a whole.
No strongarming necessary, I'm pretty sure technical considerations ruled the day here.
https://mozillacaprogram.secure.force.com/CA/PendingCACertif... shows Mozilla's in-progress certifications -- including LetsEncrypt, Amazon, DocuSign, VISA, a bunch of governments, telcos, existing CAs, and others I don't recognise. Cross-signing is a pragmatic solution for older client devices (eg. abandonware Android phones) for _any_ CA root, new or otherwise.
I'm glad they are getting into this, competition is always good. With the pricing page giving a 404 I can only guess that it will cost more than Let's Encrypt, but if you haven't already rolled your own, it might be a nice option.
20 domains on an ELB for a year, $10.80 per domain (ignoring traffic). Or put 5x as many on and get SSL for $2.16 per domain per year (also ignoring traffic).
That said, I'm really happy to see AWS head this way. Even if someone uses them, in min mind Let's Encrypt did its job - drive the cost of SSL down to where everyone can have it.
With more than one web server you need to be able to server that file up on any instance that might get hit when the challenge request comes in.
For some, DNS might be an easier way to prove domain ownership, but we have clients who control their DNS. Doing it all on the web means it is 100% in our hands.