11 ms·

Let's Encrypt: How It Works

408 points by espadrine 12y ago

radiospiel 12y ago
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?
- Wilya 12y ago
  Ownership verification is already done via DNS by existing CAs. If an attacker has full control over your DNS, he can already change the DNS records and trick a CA into delivering him a genuine certificate. This isn't really a MITM attack.
  - slasaus 12y ago
    "If an attacker has full control over your DNS" Shouldn't this be "over the CAs DNS resolver"? /edit well I guess if the attacker has control over your dns server, ofcours, but another vector is to spoof as the CAs resolver when the CA does a lookup for your domain.
    - pfg 12y ago
      Control of any name server used by the CA to resolve your hostname would be enough. That could be either the CAs DNS, any resolver in between (e.g. something like Google's Public DNS, which hopefully no real CA is using) or the authoritative name server of the domain. That is, unless you use DNSSEC.
  - mappu 12y ago
    What existing CA's offer this? The ones i've used (godaddy, startssl, namecheap/ssls.com rapidssl/positivessl) all wanted email verification iirc. EDIT: of course that's equivalent to verifying the MX. Never mind!
    - makomk 12y ago
      Email verification is worse - not only can it be attacked by modifying DNS, even a passive eavesdropper can generally get enough information to verify successfully.
    - Wilya 12y ago
      Gandi offers three validation methods: * DNS: you need to add a specific record to your DNS zone * File: you need to add a specific file to the root of a HTTP server listening on the domain name * Email: they send an email to admin@ on the domain All three are pretty much ways to check that you are the person in control of the associated DNS.
- pfg 12y ago
  I think you're right, however this is no different from how your average domain-verified certificate is issued (where you'd receive a confirmation mail to something like webmaster@example.com or serve a file given to you by the CA on a specific path). If an attacker manages to hijack your DNS, he could also modify your MX/A records and receive that mail/host the file. You could argue it's even slightly better, since with this solution, DNS is the only attack surface, whereas with email verification a vulnerable mail or web server would be enough. That is, if DNS is their only supported verification mechanism (which I don't think is true.)
