Great project to smooth out the really painful process at present for acquiring certs. How about an FAQ page or a few clarifications?
Things I wanted to know which were not immediately apparent:
Will it be broadly accepted from day one? Yes, apparently, though see the identrust issue below.
Will it generate a keypair but keep the private key on your server? Yes.
Will it work without having to babysit an interactive prompt? Yes.
Will it just let you generate key,csr,crt and do your own config changes? Yes.
Questions I still don't know the answer to:
Will it provide wildcard certs? No idea. I'd love it to be true as this is the part of current CA's which really irks me - the price gouging over something which costs them nothing more to provide. Can't see anything on the website about it.
How does it auto-renew, does it have to run all the time?
Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/
Can every CA support issuing certs this way please? :)
We're working on an FAQ. This thread has been really helpful in clarifying which Qs are FA :)
With regard to your questions:
> Will it provide wildcard certs?
Not initially, but possibly in a future iteration.
Note that having an automatic CA addresses some of the use cases for wildcard certs. Namely, if you're using a wildcard cert just to avoid having to manage individual certs for foo-1.example.com through foo-N.example.com, you can just have them each automatically get a specific cert.
> How does it auto-renew, does it have to run all the time?
That will depend on the software running on the web server. The current "node-acme" and "lets-encrypt-preview" implementations in the Github repo are examples. Ultimately, in addition to these tools, it would be great to have ACME / LE support built into web server platforms, which are already running all the time.
> Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/
I don't know what the story is with that site, but I believe the Let's Encrypt CA will be cross-signed under the same IdenTrust CA that issued the cert for https://letsencrypt.org/. So Let's Encrypt certificates should work wherever that site works (which includes Chrome and Safari, at least on my MacBook).
> Can every CA support issuing certs this way please? :)
I can't speak for other CAs, but we are definitely open to other CAs re-using technologies from Let's Encrypt to automate their operations. It would be even better for them to collaborate in developing the protocol. That's why we wrote ACME up using the IETF's document format, so that it can be developed in the IETF's open process with many stakeholders involved.
https://www.identrustssl.com/ authenticates fine for me in both Firefox and Chrome, and the certificate issuers for both that site and https://letsencrypt.org/ is in fact the same. I did notice that the IdentTrustSSL certificate has been issued yesterday, so this might be an issue of wrong clocks on your end.
What kind of impact is Let's Encrypt going to have on the CA industry? I'm not that familiar with the current state of the CA companies, nor do I understand this industry well enough to know if this is going to be a major hit to them or not.
Is there any reason why a company would prefer a CA other than Let's Encrypt?
The impact depends largely on their ability to get their root certificate into all of the browsers. It'll be interesting to see what happens with older versions of browsers as well, since if they start with a brand new root certificate then I'm not sure what happens with the older browsers.
If they can get their certificate into all of the browsers then it's possible they could achieve broad adoption for domain-verified certificates. There will still be a market for other validation types (organization validated and extended validation, for example) though.
It will cost existing CAs a lot of business. We already had free certs from StartSSL, but they were for non-commercial purposes only.
I imagine a lot of shared hosting companies who currently resell SSL certs to their own customers will be switching to this next year.
I will certainly use them, and will only recommend them and nobody else. The only reason I'd ever look at one of the old CAs now, is for EV certs. But 99% of the time, people don't need an EV cert.
The ultimate vision is to make it even easier than that -- you set the "turn on HTTPS" option, and the platform auto-configures HTTPS with a certificate and appropriate ciphers. That will require upgrades to apache, nginx, IIS, etc., though, so in the meantime, we have the "lets-encrypt" script to semi-automate things.
Great project! Please also provide a yum repository and instructions (and any others you feel are popular enough). You may want to look at the way SSLMate does it, with an operating system drop down selection (Debian, Ubuntu, RedHat, Arch, Mac, Other).
We are actually hoping to have packages shipping from the official OS repositories, so you won't even have to get the package from us. (If anyone wants to help with this aspect, please get in touch.)
Does this kill the business model for normal CAs, or is there something worth going to another CA for?
Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?
Can someone clarify whether LE will check if there is already a signed SSL cert for the domain, and it contains the same information? For example, via the SSL Observatory?
Doing this would prevent a point in time vulnerability in DNS (temporary mitm showing a different IP for the domain) or direct mitm of the connection to the webserver. Otherwise the attacker could get a signed cert for https://peacenik.org, and then present that to activists that it mitms.
Yes, we plan to apply a few mitigations of this type. Part of the idea of the "Proof of Possession of a Prior Key" challenge is so that if a web server requests a cert for a domain with an existing certificate, we can ask them to prove that they hold that certificate.
I had a hard time un-packing this for a minute so I want to try and clarify.
The part about proving to Let's Encrypt is problematic for sites that do not already have TLS on the example.com domain. Any plain HTTP request that Let's Encrypt makes to example.com to validate that you've put up some content on the server is susceptible to a MITM attack. I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.
The MITM problem with requests to example.com doesn't exist if example.com is already set up for HTTPS, which is probably why the examples on the technical description show requests for https://example.com/8303. I was confused about that at first because Let's Encrypt is largely targeted towards people without any TLS encryption yet.
Why caring at all about OCSP/CRL revocations that don't work anyway (https://www.imperialviolet.org/2014/04/29/revocationagain.ht...)? If you have an agent running on the webserver, you're 99% close to simply use short-lived certs. Just issue 1-week certs and be done with.
Getting to short-lived certificates is a goal, but the reality for now is that OCSP and CRLs are what implementations require, and what the CABF Baseline Requirements require. So we'll need to start with those.
Suppose I somehow get control of a machine on the same network as a server that doesn't use Let's Encrypt. I can probably ARP spoof it pretty easily. If it has a signed certificate from a different CA, I can't MITM it without people noticing. Or I couldn't, until now! Because I can now "control" the server's responses, I can easily get Let's Encrypt to authorize a new key pair giving my control over that domain. I can now generate valid certs for my MITM keys.
If the server were already using Let's Encrypt, I couldn't create a new controlling key pair. The "How It Works" doesn't talk about that, but search the RFC for "recovery token". But if the server isn't using Let's Encrypt, what would stop me from doing this?
Of course, I'm actually on the other end of it. To project myself, do I really have to at least register a controlling key pair with Let's Encrypt and any other browser-supported CAs that adopt this protocol?
Will using a certificate from letsencrypt.org require any kind of agreement on the part of web site administrators or visitors to their web sites?
The CA's I've looked at have these agreements. I'd like to avoid binding myself or the visitors to my website to any legal requirements from a third party.
Apparently they will use the same certs as implemented on letsencrypt.org, so the free certs will work without error on every client which trusts the "DST Root CA X3" CA. Can we collect a definitive list of clients which include this CA certificate? Similar to the list for StartSSL (https://forum.startcom.org/viewtopic.php?f=15&t=1802).
> Obtain a browser-trusted certificate and set it up on your web server
From the "RFC" on github:
> In the background, the web server contacts the CA and uses ACME to request that a certificate be issued for the intended domain name(s).
> Once the CA is satisfied, the certificate is issued and the web server automatically downloads and installs it, potentially notifying the operator via e-mail, SMS, etc.
This really sounds like they are generating the key pair, not just signing it. I think (hope) that's not the case, but clarity on this issue is pretty important.
They're generating the certificate, not the keys. Those are different things. You can probably think of the certificate as the computer equivalent of photo ID for the server.
They both show who you are (Driver's License: your name, cert: hostname), what you look like (DL: photo of you, cert: the key's fingerprint) and provide proof that they are genuine (DL: difficult and illegal fake, cert: practically impossible to do the math to forge a signature).
Note that they mention certificate singing requests. If the CA generated the keys, it wouldn't also need a CSR. It could just generate and send you the public and private keys and the signed certificate for them. However, it does need some information about the keys it's signing. You provide that information in the form of a CSR.
Does it deal with the case of SaaS apps for customer domains? Eg. Customer example.com rocks up to my SaaS app and wants to use myapp.example.com - currently creating
Yes. As the service provider, you can create a DNS record to verify "myapp.example.com", which is sufficient to get a certificate issued for it.
For a setup like this, you may still be better off getting a single wildcard certificate for "*.example.com", which (as far as we know currently), isn't possible through Let's Encrypt. But it's certainly possible to get these certificates through Let's Encrypt.
Here's a question I haven't seen anyone ask: What about email servers (SMTP/IMAP)? I need a good cert for that more than I do for https, personally. I could obviously have a web server up just to succeed at the challenge/response and get a certificate, but I actually just try to avoid running webservers at all these days, to be honest. I'm also not 100% that certificate would work.
The technical overview mentions that there can be various different kinds of challenges, so presumably you could use a DNS based one or even an email based one if it's implemented.
I am somewhat excited about letsencrypt, but isn't ownership verification via DNS not a bit, hmm, strange? After all, a proper certificate should defend against MITM attacks; so if an attacker would be able to take control over the target's DNS, he could easily create a certificate, which looks legit for all intended purposes. Or do I miss something in that regard?
The problem with their "howto" is that it completely ignores the fact that things like NAT and PAT need to be set up. Sure, the public IP's port 80 could be PAT-ed to the internal IP's port 80, but running "lets-encrypt example.com" can't magically PAT port 443 straight out of the package manager like that.
[+] [-] dale386|11 years ago|reply
[+] [-] joshmoz|11 years ago|reply
[+] [-] jeffreyrogers|11 years ago|reply
[+] [-] grey-area|11 years ago|reply
Things I wanted to know which were not immediately apparent:
Will it be broadly accepted from day one? Yes, apparently, though see the identrust issue below.
Will it generate a keypair but keep the private key on your server? Yes.
Will it work without having to babysit an interactive prompt? Yes.
Will it just let you generate key,csr,crt and do your own config changes? Yes.
Questions I still don't know the answer to:
Will it provide wildcard certs? No idea. I'd love it to be true as this is the part of current CA's which really irks me - the price gouging over something which costs them nothing more to provide. Can't see anything on the website about it.
How does it auto-renew, does it have to run all the time?
Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/
Can every CA support issuing certs this way please? :)
[+] [-] bifurcation|11 years ago|reply
With regard to your questions:
> Will it provide wildcard certs?
Not initially, but possibly in a future iteration.
Note that having an automatic CA addresses some of the use cases for wildcard certs. Namely, if you're using a wildcard cert just to avoid having to manage individual certs for foo-1.example.com through foo-N.example.com, you can just have them each automatically get a specific cert.
> How does it auto-renew, does it have to run all the time?
That will depend on the software running on the web server. The current "node-acme" and "lets-encrypt-preview" implementations in the Github repo are examples. Ultimately, in addition to these tools, it would be great to have ACME / LE support built into web server platforms, which are already running all the time.
> Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/
I don't know what the story is with that site, but I believe the Let's Encrypt CA will be cross-signed under the same IdenTrust CA that issued the cert for https://letsencrypt.org/. So Let's Encrypt certificates should work wherever that site works (which includes Chrome and Safari, at least on my MacBook).
> Can every CA support issuing certs this way please? :)
I can't speak for other CAs, but we are definitely open to other CAs re-using technologies from Let's Encrypt to automate their operations. It would be even better for them to collaborate in developing the protocol. That's why we wrote ACME up using the IETF's document format, so that it can be developed in the IETF's open process with many stakeholders involved.
[+] [-] yuriks|11 years ago|reply
[+] [-] Simucal|11 years ago|reply
Is there any reason why a company would prefer a CA other than Let's Encrypt?
[+] [-] aeden|11 years ago|reply
If they can get their certificate into all of the browsers then it's possible they could achieve broad adoption for domain-verified certificates. There will still be a market for other validation types (organization validated and extended validation, for example) though.
[+] [-] st3fan|11 years ago|reply
(Personally I don't care about any of those reasons - I just want my website to be SSL powered with an official cert and modern cipher configuration.)
[+] [-] mike-cardwell|11 years ago|reply
I imagine a lot of shared hosting companies who currently resell SSL certs to their own customers will be switching to this next year.
I will certainly use them, and will only recommend them and nobody else. The only reason I'd ever look at one of the old CAs now, is for EV certs. But 99% of the time, people don't need an EV cert.
[+] [-] grecy|11 years ago|reply
So if I have apache running http://example.com on port 80 and I follow the instructions ($ lets-encrypt example.com)
Will Apache now be correctly serving encrypted traffic on port 443 with a cert for https://example.com ?
[+] [-] bifurcation|11 years ago|reply
[+] [-] haroldp|11 years ago|reply
[+] [-] schizoidboy|11 years ago|reply
[+] [-] schoen|11 years ago|reply
[+] [-] drostie|11 years ago|reply
Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?
[+] [-] StavrosK|11 years ago|reply
[+] [-] Wilya|11 years ago|reply
I've never used those, and I don't know how relevant these are for companies, though.
[+] [-] sbierwagen|11 years ago|reply
[+] [-] angry_octet|11 years ago|reply
Doing this would prevent a point in time vulnerability in DNS (temporary mitm showing a different IP for the domain) or direct mitm of the connection to the webserver. Otherwise the attacker could get a signed cert for https://peacenik.org, and then present that to activists that it mitms.
[+] [-] bifurcation|11 years ago|reply
https://github.com/letsencrypt/acme-spec/blob/master/draft-b...
[+] [-] venomsnake|11 years ago|reply
If something could "just" prove identity without worrying about MITM we would not need the whole RSA stuff.
[+] [-] cakeface|11 years ago|reply
The part about proving to Let's Encrypt is problematic for sites that do not already have TLS on the example.com domain. Any plain HTTP request that Let's Encrypt makes to example.com to validate that you've put up some content on the server is susceptible to a MITM attack. I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.
The MITM problem with requests to example.com doesn't exist if example.com is already set up for HTTPS, which is probably why the examples on the technical description show requests for https://example.com/8303. I was confused about that at first because Let's Encrypt is largely targeted towards people without any TLS encryption yet.
[+] [-] giovannibajo1|11 years ago|reply
[+] [-] bifurcation|11 years ago|reply
[+] [-] debacle|11 years ago|reply
[+] [-] adamtj|11 years ago|reply
Suppose I somehow get control of a machine on the same network as a server that doesn't use Let's Encrypt. I can probably ARP spoof it pretty easily. If it has a signed certificate from a different CA, I can't MITM it without people noticing. Or I couldn't, until now! Because I can now "control" the server's responses, I can easily get Let's Encrypt to authorize a new key pair giving my control over that domain. I can now generate valid certs for my MITM keys.
If the server were already using Let's Encrypt, I couldn't create a new controlling key pair. The "How It Works" doesn't talk about that, but search the RFC for "recovery token". But if the server isn't using Let's Encrypt, what would stop me from doing this?
Of course, I'm actually on the other end of it. To project myself, do I really have to at least register a controlling key pair with Let's Encrypt and any other browser-supported CAs that adopt this protocol?
[+] [-] interested2|11 years ago|reply
The CA's I've looked at have these agreements. I'd like to avoid binding myself or the visitors to my website to any legal requirements from a third party.
[+] [-] don_draper|11 years ago|reply
[+] [-] higherpurpose|11 years ago|reply
https://supporters.eff.org/donate
[+] [-] freerk|11 years ago|reply
Firefox: Mozilla added the certificate in NSS 3.11.9 on 2008-01-31, see http://www-archive.mozilla.org/projects/security/pki/nss/nss... and https://bugzilla.mozilla.org/show_bug.cgi?id=411299 So Firefox starting with 3.0 works
Chrome: When the first Chrome came out it used Mozilla NSS which already included the certificate. Now Chrome uses the OS key store: http://www.chromium.org/Home/chromium-security/root-ca-polic...
Microsoft: The certificate is trusted by default since at least IE8 (http://www.herongyang.com/PKI/HTTPS-IE-8-Trusted-Root-CA-Cer...) and Windows automatically updates the certificates, see http://technet.microsoft.com/en-us/library/cc751157.aspx
Apple: Since iOS 2 (2008-07-11) (http://support.apple.com/en-us/HT2185) and at least since OS X Mavericks (http://support.apple.com/en-us/HT203120), but probably way earlier.
Java: Yes: https://gist.github.com/saltlakeryan/8479238
[+] [-] iancarroll|11 years ago|reply
[+] [-] tedunangst|11 years ago|reply
> Obtain a browser-trusted certificate and set it up on your web server
From the "RFC" on github:
> In the background, the web server contacts the CA and uses ACME to request that a certificate be issued for the intended domain name(s).
> Once the CA is satisfied, the certificate is issued and the web server automatically downloads and installs it, potentially notifying the operator via e-mail, SMS, etc.
This really sounds like they are generating the key pair, not just signing it. I think (hope) that's not the case, but clarity on this issue is pretty important.
[+] [-] CGamesPlay|11 years ago|reply
[1] https://letsencrypt.org/howitworks/technology/
[+] [-] adamtj|11 years ago|reply
They both show who you are (Driver's License: your name, cert: hostname), what you look like (DL: photo of you, cert: the key's fingerprint) and provide proof that they are genuine (DL: difficult and illegal fake, cert: practically impossible to do the math to forge a signature).
Note that they mention certificate singing requests. If the CA generated the keys, it wouldn't also need a CSR. It could just generate and send you the public and private keys and the signed certificate for them. However, it does need some information about the keys it's signing. You provide that information in the form of a CSR.
[+] [-] amatix|11 years ago|reply
[+] [-] duskwuff|11 years ago|reply
For a setup like this, you may still be better off getting a single wildcard certificate for "*.example.com", which (as far as we know currently), isn't possible through Let's Encrypt. But it's certainly possible to get these certificates through Let's Encrypt.
[+] [-] stormbrew|11 years ago|reply
[+] [-] yuriks|11 years ago|reply
[+] [-] radiospiel|11 years ago|reply
[+] [-] nnnnni|11 years ago|reply
Still, this is a great idea...
[+] [-] dewey|11 years ago|reply