Yeah, currently the keys are held securely within AWS and it's only available for use within specific AWS services - Elastic Load Balancer & CloudFront at the moment.
I mean, since they're offering for free what many others charge ~$100 USD for, I'm not surprised.
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)
You only care about pinning when you fear that a third actor somewhere between your server and the end client might MitM the connection with a valid certificate.
If a third party controls your keys, certificate pinning is useless to prevent against attacks from that third party or governmental agencies.
Most HPKP deployments pin to root or intermediate certificates of CAs (usually 2 separate CA entities, in case something happens to the primary CA) - meaning in a typical scenario, the attack surface is approximately the same.
Not sure if this approach is common in native applications that pin to keys as well.
Obviously. That doesn't mean pinning is impossible or useless against other threats though, so I don't think the argument makes sense in that general way. I bet there are tons of apps running/with backends running on AWS that should have certificate pinning.
Just a few days ago I spent $200 to purchase a multi-domain wildcard certificate so that I could host multiple secure domains, with multiple subdomains, on a single elastic beanstalk app. It was such a headache to figure out that I needed the multi-domain wildcard cert, then to find one to purchase for a reasonable price.
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.
You can probably manually specify in EB config files for ELB. Haven't touched that in a couple years but support should be able to help. If not reach out and I'll try to reconstruct.
Can anyone think of any advantages LetsEncrypt would provide over this offering from AWS? Or does this basically kill LetsEncrypt's usage on AWS?
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.
I don't think you have access to the actual private key file so this would be restricted to AWS services like an ELB. With letsencrypt you have the key file as well so you can use it for securing any type of connection (not just a load balancer front end).
I believe this requires the use of cloudfront or their load balancer. So if you want to stick with minimal costs you can use letsencrypt with just an ec2 instance.
My frustration with these offerings is that they tend to only service public-facing HTTPS servers. There are a lot of use cases where valid certificates come into play, and a lot of them aren't facing the public internet or serving HTTP traffic.
FWIW, you don't need to have an MX for example.com to get a certificate for it. The e-mail addresses used for domain validation come from WHOIS and can be, e.g., you@not-example.com.
It depends on your security requirements as well. Some people feel the need for end to end encryption as opposed to SSL termination at the load-balancer tier. If you are one of those people, letsencrypt is the way to go
If it's all going in AWS, I don't see a huge difference between terminating in the ELB vs. terminating on the VMs. It might help you if the ELB got misconfigured, but AWS managing/provisioning the keys keeps them safe from being misplaced, too, so on balance it's probably better.
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)
how does this work ? one of the big challenges with letsencrypt was that I'm unable to bake it in my Docker images. I had a circular dependency - where my nginx wont start without my certificate and letsencrypt needs nginx to be running to serve the temp file that it creates.
does this solve that ? Am I now able to bake letsencrypt in my docker images ?
I'm not familiar enough with docker to comment on what the best solution would be. That being said, instinctively I would say that a certificate is something that should be provided to docker instances as part of the configuration and not acquired whenever you launch a new instance (you would run into rate limits quite fast).
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.
IIRC authorizations (solved challenges) expire after 10 months, so you could get up to 13 months of certificate coverage out of one solved challenge. The official client doesn't support this yet, it will request a new challenge token on every run.
I have an ansible role that deploys letsencrypt certificates. It's not perfect, but currently the flow is: check if nginx is running. if it's running, use the webroot authenticator. if it's not, use the standalone authenticator.
This creates issues come renewal time, but a few tweaks to the renewal config (/etc/letsencrypt/renewal/your.domain.conf) fixes that
Are these certificates exclusively for ELB and CloudFront? Does anyone see a way to download a certificate for manual installation on a server (EC2 or otherwise)?
> 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.
You might be right. Maybe the pricing page 404 was a silly marketing stunt? That would be pretty clever.
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.
Wow that was super easy. I tried this on one of my sites and it really took me like 2 minutes total to add SSL to it.
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.
Buying SSL Cert through Bluehost (my domain registered, and blog hosted) and figuring out how to apply it my web-app, zejoop.com, hosted on AWS was far and away the most annoying and difficult chore in my development/deployment process as a relatively junior SW developer. If I could solve all inhouse within AWS (at reasonable cost) is be very happy. My cert just renewed, so until I roll change to AWS my https:// is down. If update is as difficult for me as original install was, then I guess it will be about 18 hours of aggravation. So I'll look into this, if the OP title is a reality.
Thanks, I will investigate. Not clear though if I'll need to convert the cert though to AWS load balancer accepted format... that was the bulk of my earlier problem, especially handling the chain bundle. The AWS cert service, I assume, would eliminate the conversion problem for me. Thanks... I'll check it out
tl;dr - For now, their root CA is Starfield[0], but AWS may become a root CA very soon.
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]
Cool, they will be accepted as Root Cert on Windows then. Yep, Apple and Microsoft maintains their own Root CA programs (private approval process). I bet AWS also applied for Apple's Root CA program.
Guide is great, except my environment (which can't be renamed) is "My First Elastic BeanStalk Application" - this results in error on CLI "Value 'My First Elastic BeanStalk Application' at 'environmentName' failed to satisfy constraint: Member must have length less than or equal to 23"... stuck
I figured out my own mistakes: [1] the actual name was 'Default-Environment', and [2] I had used the wrong zone when I set up AWS CLI using the 'aws configure' command. Fixed both mistakes and zejoop dot com is back online with a working SSL Cert.
Thanks for documenting that! Now if I could only remember where I put my I put my 'AWS Access Key ID' and its corresponding 'AWS Secret Access Key' so that I could 'aws configure' from the CLI I'd be golden! The guide looks great though.
This is fantastic news. Now, let's see Heroku use either this or Let's Encrypt and eliminate their onerous $20 per host SSL fee, which is making the Internet less secure.
This would be huge. Heroku's high monthly SSL cost is a big reason I've moved dozens of smaller apps and sites to Digital Ocean. As I moved to using SSL everywhere I realized Heroku's costs were not sustainable for random side projects and static sites.
I recently needed a cert and got one from letsencrypt. Haven't read about them or followed all the news. I have no idea about the architecture of Let's Encrypt. So these might sound stupid;
- 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)
> - 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?
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.)
The goal with letsencrypt is to get everyone using SSL, even the layman. With that in mind they aim to automate the process as much as possible so you don't need to remember to update your cert or worry about it expiring. The client will handle all this for you in the background.
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.
The local client app is needed to verify that you actually own the domain.
3 month certs are actually more secure since there is shorter amount of time in which they can be stolen & used.
The goal of letsencrypt is to make re-issuing certificates automated, so even a 1 week certificate is no problem since you can run a nightly cronjob to refresh it.
I'm using Let's encrypt for personal and work stuff. The official client stinks. The first time I tried it I had to shut down my web server to get the cert? It was my personal stuff, so I did it, but moved on to find a new solution for work. I'm using this: https://github.com/diafygi/acme-tiny. It needed a bit of a tweak to get the challenge files to show up on all of the EC2 instances that hide behind the ELB since you don't know which one will be hit.
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.
I suspect the 3 month certs is to make sure you have to authenticate your domain 4 times a year with Let's Encrypt to make sure that you can't hold a valid SSL key for the domain for more than a few months after you transfer it. Also, if someone manages to scam Let's Encrypt, the resulting cert is only valid for a short time.
The local client is there to make sure that the authentication process can be automated and not require your manual intervention.
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.)
It gives 3 month certs because what you are supposed to be doing is automating the cert creation and when you have it automated 3 months certs are a good thing since it is a security benefit and has no disadvantages.
So Let's Encrypt - awesome. On a side note, I was wondering what the difference is between the base certs issued by LE vs. those fancy super, extra double / triple level certs ("EV"? if I recall) practically speaking.
LE enables Domain Validated certs...so you'll get a green lock in most browsers.
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.
The gimmick on the super fancy certs that give the big green bar w/ company name next to the URL is that they supposedly mean the CA has done a super thorough investigation on the company and verified that they really are who they say they are. Those certs cost like $1k from most vendors. This could be valuable if you get a lot of people trying to imitate your company or domain; for example, something like nikeshoes.com v. nike.com. But since most customers don't actually know any difference, the practical value is very small.
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.
A 3-year wildcard cert from rapidSSL is only 200 bucks when purchased through a reseller. If going in that direction saves you even a couple hours over the course of three years, it's more than paid for itself.
You generate a new CSR + private key and reissue the cert through the vendor. All the ones I've purchased allow reissuing as often as you like. The expiration date never changes obviously, but reissuing is a common practice.
With ELB, in most of my projects wildcard certificates are a must and thus Let's Encrypt is not an option. I hope one day (soon) they implement that as well.
I have nurtured the secret belief that the reason that Letsencrypt renews certificates ("automatically") every three months is not a feature... but a forced limitation by the guys who own the root cert chain.
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 ?
The LetsEncrypt root is in-house, not third party. Certificates are also cross-signed by IdenTrust, but once the LetsEncrypt root is in all major browsers, it won't be necessary to have a cross-signature.
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.
I meant the cross signing. That is the big deal here. And I somehow have this nagging feeling that they were strong armed into the 3 month renewal policy. No other reason to not have yearly renewals.
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).
As mentioned in the other threads, 3 month renewal provides a smaller risk window for compromised domains/certificates.
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.
ACMs roots are cross-signed by Starfield (GoDaddy iirc), while they wait for their inclusion in the browser roots... so I can't see a difference with LetsEncrypt? AFAIK either you have the processes/tech in place to secure your CA and issue certificates, or you don't.
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.
How will Amazon's new root certificate be spread to all browsers and mobile devices, so it's made sure that it will be trusted on every possible endpoint? Is the root certificate cross signed with another, already trusted cert?
Thanks, but funny: Not all test URLs are working on my Marshmallow Android. Only the "valid" tagged "Amazon Root CA 1" is accepted by my mobile Chrome, not so the others. Also the revoked Starfield test url is still being accepted by my browser.
It is past time. Where was this last month? We just started using Let's Encrypt to get certs onto ELBs. With a few mods to stuff on github we can easily generate certs for multiple domains (up to the 100 domain limit) and put them on the ELB.
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.
Dumb question; I'm not an aws user, but I thought with ELBs you did ssl termination at the load balancer, then unencrypted to downstream servers? But you seem to indicate you have ssl between elb's and downstream? Is that correct?
Not a bad question. You are correct, the ELBs are doing ssl termination, but the way I'm using Let's Encrypt and a 3rd party python script means that each web server needs to be able to answer the challenge on port 80. For web server without a LB, that means you just run the script and it generates the file that needs served up on 80.
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.
It is, but using it would require us to use 5x as many ELBs as we need now (100 domains per cert vs 20). For some that isn't a problem and free is a great price.
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.
Why? AWS is issuing certificates. They happen to be doing that through their new Certificate Manager service, but the more interesting news is that AWS is issuing publicly trusted certs.
It's a moot point now, because the announcement post (which we changed the URL to) has a different title. But the answer to your question is that we don't always have a magic title accuracy detector—though HN readers come close.
If you use the AWS Simple Monthly Calculator, it shows a $600 a month charge for one dedicated IP/SSL certificate on Cloudfront. Is this not the same thing as the new free certificate?
http://aws.amazon.com/certificate-manager/pricing/
https://docs.aws.amazon.com/acm/latest/userguide/acm-certifi...