grecy 12y ago
Sorry for the newbie question.... So if I have apache running http://example.com 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 https://example.com ?
- haroldp 12y ago
  That's the idea. It assumes you are using an OS with a package manager, and letting it manage your software and (to some extent) config files.
  - st3fan 12y ago
    And if you don't, or if you don't want to, it is easy to configure Apache or any web server manually. All you really need are three things: * the letsencrypt command line tool that will do the API dance to request the certificate * a file in your web site root with a ownership verification token or a DNS record with said token * a configuration file snippet for your server I'm sure all of this will be documented very well.
  - grecy 12y ago
    Nice, thanks. (I'm running on Ubuntu, so should be good)
- bifurcation 12y ago
  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.
  - ivok 12y ago
    So going from a single command to a different single command? How much simpler could it get?
haroldp 12y ago
It seems like the one thing this doesn't/can't address is the IP shortage. Does help much if example.com is virtual hosted on the same IP address as 100 other sites?
- silverwind 12y ago
  This really isn't a problem any more with SNI. With XP dying out, there's really no excuse anymore to not use it for shared hosting.
  - tedunangst 12y ago
    Python 2.7 (no SNI support) is the new Windows XP. Not a browser problem, but if you're building an API, it will lock people out. (sorry to beat a dead horse, but it's burned me recently and I think people are flipping the https only switch without awareness or consideration. doesn't mean "don't switch", but be aware.)
    - cmwright 12y ago
      Was surprised by this so just did a little research. It appears (https://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support/18579484#18579484 https://stackoverflow.com/questions/18578439/using-requests-... , http://docs.python-requests.org/en/latest/community/faq/#what-are-hostname-doesn-t-match-errors http://docs.python-requests.org/en/latest/community/faq/#wha...) that this is fixable in python 2.7 so not a show stopper, more of just a good to know.
      - tedunangst 12y ago
        Note that many people don't use requests, which has a rather large dependency chain, and sometimes you don't have much choice. e.g., feedparser doesn't use requests, nor is it likely to because of the dependencies. PEP 466 https://www.python.org/dev/peps/pep-0466 https://www.python.org/dev/peps/pep-0466 has more information, too.
    - kxo 12y ago
Simucal 12y ago
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?
- st3fan 12y ago
  Insurance, guarantees, EV certs, doing business with a big trusted company. All reasons to stay with your regular CA. (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.)
- aeden 12y ago
  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.
  - Supermighty 12y ago
    > since if they start with a brand new root certificate then I'm not sure what happens with the older browsers. IdenTrust will cross-sign Let's Encrypt root cert. I imagine they will keep it cross-signed, for backwards compatibility, once LE has their root cert in all the browsers.
    - iancarroll 12y ago
      You can't exactly undo cross signing without creating a new root CA - at some point they'll probably stop sending their root CA with the handshake (which is required when cross signing).
angry_octet 12y ago
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 https://peacenik.org, and then present that to activists that it mitms.
- bifurcation 12y ago
  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. https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md https://github.com/letsencrypt/acme-spec/blob/master/draft-b...
  - iancarroll 12y ago
    This is a horrible idea... I have numerous certs for my domain and collecting them all to prove to you I own them is not going to be fun.
    - angry_octet 12y ago
      You wouldn't be in a very good position to revoke them then, would you? For example, if we had another heartbleed.
      - iancarroll 12y ago
        I have access to manage them, however the private keys are either in various services or non exportable with AWS...
  - angry_octet 12y ago
    Also, it seems possible that large scale DOS could be performed by applying for domains (via DNS hijack) before the owners do, causing significant administrative burden to recover from. I would suggest allowing simpler revocations within some multiple of the DNS TTL value for the domain. I can also envision unscrupulous registrars pre-applying for LE certs for a fee, like $5.99 per month, and being very tardy and uncooperative about relinquishing control.
stormbrew 12y ago
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.
- yuriks 12y ago
  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.
  - bifurcation 12y ago
    That's correct. Also, if you've got an A/AAAA record for the domain name in question, you could run an ACME client on that box that spins up a temporary web server. That's what the node-acme demo client does. https://github.com/letsencrypt/node-acme/blob/master/lib/acme.js#L174 https://github.com/letsencrypt/node-acme/blob/master/lib/acm...
dale386 12y ago
Which browsers will trust Let's Encrypt certificates out of the box? There may be a major backwards compatibility gap here.
- jeffreyrogers 12y ago
  I'm not sure why you've been downvoted. This is a very reasonable concern and one that should be addressed.
- joshmoz 12y ago
  We'll have very broad compatibility from day one via cross-signing by IdenTrust.
  - dale386 12y ago
    Great, thanks -- I'm looking forward to your release.
Animats 12y ago
Keep track of when your certificate is going to expire, and automatically renew it. Or, all you have to do is let this new piece of software run periodically on your secure server. What could possibly go wrong?
- st3fan 12y ago
  Why so negative? Don't you think this is much better than the very manual ways that we now have? Automate it. Make it part of your maintenance scripts. Put it in a cron job. I think it will be a huge step forward.
  - jeffreyrogers 12y ago
    I think the OP was expressing concern over Let's Encrypt being installed on servers and potentially doing malicious things. Of course, if you apply this logic to Let's Encrypt you could just as well apply it to your web server or your mail server, or even your OS itself. At some point you just have to trust that the people and organizations that you're getting your software from aren't malicious... or you could write everything from scratch yourself.
    - Animats 12y ago
      Bear in mind that this is all vaporware. The github repository for "AJAX" just has a spec, no code. They're selling a security "solution" no one has evaluated yet. I'm bothered that this runs periodically. Will it auto-update code? How secure is the auto-update process? Who can run an auto-update? Does it run as root? If so, why? If it was a one-time manual run, that wouldn't be so bad. You can snapshot a system, run it, and see what it changed. When it gets to run on its own, that's harder to test.
      - pfg 12y ago
        I think they have stated that they want to get official packages into distro repositories, so you'd get whatever security your distribution's package manager provides, and your distribution of choice would act as a kind of gatekeeper against malicious code/updates the same way it does for other packages.
tedunangst 12y ago
Unfortunate choice of wording. From the web page: > 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 12y ago
  The technical overview [1] shows that the private key is on your server and never leaves it. [1] https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/
  - jdkasten 12y ago
    The open source python code also demonstrates it. https://github.com/letsencrypt/lets-encrypt-preview https://github.com/letsencrypt/lets-encrypt-preview
- adamtj 12y ago
  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.
  - grey-area 12y ago
venomsnake 12y ago
> Automatically prove to the Let’s Encrypt CA that you control the website If something could "just" prove identity without worrying about MITM we would not need the whole RSA stuff.
- cakeface 12y ago
  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 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.
  - iancarroll 12y ago
    > 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. FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.
    - organsnyder 12y ago
      Not sure how the self-signed cert would make things better. Couldn't an MITM attacker do the exact same thing? Presumably, the MITM attacker would already be the party making the (fraudulent) request to the CA, so they could submit their own fingerprint.
      - iancarroll 12y ago
schizoidboy 12y ago
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).
- schoen 12y ago
  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.)
  - mappu 12y ago
    Is it possible to get new packages into Jessie post-freeze?
    - dredmorbius 12y ago
      Generally not into the Debian repos, though it's possible the release manage could approve it. You can pin other releases for specific packages, though, and if this is well-designed it should have minimal other dependencies. Ideally it's simply requesting and installing a key.
    - schoen 12y ago
      I don't think it would make sense to start shipping this package in operating systems before public cert issuance starts, which is currently expected to be around next summer. It would be fairly confusing to web developers to be encouraged by the OS to run the client, only to have it immediately inform them that there are no CAs yet able to issue certs to them!
