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.
Not initially, but possibly in a future iteration.
OK, good to know.
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.
I see, thanks, hence the emphasis on protocol not product. Great idea, let's hope it takes off, it'd be really nice to be able to just add a config for ssl_on and let the server deal with the rest. I suppose it's early days for discussions with server providers?
I don't know what the story is with that site
It's weird how old and busted CA sites are, almost without exception, I guess I shouldn't be surprised that a place selling certs doesn't even use them properly, but as you point out, they've issued letsencrypt.org, and that works fine. Good to know.
So Let's Encrypt certificates should work wherever that site works
This would be a great line for your how it works, rather than browser-trusted, which could mean anything really.
Thanks again for this great idea, looking forward to trying it out.
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.
> 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.
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).
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.
It's very, very hard for traditional CAs to compete with free, trusted in all major platforms and with dead simple set up. Hopefully this sort of scheme, combined with the added trust of Certificate Transparency, can kill off most traditional CAs.
The only reason I would still buy 1 certificate is for wildcard support.
Wait. Where can I get free certs today? Or did you mean once this service goes live?
I've used StartSSL, but somehow messed up the process and can't issue a new cert unless I pay to revoke the current. Even then their free certs expire in a year.
The only other free cert I found was from Comodo, but it expires after 90 days.
So, I wouldn't exactly say the only reason to pay for a cert is for wildcard support.
Yes, I was saying once this service goes live. But currently I've had 0 issues with StartSSL including renewals and getting multiple certs for a single domain. You do not need to revoke to get more certs from it in my experience at least. Paying for certs is just generally pointless right now even.
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.)
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!
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.
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?
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.
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
I wouldn't login to my bank's website if it didn't present me with green EV url bar. Same with paypal, amazon and basically anything to do with money has to have EV for me. I might be slightly paranoid, but I thought the point of ssl was EV.
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.
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.
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.
> 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.
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.
I suppose you're correct, I wasn't thinking that the attacker would also submit the request. I guess if you're MITMing CA requests you're screwed anyhow.
I don't see how using TLS would prevent MITM in this case. TLS only prevents MITM if you know public key or if it's been signed by a CA, but neither is the case here.
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.
Looks to me like it generates the keys locally OR you can specify the keys if you like. But since the private key doesn't leave your server, it doesn't really matter either way.
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.
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.
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?
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.)
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.
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.
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.
* 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.
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.
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.
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"?
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.)
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?
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.)
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 has more information, too.
I take it you've read the source code of Apache and Nginx then and confirmed that they aren't doing anything malicious as well? :)
In any practical security system you are always going to have to trust that certain components are doing what they say they're doing. Fortunately, Let's Encrypt is from a reputable group, and sponsored by organizations with good reputations (Mozilla, EFF, etc.), which is about as good as you can hope for.
Many people draw a line between one time trust and continuous trust. If this thing can update the certs on my server whenever it likes, that's substantially more trust than permitting it to install a cert exactly once. If, for example, it has a bug that permits a malicious upstream to overwrite arbitrary files, the window of vulnerability expands from "the CA is pwned this instant" to "the CA will at any future time ever be pwned".
Easy fix: Run the tool as its own user, give write permission to cert & key files to that user. If you're really paranoid, run it in a jail that only has access to those files. No different than proper security for any other system process.
Yes, I need to trust some things. But I can limit the amount of trust I need to have by limiting the number of things to run. I can add a reminder to my calendar to say "hey renew your certs", or better yet I can add a check to my existing monitoring service to look at expiration dates. Why run a whole new persistent service just for this?
There won't be any sort of requirement to allow our tools to run automatically. But the existing track record of expiring certs suggest that some people are having trouble remembering to do the renewals manually, so it may be useful to have a tool that does it automatically for people who want that.
The vast majority of sites fall into the category of "encryption would be nice, but not worth the time." All of my hobby sites (various forums, a site for my choir, etc.) fall into that category. Automagic TLS done right is an improvement from no TLS, IMHO, even if it comes with its own new set of potential attack vectors.
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.
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.
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.
That is exactly correct. And the client will be open source code written in Python.
It's not like "take this binary blob from us and run it as root on your machine", it's like "we have an open source project that would like to work with your upstream OS distributor on exactly the same terms as, and in exactly the same way as, the other tools that you're using on your server".
Edit: If you want to follow along with, audit, contribute to, help package, etc., our preview client, it is available at
We will also welcome people to create their own interoperable software, so if you don't want to run our client or any of its dependencies, or if it doesn't work well with your serving environment, you can create your own alternative. (Hosting providers or CDNs that want certs for sites they host, for example, could create their own tools to deploy them, instead of using our tools.)
It's a balance, at the end of the day. I won't be auto-updating on my server because it's not hard for me to do that myself. But if someone is just running a site where HTTPS isn't particularly important (a personal blog, say) then the convenience might outweigh the very slight security concern - better they are using HTTPS at all, if the alternative to convenience is HTTP.
You're probably already doing something similar if you use OCSP stapling.
It needs to run continously for revocation purposes but you don't notice because it's integrated in your web server. This could be done in the same way.