debacle 12y ago
I really like this and I am excited by the sponsor list. The self-signed cert notification in browsers is becoming more obnoxious every year.
drostie 12y ago
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?
- StavrosK 12y ago
  I'm thinking someone could spoof a DNS entry for the signing server and prove that they own any domain they want, is that prevented somehow?
  - sbierwagen 12y ago
    If an attacker can spoof DNS, they can just create A records that point to their own server, and MITM from that. Public key pinning would protect against that class of attacks: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...
    - StavrosK 12y ago
      Whose DNS layer? If they own the user's, no. If they own the server's, maybe, if they could convince the CA to sign a certificate they control. Otherwise, they couldn't really do anything.
- sbierwagen 12y ago
  It doesn't issue EV certs, so the business model for traditional CAs will be those.
  - raesene3 12y ago
    I don't think EV SSL certificates have been a big success (though that's just a personal opinion rather something backed with specific data) For me the differentiation in the browser presentation of EV against ordinary SSL doesn't provide much additional security. Most users don't notice the difference and even if they do, wouldn't remember which sites had an EV certificate, such that they would notice it changing back to non-EV
dewey 12y ago
Is this a wildcard certificate and will it cover subdomains that way? Couldn't find anything on the site clarifying that.
giovannibajo1 12y ago
Why caring at all about OCSP/CRL revocations that don't work anyway (https://www.imperialviolet.org/2014/04/29/revocationagain.html 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.
- bifurcation 12y ago
  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.
z3t4 12y ago
Wouldn't it be much easier if lets-encrypt just created the .crt .key files!? Rather then set it up automagically. You could have it run once a year via crontab. I would like to keep the control of my .conf files.
- jdkasten 12y ago
  That will be an option. Also, the current implementation only changes the SSLCertificateFile directive if you provide your own --key, --csr and already have an SSL vhost for the domain. (This one change is logged.)
zupreme 12y ago
Upside: This is an awesome idea and I really hope you can get support for this from browsers, the major operating systems, and smartphone makers. I, for one, usually want a cert when I request it (often as the last step before launching a product) and hate the wait imposed by Network Solutions, GoDaddy, and others. Downside: You are lowering the bar for SSL certs (no business registration verification, for example) which could open the door to malicious players impersonating established organizations (i.e. microsoft.phishme.com masquerading as Microsoft Corporation) and making it easier to dupe the vulnerable.
don_draper 12y ago
Note to self: Donate to EFF
- higherpurpose 12y ago
  Why leave for tomorrow what you can do today? https://supporters.eff.org/donate https://supporters.eff.org/donate
  - bifurcation 12y ago
    See also: https://sendto.mozilla.org/ https://sendto.mozilla.org/
  - pepr 12y ago
    I'm also happy to see EFF now accepts Bitcoin.
grey-area 12y ago
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/ https://www.identrustssl.com/ Can every CA support issuing certs this way please? :)
- bifurcation 12y ago
  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/ 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/ 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.
nnnnni 12y ago
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. Still, this is a great idea...
interested2 12y ago
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.
amatix 12y ago
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
- duskwuff 12y ago
  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.
rcthompson 12y ago
So is this something I can use in place of an auto-generated self-signed certificate for that headless linux box that I have running in the back of my closet and which I optimistically refer to as "my web server"?
- zanny 12y ago
  You can use startssl for that right now. They provide one year free noncommercial certs. By the time that one expires letsencrypt will be live.
Tepix 12y ago
Can it be used with tor to sign .onion hidden sites?
GordyMD 12y ago
Really excited about this!
smilepet_26 12y ago
This is super awesome. It will help drive a better and secure web. Hats off to LetsEncrypt team.
freerk 12y ago
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 https://forum.startcom.org/viewtopic.php?f=15&t=1802). 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-3.11.9/nss-3.11.9-release-notes.html http://www-archive.mozilla.org/projects/security/pki/nss/nss... and https://bugzilla.mozilla.org/show_bug.cgi?id=411299 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-policy 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-Certificate-Authorities.html 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 http://technet.microsoft.com/en-us/library/cc751157.aspx Apple: Since iOS 2 (2008-07-11) (http://support.apple.com/en-us/HT2185 http://support.apple.com/en-us/HT2185) and at least since OS X Mavericks (http://support.apple.com/en-us/HT203120 http://support.apple.com/en-us/HT203120), but probably way earlier. Java: Yes: https://gist.github.com/saltlakeryan/8479238 https://gist.github.com/saltlakeryan/8479238
- iancarroll 12y ago
  Chrome does not use NSS. It uses the underlying OS root store.
  - freerk 12y ago
    Sure, fixed it. Thanks!
adamtj 12y ago
How is this not really bad? 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?

408 points by espadrine 12y ago

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?

Wilya 12y ago
Ownership verification is already done via DNS by existing CAs. If an attacker has full control over your DNS, he can already change the DNS records and trick a CA into delivering him a genuine certificate. This isn't really a MITM attack.
- slasaus 12y ago
  "If an attacker has full control over your DNS" Shouldn't this be "over the CAs DNS resolver"? /edit well I guess if the attacker has control over your dns server, ofcours, but another vector is to spoof as the CAs resolver when the CA does a lookup for your domain.
  - pfg 12y ago
    Control of any name server used by the CA to resolve your hostname would be enough. That could be either the CAs DNS, any resolver in between (e.g. something like Google's Public DNS, which hopefully no real CA is using) or the authoritative name server of the domain. That is, unless you use DNSSEC.
- mappu 12y ago
  What existing CA's offer this? The ones i've used (godaddy, startssl, namecheap/ssls.com rapidssl/positivessl) all wanted email verification iirc. EDIT: of course that's equivalent to verifying the MX. Never mind!
  - makomk 12y ago
    Email verification is worse - not only can it be attacked by modifying DNS, even a passive eavesdropper can generally get enough information to verify successfully.
  - Wilya 12y ago
    Gandi offers three validation methods: * DNS: you need to add a specific record to your DNS zone * File: you need to add a specific file to the root of a HTTP server listening on the domain name * Email: they send an email to admin@ on the domain All three are pretty much ways to check that you are the person in control of the associated DNS.
pfg 12y ago
I think you're right, however this is no different from how your average domain-verified certificate is issued (where you'd receive a confirmation mail to something like webmaster@example.com or serve a file given to you by the CA on a specific path). If an attacker manages to hijack your DNS, he could also modify your MX/A records and receive that mail/host the file. You could argue it's even slightly better, since with this solution, DNS is the only attack surface, whereas with email verification a vulnerable mail or web server would be enough. That is, if DNS is their only supported verification mechanism (which I don't think is true.)

grecy 12y ago

Sorry for the newbie question.... So if I have apache running http://example.com 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 https://example.com ?

haroldp 12y ago
That's the idea. It assumes you are using an OS with a package manager, and letting it manage your software and (to some extent) config files.
- st3fan 12y ago
  And if you don't, or if you don't want to, it is easy to configure Apache or any web server manually. All you really need are three things: * the letsencrypt command line tool that will do the API dance to request the certificate * a file in your web site root with a ownership verification token or a DNS record with said token * a configuration file snippet for your server I'm sure all of this will be documented very well.
- grecy 12y ago
  Nice, thanks. (I'm running on Ubuntu, so should be good)
bifurcation 12y ago
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.
- ivok 12y ago
  So going from a single command to a different single command? How much simpler could it get?

haroldp 12y ago

It seems like the one thing this doesn't/can't address is the IP shortage. Does help much if example.com is virtual hosted on the same IP address as 100 other sites?

silverwind 12y ago
This really isn't a problem any more with SNI. With XP dying out, there's really no excuse anymore to not use it for shared hosting.
- tedunangst 12y ago
  Python 2.7 (no SNI support) is the new Windows XP. Not a browser problem, but if you're building an API, it will lock people out. (sorry to beat a dead horse, but it's burned me recently and I think people are flipping the https only switch without awareness or consideration. doesn't mean "don't switch", but be aware.)
  - cmwright 12y ago
    Was surprised by this so just did a little research. It appears (https://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support/18579484#18579484 https://stackoverflow.com/questions/18578439/using-requests-... , http://docs.python-requests.org/en/latest/community/faq/#what-are-hostname-doesn-t-match-errors http://docs.python-requests.org/en/latest/community/faq/#wha...) that this is fixable in python 2.7 so not a show stopper, more of just a good to know.
    - tedunangst 12y ago
      Note that many people don't use requests, which has a rather large dependency chain, and sometimes you don't have much choice. e.g., feedparser doesn't use requests, nor is it likely to because of the dependencies. PEP 466 https://www.python.org/dev/peps/pep-0466 https://www.python.org/dev/peps/pep-0466 has more information, too.
  - kxo 12y ago

Simucal 12y ago

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?

st3fan 12y ago
Insurance, guarantees, EV certs, doing business with a big trusted company. All reasons to stay with your regular CA. (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.)
aeden 12y ago
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.
- Supermighty 12y ago
  > since if they start with a brand new root certificate then I'm not sure what happens with the older browsers. IdenTrust will cross-sign Let's Encrypt root cert. I imagine they will keep it cross-signed, for backwards compatibility, once LE has their root cert in all the browsers.
  - iancarroll 12y ago
    You can't exactly undo cross signing without creating a new root CA - at some point they'll probably stop sending their root CA with the handshake (which is required when cross signing).

angry_octet 12y ago

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 https://peacenik.org, and then present that to activists that it mitms.

bifurcation 12y ago
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. https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md https://github.com/letsencrypt/acme-spec/blob/master/draft-b...
- iancarroll 12y ago
  This is a horrible idea... I have numerous certs for my domain and collecting them all to prove to you I own them is not going to be fun.
  - angry_octet 12y ago
    You wouldn't be in a very good position to revoke them then, would you? For example, if we had another heartbleed.
    - iancarroll 12y ago
      I have access to manage them, however the private keys are either in various services or non exportable with AWS...
- angry_octet 12y ago
  Also, it seems possible that large scale DOS could be performed by applying for domains (via DNS hijack) before the owners do, causing significant administrative burden to recover from. I would suggest allowing simpler revocations within some multiple of the DNS TTL value for the domain. I can also envision unscrupulous registrars pre-applying for LE certs for a fee, like $5.99 per month, and being very tardy and uncooperative about relinquishing control.

stormbrew 12y ago

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.

yuriks 12y ago
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.
- bifurcation 12y ago
  That's correct. Also, if you've got an A/AAAA record for the domain name in question, you could run an ACME client on that box that spins up a temporary web server. That's what the node-acme demo client does. https://github.com/letsencrypt/node-acme/blob/master/lib/acme.js#L174 https://github.com/letsencrypt/node-acme/blob/master/lib/acm...

dale386 12y ago

Which browsers will trust Let's Encrypt certificates out of the box? There may be a major backwards compatibility gap here.

jeffreyrogers 12y ago
I'm not sure why you've been downvoted. This is a very reasonable concern and one that should be addressed.
joshmoz 12y ago
We'll have very broad compatibility from day one via cross-signing by IdenTrust.
- dale386 12y ago
  Great, thanks -- I'm looking forward to your release.

Animats 12y ago

Keep track of when your certificate is going to expire, and automatically renew it. Or, all you have to do is let this new piece of software run periodically on your secure server. What could possibly go wrong?

st3fan 12y ago
Why so negative? Don't you think this is much better than the very manual ways that we now have? Automate it. Make it part of your maintenance scripts. Put it in a cron job. I think it will be a huge step forward.
- jeffreyrogers 12y ago
  I think the OP was expressing concern over Let's Encrypt being installed on servers and potentially doing malicious things. Of course, if you apply this logic to Let's Encrypt you could just as well apply it to your web server or your mail server, or even your OS itself. At some point you just have to trust that the people and organizations that you're getting your software from aren't malicious... or you could write everything from scratch yourself.
  - Animats 12y ago
    Bear in mind that this is all vaporware. The github repository for "AJAX" just has a spec, no code. They're selling a security "solution" no one has evaluated yet. I'm bothered that this runs periodically. Will it auto-update code? How secure is the auto-update process? Who can run an auto-update? Does it run as root? If so, why? If it was a one-time manual run, that wouldn't be so bad. You can snapshot a system, run it, and see what it changed. When it gets to run on its own, that's harder to test.
    - pfg 12y ago
      I think they have stated that they want to get official packages into distro repositories, so you'd get whatever security your distribution's package manager provides, and your distribution of choice would act as a kind of gatekeeper against malicious code/updates the same way it does for other packages.

tedunangst 12y ago

Unfortunate choice of wording. From the web page: > 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 12y ago
The technical overview [1] shows that the private key is on your server and never leaves it. [1] https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/
- jdkasten 12y ago
  The open source python code also demonstrates it. https://github.com/letsencrypt/lets-encrypt-preview https://github.com/letsencrypt/lets-encrypt-preview
adamtj 12y ago
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.
- grey-area 12y ago

venomsnake 12y ago

> Automatically prove to the Let’s Encrypt CA that you control the website If something could "just" prove identity without worrying about MITM we would not need the whole RSA stuff.

cakeface 12y ago
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 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.
- iancarroll 12y ago
  > 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. FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.
  - organsnyder 12y ago
    Not sure how the self-signed cert would make things better. Couldn't an MITM attacker do the exact same thing? Presumably, the MITM attacker would already be the party making the (fraudulent) request to the CA, so they could submit their own fingerprint.
    - iancarroll 12y ago

schizoidboy 12y ago

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).

schoen 12y ago
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.)
- mappu 12y ago
  Is it possible to get new packages into Jessie post-freeze?
  - dredmorbius 12y ago
    Generally not into the Debian repos, though it's possible the release manage could approve it. You can pin other releases for specific packages, though, and if this is well-designed it should have minimal other dependencies. Ideally it's simply requesting and installing a key.
  - schoen 12y ago
    I don't think it would make sense to start shipping this package in operating systems before public cert issuance starts, which is currently expected to be around next summer. It would be fairly confusing to web developers to be encouraged by the OS to run the client, only to have it immediately inform them that there are no CAs yet able to issue certs to them!

debacle 12y ago

I really like this and I am excited by the sponsor list. The self-signed cert notification in browsers is becoming more obnoxious every year.

drostie 12y ago

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?

StavrosK 12y ago
I'm thinking someone could spoof a DNS entry for the signing server and prove that they own any domain they want, is that prevented somehow?
- sbierwagen 12y ago
  If an attacker can spoof DNS, they can just create A records that point to their own server, and MITM from that. Public key pinning would protect against that class of attacks: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...
  - StavrosK 12y ago
    Whose DNS layer? If they own the user's, no. If they own the server's, maybe, if they could convince the CA to sign a certificate they control. Otherwise, they couldn't really do anything.
sbierwagen 12y ago
It doesn't issue EV certs, so the business model for traditional CAs will be those.
- raesene3 12y ago
  I don't think EV SSL certificates have been a big success (though that's just a personal opinion rather something backed with specific data) For me the differentiation in the browser presentation of EV against ordinary SSL doesn't provide much additional security. Most users don't notice the difference and even if they do, wouldn't remember which sites had an EV certificate, such that they would notice it changing back to non-EV

dewey 12y ago

Is this a wildcard certificate and will it cover subdomains that way? Couldn't find anything on the site clarifying that.

giovannibajo1 12y ago

Why caring at all about OCSP/CRL revocations that don't work anyway (https://www.imperialviolet.org/2014/04/29/revocationagain.html 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.

bifurcation 12y ago
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.

z3t4 12y ago

Wouldn't it be much easier if lets-encrypt just created the .crt .key files!? Rather then set it up automagically. You could have it run once a year via crontab. I would like to keep the control of my .conf files.

jdkasten 12y ago
That will be an option. Also, the current implementation only changes the SSLCertificateFile directive if you provide your own --key, --csr and already have an SSL vhost for the domain. (This one change is logged.)

zupreme 12y ago

Upside: This is an awesome idea and I really hope you can get support for this from browsers, the major operating systems, and smartphone makers. I, for one, usually want a cert when I request it (often as the last step before launching a product) and hate the wait imposed by Network Solutions, GoDaddy, and others. Downside: You are lowering the bar for SSL certs (no business registration verification, for example) which could open the door to malicious players impersonating established organizations (i.e. microsoft.phishme.com masquerading as Microsoft Corporation) and making it easier to dupe the vulnerable.

don_draper 12y ago

Note to self: Donate to EFF

higherpurpose 12y ago
Why leave for tomorrow what you can do today? https://supporters.eff.org/donate https://supporters.eff.org/donate
- bifurcation 12y ago
  See also: https://sendto.mozilla.org/ https://sendto.mozilla.org/
- pepr 12y ago
  I'm also happy to see EFF now accepts Bitcoin.

grey-area 12y ago

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/ https://www.identrustssl.com/ Can every CA support issuing certs this way please? :)

bifurcation 12y ago
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/ 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/ 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.

nnnnni 12y ago

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. Still, this is a great idea...

interested2 12y ago

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.

amatix 12y ago

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

duskwuff 12y ago
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.

rcthompson 12y ago

So is this something I can use in place of an auto-generated self-signed certificate for that headless linux box that I have running in the back of my closet and which I optimistically refer to as "my web server"?

zanny 12y ago
You can use startssl for that right now. They provide one year free noncommercial certs. By the time that one expires letsencrypt will be live.

Tepix 12y ago

Can it be used with tor to sign .onion hidden sites?

GordyMD 12y ago

Really excited about this!

smilepet_26 12y ago

This is super awesome. It will help drive a better and secure web. Hats off to LetsEncrypt team.

freerk 12y ago

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 https://forum.startcom.org/viewtopic.php?f=15&t=1802). 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-3.11.9/nss-3.11.9-release-notes.html http://www-archive.mozilla.org/projects/security/pki/nss/nss... and https://bugzilla.mozilla.org/show_bug.cgi?id=411299 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-policy 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-Certificate-Authorities.html 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 http://technet.microsoft.com/en-us/library/cc751157.aspx Apple: Since iOS 2 (2008-07-11) (http://support.apple.com/en-us/HT2185 http://support.apple.com/en-us/HT2185) and at least since OS X Mavericks (http://support.apple.com/en-us/HT203120 http://support.apple.com/en-us/HT203120), but probably way earlier. Java: Yes: https://gist.github.com/saltlakeryan/8479238 https://gist.github.com/saltlakeryan/8479238

iancarroll 12y ago
Chrome does not use NSS. It uses the underlying OS root store.
- freerk 12y ago
  Sure, fixed it. Thanks!

adamtj 12y ago

How is this not really bad? 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?