Our First Certificate Is Now Live(letsencrypt.org)
letsencrypt.org
Our First Certificate Is Now Live
https://letsencrypt.org/2015/09/14/our-first-cert.html
255 comments
We need to demonstrate proper issuance under our root and gain confidence in our live systems before getting cross-signed. Issuing without a cross-signature for a bit is how we do this.
It's a bootstrapping process, I don't think they can be accepted as a root certificate until they have proved their automated issuing system it working.
One way to prove that their automated issuing system is working, is to turn it on.
Looks like they have set it up to only issue certificates for white-listed domains in the beta program, and they will switch to General availability in the Week of November 16th.
One way to prove that their automated issuing system is working, is to turn it on.
Looks like they have set it up to only issue certificates for white-listed domains in the beta program, and they will switch to General availability in the Week of November 16th.
Baby steps. This is a huge step forward, and I'm willing to cut them some slack considering they're about to shake up an entire industry.
EDIT: Kudos everyone working on Let's Encrypt. You're doing awesome work.
EDIT: Kudos everyone working on Let's Encrypt. You're doing awesome work.
For real. This is so damn awesome I feel like letting out a Howard Dean like yell.
+1, this is a huge step in the right direction.
> A cross-signature will be in place before general availability.
https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
What about after general availability?
You should read back over their blog to see how much planning has gone into this so far. This isn't a single-file LAMP app running on a VPS, they're setting up a CA trustworthy enough to have its roots in all the major browsers
You keep saying the word "broken" when nothing is broken at all, just the certificates are only useful in limited contexts.
Even a "useful in limited contexts" clock is right twice a day.
They aren't making it generally available to the public yet, only to certain beta folks who know what they are getting. It isn't broken out of the box since it isn't 'out of the box' yet.
According to TFA, Firefox already trusts this cert.
Incorrect. Inclusion into the Firefox root store is being tracked in https://bugzil.la/1204656 and has not yet been resolved.
Firefox trusts the cert on TFA because letsencrypt.org itself is using a certificate signed by IdenTrust.
Firefox trusts the cert on TFA because letsencrypt.org itself is using a certificate signed by IdenTrust.
Looking at http://helloworld.letsencrypt.org/ I see:
> Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself. Specifics will depend on your browser. In Firefox, just click the link.
> Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself. Specifics will depend on your browser. In Firefox, just click the link.
Wow the Firefox process to add a root is pretty simple! Downloading a file is more difficult. Adding an exception for a self-signed cert is scary.
But adding a new root? Little popup, check a box and OK-you-go!
But adding a new root? Little popup, check a box and OK-you-go!
It's scary how easy it is to add new roots on all major platforms. You just click on the CA link and get a response with the appropriate MIME type back, then:
* Windows gives you a helpful little wizard wherein you click "next" a few times.
* Firefox gives you a dialog with 3 checkboxes; check them and click okay.
* iOS sends you to settings, and asks you if you want to trust the given CA.
* OS X hands it to Keychain Access, where you have to select 'trust' from a dropdown and maybe enter a keychain password; it's a bit less intuitive.
* Chrome uses the OS trust store, so it hands it off to the OS while claiming it's a dangerous filetype.
* Windows gives you a helpful little wizard wherein you click "next" a few times.
* Firefox gives you a dialog with 3 checkboxes; check them and click okay.
* iOS sends you to settings, and asks you if you want to trust the given CA.
* OS X hands it to Keychain Access, where you have to select 'trust' from a dropdown and maybe enter a keychain password; it's a bit less intuitive.
* Chrome uses the OS trust store, so it hands it off to the OS while claiming it's a dangerous filetype.
You're incorrect about Windows. If you just click next several times the cert will not be added to trusted. To do that you'll have to override default settings in a non trivial way (deselect "Choose cert store automatically" and select the correct cert store) on one of the steps
I'm sure that's intentional design
I'm sure that's intentional design
Maybe it changed at some point (8?), or my memory's fuzzy. I haven't looked at it in several years.
Either way, trusting a root CA generally looks far less threatening than the self-signed certificate warnings.
Either way, trusting a root CA generally looks far less threatening than the self-signed certificate warnings.
Ah, that is a bit misleading. When it says "just click the link," it's referring to the process for installing the root certificate.
It should read "specifics will depend on your browser. In Firefox, just click the link [to the .der file, and you will see a prompt allowing you to trust it.]" It looks like this: http://imgur.com/dzC89xI
Without importing the root, Firefox absolutely distrusts https://helloworld.letsencrypt.org/, and will do so until Bug 1204656 is marked RESOLVED FIXED. :)
It should read "specifics will depend on your browser. In Firefox, just click the link [to the .der file, and you will see a prompt allowing you to trust it.]" It looks like this: http://imgur.com/dzC89xI
Without importing the root, Firefox absolutely distrusts https://helloworld.letsencrypt.org/, and will do so until Bug 1204656 is marked RESOLVED FIXED. :)
Actually, 1204656 doesn't need to be fixed in order to get Firefox to accept this cert. As https://letsencrypt.org/certificates/ explains,
> IdenTrust will cross-sign our intermediates. This will allow our end certificates to be accepted by all major browsers while we propagate our own root.
The cross-signature is expected to happen before the mainstream browsers finish processing our application to be a root CA. That will be the main initial mechanism by which browsers trust our certificates.
> IdenTrust will cross-sign our intermediates. This will allow our end certificates to be accepted by all major browsers while we propagate our own root.
The cross-signature is expected to happen before the mainstream browsers finish processing our application to be a root CA. That will be the main initial mechanism by which browsers trust our certificates.
Touché :)
the iSRG root is not in FF[1][2]...you're visiting the http version of that URL.
1 http://idzr.org/y1pg
2 http://idzr.org/ee91
1 http://idzr.org/y1pg
2 http://idzr.org/ee91
Hmm, that's taking a long time assuming Mozilla itself is involved in the project.
My understanding is that Mozilla is primarily just a sponsor of ISRG, the non-profit behind Let's Encrypt. Some of their sponsorship includes dedicated engineering time, but LetsEncrypt still has to pass all the same audits and requirements as any other CA, as defined in the Mozilla CA Certificate Policy at https://www.mozilla.org/en-US/about/governance/policies/secu....
Mozilla's not a nepotist with regard to its root store. :-)
Mozilla's not a nepotist with regard to its root store. :-)
Firefox doesn't trust the cert yet. The application to be added to the root store is here https://bugzilla.mozilla.org/show_bug.cgi?id=1204656
It's amazing that it takes a free provider to make things simple:
https://letsencrypt.org/howitworks/
I'd actually pay more than I do now for SSL certs to get that kind of simplicity.
https://letsencrypt.org/howitworks/
I'd actually pay more than I do now for SSL certs to get that kind of simplicity.
I run https://certsimple.com: we only do EV certificates, we're the fastest place to get an EV cert, we check as much as we can before you pay us a cent, and our application process is 80 seconds.
These shameless plugs are getting really annoying. We know about you, we know CloudFlare and Let's Encrypt are kinda competitors with their free certificates, but you don't have to comment on each post about them. Really, stop annoying us - it doesn't do you any good, honestly!
These shameless plugs are getting really annoying. We know about you
I for one had never heard of these guys and appreciate the mention. Besides, as far as I can recall, it's never been considered problematic to promote your own service on HN as long as the mention is topical and done tastefully.
I for one had never heard of these guys and appreciate the mention. Besides, as far as I can recall, it's never been considered problematic to promote your own service on HN as long as the mention is topical and done tastefully.
In this case, the previous commenter was explicitly asking for advice about how to get certificates more conveniently today, so the replies about existing services that can do so seem quite relevant.
It's like trying to sell a Ferrari to a guy who's looking for a regular car...
Maybe so, but you know every regular guy driving a regular car would rather have a Ferrari and might even spend time looking at them even though he can't buy one.
You're wrong. EV is a scam. I can afford to buy EV for most of my sites, but I don't do it. Because consumers don't really care. Even HN doesn't have an EV! Ferrari is what everybody wants, EV is a different story! And stop downvoting all my comments - it shows your subpar human material. Downvote my main point and stop right there. No need to go aggressive and try to silence me and not comment further, because you will "punish" me further as well.
As per the guidelines, please keep discussions civil on HN and please don't complain about being downvoted.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
I am civil, but those who can't help the sick urge to downvote every single comment of mine although they all represent the same points are not civilized.
No, cpach is right. You can't post comments like "it shows your subpar human material" to Hacker News. Personal attacks are not allowed here, regardless of whether someone downvoted unfairly.
There's also the guideline specifically asking you not to go on about being downvoted.
https://news.ycombinator.com/newsguidelines.html
There's also the guideline specifically asking you not to go on about being downvoted.
https://news.ycombinator.com/newsguidelines.html
Most are just suggestions, not law. I stand by what I said. Being vindictive is not civilized. I didn't make personal attacks - I have no idea who downvoted me.
Personal attacks can be anonymous, so that's a red herring. And HN's guidelines may not be laws, but neither are they optional—we ban accounts that violate them repeatedly.
It's not hard to see what kind of discourse we're going for here. What's hard is to stick to it when you're feeling that someone is subpar. On the internet, human biases yield a strong tendency to feel that way about others, and we all need to be disciplined about counteracting it. If you can't or won't take up the task, you're not welcome to comment here.
That doesn't mean you have to abide by it perfectly. I can't, and doubt anyone can. It means that when we slip we need to recognize our error and correct it, not defensively dismiss the information.
It's not hard to see what kind of discourse we're going for here. What's hard is to stick to it when you're feeling that someone is subpar. On the internet, human biases yield a strong tendency to feel that way about others, and we all need to be disciplined about counteracting it. If you can't or won't take up the task, you're not welcome to comment here.
That doesn't mean you have to abide by it perfectly. I can't, and doubt anyone can. It means that when we slip we need to recognize our error and correct it, not defensively dismiss the information.
I really would not care if any of your sites had EV. And I don't care that HN does not have EV. But I may care whether the place I am going to spend money does have one.
You don't shop at Amazon.com? Because they don't believe in the EV scam either! More on the DV vs EV topic here: https://certsimple.com/blog/are-ev-ssl-certificates-worth-it
Oh, the commenter asked for the overly expensive EV type? Let's not be the devil's advocate. This is the wrong way to advertise. This is not the beginners corner. You advertise once, twice, three times, people remember, you can search HN - no need to annoy people till the end of the world. The company seems desperate for new business this way anyway.
You might want to fix your webdesign: http://i.imgur.com/zQbWnUI.png
And this is in Firefox, which renders fonts more bold than other browsers.
And this is in Firefox, which renders fonts more bold than other browsers.
Just removing the font-weight: 300 helps tremendously. Personally, I'm becoming less of a fan of external fonts. I've noticed lately that they're often the slowest thing to load on sites that use them (especially Google fonts).
The weight works great on a high DPI display, but on older displays, it just doesn't work. Open on a rMBP or iPad, and it's beautiful. I'm guessing the designers are working on a high DPI Mac.
Edit: should be sorted.
Original: working on a standard DPI Mac, but it still looks fine - see http://imgur.com/WRWYzBx. Trying to figure it out now...
Original: working on a standard DPI Mac, but it still looks fine - see http://imgur.com/WRWYzBx. Trying to figure it out now...
Do you mean "fine" as in "very fine lines", or "looks fine" as in "looks good"?
Cause that looks like a printer that ran out of ink.
Cause that looks like a printer that ran out of ink.
I'm guessing OS X's font smoothing is more aggressive and makes it look better than Windows'. It also depends on how the font was hinted for Windows, whereas on OS X, the system "knows best" and has its own font smoothing technique.
I am on a rMBP and I wouldn't call it beautiful.
It's painfully thin, and the eyestrain factor is pretty high.
It's painfully thin, and the eyestrain factor is pretty high.
I downloaded all of Google’s font library and installed it locally, means I can read the fonts without having to load them from Google. Still doesn’t help against fonts with 0.5px thin lines.
Back in the day, running a massive library of fonts slowed down many apps. Is this still the case? I'm running Mac OS X 10.10.
I’m on linux, and yes, it does. Opening the font selection menu can take for me, with 7000 installed fonts, about half an hour sometimes. I just don’t do that, instead select fonts by name (I know most of them now).
But you don’t notice it until you open a font selection menu.
But you don’t notice it until you open a font selection menu.
That's insane! Guessing you don't use Photoshop. At least, the last version I used (I think CS5), the font selection was weird and, no matter what, required that you open the drop down. Bleh. Haha
Photoshop on linux, that’s funny ;P
But seriously, I had to use Gtk3's font selection menu today, and it was impossible to work with it.
But seriously, I had to use Gtk3's font selection menu today, and it was impossible to work with it.
Also on Ubuntu. I (only) have 671 fonts, no delay at all for me.
Edit:
I've made some changes to Typekit to thicken things up. Is it better? If not, can you provide details of your OS?
Original:
I'll investigate and fix that now. What OS are you on so I can reproduce it?
It looks this this here in Firefox (http://imgur.com/WRWYzBx) and this in Chrome (http://imgur.com/6dFeQhG) on OS X, testing across multiple Macs here. I'd really like to fix it though! Thanks for the heads up!
We moved from Google Fonts to TypeKit recently, so I suspect it may have happened then.
I've made some changes to Typekit to thicken things up. Is it better? If not, can you provide details of your OS?
Original:
I'll investigate and fix that now. What OS are you on so I can reproduce it?
It looks this this here in Firefox (http://imgur.com/WRWYzBx) and this in Chrome (http://imgur.com/6dFeQhG) on OS X, testing across multiple Macs here. I'd really like to fix it though! Thanks for the heads up!
We moved from Google Fonts to TypeKit recently, so I suspect it may have happened then.
As I said above, the Firefox screenshot looks like a printer that ran out of ink, the Chrome version is slightly better, but look at the letter 'T', that's still wrong, a hairline that falls between pixels. That's only acceptable for text that is not actually intended to be read (thumbnails, mockups, zoomed out stuff, etc).
On the updated version, want to give some actionable feedback:
Not just the weight, the size combined with the weight: 12px in a thin font is too light for a screen, especially done in grey. Going to 16px could really make a difference.
Going with a bigger size gives the scope to use a different, contrasting (perhaps thicker, perhaps thicker and smaller for double-contrast?) font for the headings currently in green.
* Getting older happens to different people at different ages, one of the effects of this means eyes get more temperamental, and this doesn't happen 50+, it happens a lot earlier for a lot of people.
Not just the weight, the size combined with the weight: 12px in a thin font is too light for a screen, especially done in grey. Going to 16px could really make a difference.
Going with a bigger size gives the scope to use a different, contrasting (perhaps thicker, perhaps thicker and smaller for double-contrast?) font for the headings currently in green.
* Getting older happens to different people at different ages, one of the effects of this means eyes get more temperamental, and this doesn't happen 50+, it happens a lot earlier for a lot of people.
Thanks - I'm really grateful for the feedback - and would like it if you have any more.
I'll be changing the base font to 14px and darkening the grey to #222 quite soon.
I'll also look at 16px but this needs some additional design work.
I'll be changing the base font to 14px and darkening the grey to #222 quite soon.
I'll also look at 16px but this needs some additional design work.
In Chrome is better but still terrible :/
Yeah but still $234/yr for a certificate. While I appreciate what you're doing to make things more simple, that's pretty expensive.
I can't wait until letsencrypt is done.
I can't wait until letsencrypt is done.
They offer EV certs, so there's some cost involved in doing the identity verification. I don't think it's $234 dollars a year, forever, but it costs something. And that's actually a pretty competitive price for an EV certificate.
Is it possible to get a wildcard EV certificate?
Wildcards are prohibited on EV certificates per CA/B Forum requirements: https://cabforum.org/wp-content/uploads/EV-V1_5_61.pdf (Section 9.2.2)
No, which is why most of Google isn't running on EV certs..
Like the other comment says, the font is way too thin on your site and actually hurts to read on my monitor. Any interest I had in this service is effectively gone now.
Text needs to be legible, please try and stick to normal and bold weights.
Text needs to be legible, please try and stick to normal and bold weights.
I didn't know the site is unreadable until uMatrix was disabled.
SSLMate seems pretty easy as well: https://sslmate.com/
(No affiliation, I just saw their HN post some time before)
(No affiliation, I just saw their HN post some time before)
Looks awesome!
Does anyone know if there's an undo command for `$ letsencrypt run`?
I would love to try this, but too scared to do it and mess up with my nginx configs.
Does anyone know if there's an undo command for `$ letsencrypt run`?
I would love to try this, but too scared to do it and mess up with my nginx configs.
Perhaps $ git init your nginx configs?
I mean... back them up? :D
The client has a checkpointing mechanism that does back up old configuration versions and can revert them. (This client feature is called the "reverter", in case you care to look at some of the code or issues related to it on our GitHub page.)
I still haven't figured out how that interacts with the automated renewal features (probably not well right now!) but the ability to revert configurations exists.
Also, please don't try the client with a live site right now, because we don't have general public availability (nobody outside of Let's Encrypt can get a cert issued from the Let's Encrypt intermediate -- you'll get one from "happy hacker fake CA" instead), and we don't have the cross-signature. We're not even quite at the beta-test stage yet, let alone the "please use our certificates on your popular public services" stage. :-)
The main exception would be if you currently don't have HTTPS enabled at all and you're in the mood to experiment to learn more about Let's Encrypt.
I still haven't figured out how that interacts with the automated renewal features (probably not well right now!) but the ability to revert configurations exists.
Also, please don't try the client with a live site right now, because we don't have general public availability (nobody outside of Let's Encrypt can get a cert issued from the Let's Encrypt intermediate -- you'll get one from "happy hacker fake CA" instead), and we don't have the cross-signature. We're not even quite at the beta-test stage yet, let alone the "please use our certificates on your popular public services" stage. :-)
The main exception would be if you currently don't have HTTPS enabled at all and you're in the mood to experiment to learn more about Let's Encrypt.
For this specific reason I'm a lot more comfortable running the "nosudo"[0] variant, which tells you to install the keys yourself.
A recently released Ruby gem also looks promising, in that it's a much better codebase with a tonne of tests.[1].
[0] https://github.com/diafygi/letsencrypt-nosudo [1] https://github.com/unixcharles/acme-client
A recently released Ruby gem also looks promising, in that it's a much better codebase with a tonne of tests.[1].
[0] https://github.com/diafygi/letsencrypt-nosudo [1] https://github.com/unixcharles/acme-client
SSLmate (https://sslmate.com/) actually makes things similarly simple — I've been using them for a few months now.
I'm so excited for this to take off, and it's good to see they've taken the first steps, but can I at least download the CA Cert over HTTPS? Not sure how comfortable I am installing a CA cert I downloaded via HTTP, since that's kind of the whole point of this whole thing.
Fixed, thanks for pointing that out.
No problem :-) I actually noticed the link was HTTPS (presumably after you changed it) and thought I was taking crazy pills.
HTTP version really should redir to HTTPS.
I thought the same thing, so I wrote the comment below (I downloaded it using https and checked it against earlier posted copies of the cert):
https://news.ycombinator.com/item?id=10218774
https://news.ycombinator.com/item?id=10218774
Sorry for asking a potentially dumb question : but is it possible for me to set up a domain name thecitibank.com and ask letsencrypt to issue me a certificate ? I can then create a login page to steal IPINs. Isn't that why we have humans in the loop for issuing certificates ?
This comment is the exact perception about HTTPS that we need to change. It's not the job of HTTPS to say whether a website is safe or unsafe, good or bad. HTTPS should be the default communication protocol for every website, and lets encrypt move us a major step towards that by making SSL certificates free and trivial to set up.
"This comment is the exact perception about HTTPS that we need to change. It's not the job of HTTPS to say whether a website is safe or unsafe."
Too late. The web industry has spent about 20 years training regular people to look for that green lock sign in the address bar and feel all warm and fuzzy about how safe the site is. You can post on hacker news all you want about what perceptions need to be changed. It's not going to change the ground reality. SSL, as practiced in the industry today with all it's historical baggage is fundamentally broken. There's no fixing it.
Too late. The web industry has spent about 20 years training regular people to look for that green lock sign in the address bar and feel all warm and fuzzy about how safe the site is. You can post on hacker news all you want about what perceptions need to be changed. It's not going to change the ground reality. SSL, as practiced in the industry today with all it's historical baggage is fundamentally broken. There's no fixing it.
Actually what's really broken is the way we've approached implementations. Recently I was trying to get a self-signed certificate for myself trusted by Python urllib3...I still don't know how to do it. It uses a completely separate trust-store. As does half a dozen other things on my system.
Java is literally the worst as well. The Java truststore doesn't even have all the certs that every major browser supports. I'm looking at you StartSSL.
Green lock = EV cert. People are trained to look for the green, not for the lock - few people other than techies even look for a grey lock. EV certs generally have much more stringent requirements than "hey, give me a cert!".
I'm pretty sure "People are trained to look for the green, not for the lock" is newer and not nearly as widely known advice as "look for the lock". And it's pretty obvious just looking around non-tech-related sites that even the "look for the lock" advice isn't all that well received - so many sites use images of padlocks on the page to imply "banking grade security!!!", surely not _all_ of them are incompetent - I have a strong suspicion that at least some of those people are doing it as part of high statistical significance validated A?B tested funnel optimisations...
Chrome has a green lock and green 'https' for this site, which hasn't an EV cert.
That's correct - only Chrome shows green locks for domain validated certs.
Firefox uses a grey lock for domain validated certs.
Edge uses a hollowed-out grey lock for domain validated certs.
Firefox uses a grey lock for domain validated certs.
Edge uses a hollowed-out grey lock for domain validated certs.
A valid certificate only allows you to have a secure connection without errors and warnings popping up all over. It does nothing to guarantee that the domain is "legit". You can already set up thecitibank.com and get an SSL certificate for it without any problem. What you can't do is get the EV (green bar) certificate where indeed you need to go through a human. But I'm pretty sure Let's Encrypt won't be giving away EV certificates.
”without any problem”
Are you sure about that?
Are you sure about that?
Yeah - there's many ssl vendors who've automated everything - so long as you can read email sent to [email protected], they'll sign a csr for that domain's ssl cert.
Most certificate providers are already fully automated, the personal identity (not domain ownership) verification is the only human part.
Surely you would at least need access to a relevant email address on that domain? How would you bypass that?
He would need to be in control of that domain entirely. thecitibank.com is just an address that looks legitimate and is purchasable.
Ok, I understand.
On a slight side note he may not necessarily need to control the domain entirely, just have access to a privileged email address [1]
However, now it seems you won't even need access to an email address. What would stop someone creating a cert for the real citibank.com and using it for a MITM attack? How many people actually check the green bar?
[1] http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
On a slight side note he may not necessarily need to control the domain entirely, just have access to a privileged email address [1]
However, now it seems you won't even need access to an email address. What would stop someone creating a cert for the real citibank.com and using it for a MITM attack? How many people actually check the green bar?
[1] http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
In the live.fi example, it sounds like Microsoft may have failed to prevent a random user from registering [email protected] as a personal account. Citibank probably won't allow a customer to get that e-mail address!
Yes, you can.
You can also do the same at every existing CA that provides domain verified certificates. From personal experience neither StartSSL nor Comodo have a human in the look – until you want more than domain verification (e.g., "green bar" EV certificates).
You can also do the same at every existing CA that provides domain verified certificates. From personal experience neither StartSSL nor Comodo have a human in the look – until you want more than domain verification (e.g., "green bar" EV certificates).
StartSSL at least have a human in the loop for your initial identity validation. They got in touch with me because I'd put a work address in instead of my home address, and they worked it out and sent me a very human-like email asking me to correct it.
I got also an email from a guy because my domain name had been registered that same day, telling me to wait, sure you can automate the check, but at least the email didn't look automated.
We don't have humans in the loop for issuing certificate; this can and has been exploited for fun and profit, with fun attacks like getting a cert for "citibank.com\0.mydomain.com" which used to trick the C strcmp in most browser certificate checking routines. Moxie has an entertaining talk: https://www.youtube.com/watch?v=MFol6IMbZ7Y
Your problem would be getting people to "thecitibank.com." Chrome, Firefox, and GMail would all eventually figure out it was a phishing site and warn users about clicking through to it.
Your problem would be getting people to "thecitibank.com." Chrome, Firefox, and GMail would all eventually figure out it was a phishing site and warn users about clicking through to it.
As has been said, existing domain-validated (i.e. basic) certificates are automated anyway.
The type of certificate that banks etc use are EV - Extended Validation. This means the organisation details are verified as well, and as such the browser displays the verified organisation name in green in some cases, instead of any host/url at all).
The type of certificate that banks etc use are EV - Extended Validation. This means the organisation details are verified as well, and as such the browser displays the verified organisation name in green in some cases, instead of any host/url at all).
Actually it's automated in most places, simply requiring you to confirm a request via an e-mail address associated with the domain you're getting an SSL for (typically admin@ hostmaster@ webmaster@, though it varies between certificate providers).
Most of the reputable CAs have some practices in place to check for keywords related to big brands and auto-reject certificate requests. (So you can't get a certificate for "login-facebook.com" or whatnot, for instance.)
"(So you can't get a certificate for "login-facebook.com" or whatnot, for instance.)"
You mean not from one of those "reputable" CAs. But really, why would I go to a "reputable" CA for my deceptive certificate if my intent is not so reputable?
You mean not from one of those "reputable" CAs. But really, why would I go to a "reputable" CA for my deceptive certificate if my intent is not so reputable?
There's no requirement in the spec for using "reputable" CA's for certificates.
Could you provide a few examples of reputable and not so reputable CAs?
Just browse the truststore of your browser, you'd be surprised.
No, they don't. What would be the point, anyway?
Er, from personal experience I can say that at least some well-known CAs absolutely do review keywords appearing in SSL certificate requests. For a (really stupid and disappointing) example, see:
http://forums.comodo.com/ssl-certificate-b14.0/-t106480.0.ht...
http://forums.comodo.com/ssl-certificate-b14.0/-t106480.0.ht...
What's the target audience of the beta program? I'd love to play around with this on a personal domain but I doubt that there will be more than 2 or 3 unique visitors between now and general availability. Do they want signups for the beta program irrespective of the traffic volume of the site or would toy site signups just be more of a hassle for someone to approve?
The verbiage on that page isn't very clear on if there's some manual process for approving beta participants or if it's just grab 100 entries a week out of a Google Sheets page.
The verbiage on that page isn't very clear on if there's some manual process for approving beta participants or if it's just grab 100 entries a week out of a Google Sheets page.
Does anybody know if there is any protection built in against MITM or DNS poisoning attacks?
It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate.
For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which routes along a set path - say 2.3.4.5 and 3.4.5.6. To verify that I control amazon.com, letsencrypt is going to try and fetch http://1.2.3.4/something (through DNS resolving). If I can get MITM access on 2.3.4.5 and pass back /something to the request, letsencrypt is going to generate a certificate for me that I can use to say I am amazon.com for the entire world.
Is there any protection against this built into letsencrypt for this? Maybe checking if amazon.com already has https:// ? Although I'm not sure if there is any way to get around a DNS poisoning attack...
In essence, this seems to mean that you can take a single successful MITM and turn it into a globally authorized MITM. Right?
It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate.
For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which routes along a set path - say 2.3.4.5 and 3.4.5.6. To verify that I control amazon.com, letsencrypt is going to try and fetch http://1.2.3.4/something (through DNS resolving). If I can get MITM access on 2.3.4.5 and pass back /something to the request, letsencrypt is going to generate a certificate for me that I can use to say I am amazon.com for the entire world.
Is there any protection against this built into letsencrypt for this? Maybe checking if amazon.com already has https:// ? Although I'm not sure if there is any way to get around a DNS poisoning attack...
In essence, this seems to mean that you can take a single successful MITM and turn it into a globally authorized MITM. Right?
You can already do that today with most CAs.
They may do domain validation by looking up WHOIS and emailing the contact address there.
You could MITM the DNS MX lookup and respond with an IP address of an SMTP server you control, and grab the validation code in the verification email as it is dutifully delivered to you just as easily.
Edit: In fact, come to think of it... For DNS you might not even need to MITM, just be able to spoof the IP source in an UDP package and correctly guess the remote source port + possibly a query ID, and race the real DNS server? I wonder how feasible that would be at for example 1 Gbps?
They may do domain validation by looking up WHOIS and emailing the contact address there.
You could MITM the DNS MX lookup and respond with an IP address of an SMTP server you control, and grab the validation code in the verification email as it is dutifully delivered to you just as easily.
Edit: In fact, come to think of it... For DNS you might not even need to MITM, just be able to spoof the IP source in an UDP package and correctly guess the remote source port + possibly a query ID, and race the real DNS server? I wonder how feasible that would be at for example 1 Gbps?
Boulder (the CA backend) has two solutions to this problem
a. if we know of an already existing certificate for the domain that is being authorized you must prove control over both the server and the key used in the existing certificate
b. validation is done over multiple paths to confirm results, an attacker would need to be able to hijack connections from all of our validation servers in order to cause miss-issuance (servers which would move over time)
Currently (a) is mostly implemented but (b) needs quite a bit more work before it can go live.
a. if we know of an already existing certificate for the domain that is being authorized you must prove control over both the server and the key used in the existing certificate
b. validation is done over multiple paths to confirm results, an attacker would need to be able to hijack connections from all of our validation servers in order to cause miss-issuance (servers which would move over time)
Currently (a) is mostly implemented but (b) needs quite a bit more work before it can go live.
What happens if the user loses the key?
What happens if a certificate is requested, the domain is sold to a new owner and the new owner tries to request a certificate, but doesn't have access to the keys for the old one?
Also, how can the new owner revoke all certificates delivered to previous owners?
What happens if a certificate is requested, the domain is sold to a new owner and the new owner tries to request a certificate, but doesn't have access to the keys for the old one?
Also, how can the new owner revoke all certificates delivered to previous owners?
Certificates expire. Presumably the answer to all of your questions would then be to wait for the old certificate to expire.
So if you want to mitigate the consequences at the outset, use certificates that expire quickly. Which should be easy when renewing a certificate is free and automatic.
So if you want to mitigate the consequences at the outset, use certificates that expire quickly. Which should be easy when renewing a certificate is free and automatic.
Either wait for the certificate to expire, register a new certificate for the domain with another CA which LE will see and can then be used to prove ownership, or ask the originally issuing CA to revoke the certificate which will remove the need for the challenge completely.
I interpreted "you must prove control over both the server and the key used in the existing certificate" as meaning that if a Let's Encrypt certificate for the domain has been created in the past, you need to own its key (presumably proved by signing something with it) to get another one.
Is that wrong?
Waiting for certificates to expire could mean waiting for years, unless they have auto-renewing very short-lived certificates (but then you have the same problem for the authentication used to automatically get those certificates).
Is that wrong?
Waiting for certificates to expire could mean waiting for years, unless they have auto-renewing very short-lived certificates (but then you have the same problem for the authentication used to automatically get those certificates).
LetsEncrypt does use very short-lived certificates (90 days) for this reason. However, you have to remember than when you buy a domain you already have no idea if any CA has issued valid certificates for it.
According to their 31C3 talk, they will use multiple connections from multiple locations (possibly including Tor?) to mitigate against these attacks.
Thanks, this is the real answer I was looking for and not the hand waving about trusting everyone up above. That sounds like a good solution to me.
Any CA performing domain ownership validation would be vulnerable to the same thing. If you can fake its WHOIS requests or make it appear as if the domain making the request does in fact have the "canary" file they told you to host to prove ownership, then you can get any CA to give you a cert for any site.
You have to trust something.
You have to trust something.
Agreed - but by making this a fully automated system you open up an easily testable and repeatable source of attack.
I don't think "You have to trust something" is really right in this case, as you're basically saying "You have to trust every single router between letsencrypt and every server on the internet".
I guess it's correct that with most current CAs now automating a lot of this with minimal manual checks, this is probably happening already? I wonder how many amazon.com valid certs are floating around the place? (Or more likely, smaller sites where people wouldn't be checking if the cert is really valid). The original point behind the costs charged by Thawte et al was that they would actually validate that you're who you say you are. I guess that ship has sailed though.
I don't think "You have to trust something" is really right in this case, as you're basically saying "You have to trust every single router between letsencrypt and every server on the internet".
I guess it's correct that with most current CAs now automating a lot of this with minimal manual checks, this is probably happening already? I wonder how many amazon.com valid certs are floating around the place? (Or more likely, smaller sites where people wouldn't be checking if the cert is really valid). The original point behind the costs charged by Thawte et al was that they would actually validate that you're who you say you are. I guess that ship has sailed though.
All mainstream CAs issue certs through a fully automated process, and have for at least a decade. Generally you are required to receive emails sent to the administrative contact in WHOIS, put something in a DNS TXT record, place or file they give you at a URL they give you, or some combination of the above.
There are Extended Validation (EV) certs where a human verifies your ownership of a legal entity. Chrome presents these as a big green bar with the name of the corporation in the URL bar. Most certs (including Amazon's) are not EV certs.
There are Extended Validation (EV) certs where a human verifies your ownership of a legal entity. Chrome presents these as a big green bar with the name of the corporation in the URL bar. Most certs (including Amazon's) are not EV certs.
If the registrar held the job of being a CA, then at least there wouldn't be a spoofable link between the CA and the domain owner - the registrar already has your account information and proof of ownership, 100% verified, when your domain is held with them...
Sure, but registrars would need to start doing a lot better job of checking the identity of people applying for domains, otherwise we'd just end up with domain validated certificates all over again.
As the grandparent post notes, all CAs completely automate domian validation at present.
As the grandparent post notes, all CAs completely automate domian validation at present.
My point is that regular domain validated CA should be the sole job of registrars. It would even prevent parallel certs being fraudulently issued - a domain can only be registered at one registrar at one time.
Sure, you could have the other CAs still offer EV (real-world identity) validation as a value-add.
But it's pretty silly that, currently, you have to pay a third party (today's CAs) to validate something that the registrar already knows for sure.
Sure, you could have the other CAs still offer EV (real-world identity) validation as a value-add.
But it's pretty silly that, currently, you have to pay a third party (today's CAs) to validate something that the registrar already knows for sure.
The other side of that argument is that if your registrar is also your CA, they have the ability to give bogus SSL certs to an evil server and the ability to direct your domain to that evil server.
They can already do that, as they could temporarily hijack your NS records and buy a cert somewhere else. If you can't trust your registrar, you have bigger problems (I'd say "all is lost")
On the flipside, having a registar act as the only valid CA would mean that choosing a trustworthy registrar suddenly has real value. Power users could make an educated opinion on the trustworthyness of a given domain validated CA. Domain owners could be sure they're not at risk for how in the current system, an adversarity could get a valid parallel SSL certificate from a sloppy bargain-bin CA, even if the domain owner picked the most expensive and diligent CA and registrar for themselves.
On the flipside, having a registar act as the only valid CA would mean that choosing a trustworthy registrar suddenly has real value. Power users could make an educated opinion on the trustworthyness of a given domain validated CA. Domain owners could be sure they're not at risk for how in the current system, an adversarity could get a valid parallel SSL certificate from a sloppy bargain-bin CA, even if the domain owner picked the most expensive and diligent CA and registrar for themselves.
A lot of folks might not have thought through the weakest-link aspect of the current system: they feel like they're safer because they chose to use a reputable or trustworthy CA. But misissuance events that I've heard of have never involved CAs that the victims had any business relationship with at all.
Everyone repeat after me, wildcards, wildcards, wildcards.
(just hoping they will appear next year)
One more nail in the coffin of the ssl cert mafia.
(just hoping they will appear next year)
One more nail in the coffin of the ssl cert mafia.
While I too would like to see wildcards, doesn't the fact that you can programmatically obtain a cert for a subdomain obviate most of the wildcard needs? Sure it's a bit more difficult but if your service has some form of sorts to make a subdomain work for a specific word, surely it can request the cert at that time. Having said that, obviously keeping track of only one cert and not having to build this into your apps is much more preferred.
This comes up when you are running a multi-tenant app with many tenants; github.com is a good example. You can sign up as "dude.github.com" or "me234.github.com" and so on. So, Github can either a) obtain wildcard SSL cert for "*.github.com" once, and then present it to tenants, and control access with the "domain" property of the cookie, and don't worry about SSL cert until next year's renewal time, or 2) apply to some authority for XXX.github.com every time the new tenant signs up. Well, 2) makes you reliant on "some authority" every time new customer signs up, (hopefully many times a day!) which is not so very good IMHO. Just my 5c.
Not all subdomains are known in advance - DNS has wildcards too.
Without wildcards you can't use the automated tool to pre-provision new servers, for example.
Say 1.example.com is in production and is to be swapped for new1.example.com which is in staging.
new1 can't obtain a useful cert from Let's Encrypt until it becomes 1 in Internet-facing DNS. So you have a service discontinuity whilst moving 1 -> old1 and new1 -> 1 and then applying for the cert.
I appreciate that the set of people managing such issues probably aren't the target market ( they also won't be running an as-root tool to make automated changes on their edge servers... ) but it's an example of why wildcards are so useful.
Say 1.example.com is in production and is to be swapped for new1.example.com which is in staging.
new1 can't obtain a useful cert from Let's Encrypt until it becomes 1 in Internet-facing DNS. So you have a service discontinuity whilst moving 1 -> old1 and new1 -> 1 and then applying for the cert.
I appreciate that the set of people managing such issues probably aren't the target market ( they also won't be running an as-root tool to make automated changes on their edge servers... ) but it's an example of why wildcards are so useful.
I can absolutely understand the need for this, but until then with a bit of code and the automated workflow you could make requests for new subdomains on-the-fly.
They won't support those on launch?
Altough because of SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) the need for wildcard certificates has greatly diminished.
Altough because of SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) the need for wildcard certificates has greatly diminished.
Agreed.
SNI and SubjectAltName [https://en.wikipedia.org/wiki/SubjectAltName] mixed with the simplicity of issuing a new certificate using LetsEncrypt [https://letsencrypt.org/howitworks/] all but eliminate the need for wildcards.
SNI and SubjectAltName [https://en.wikipedia.org/wiki/SubjectAltName] mixed with the simplicity of issuing a new certificate using LetsEncrypt [https://letsencrypt.org/howitworks/] all but eliminate the need for wildcards.
Not sure if they'll amend their certificate policy or not. My guess is because their process is automated, they want to confine their certificate issuance to specific domains/sub-domains and not wildcards. It mitigates some repercussions in the event of a compromised cert.
Pg. 24 of the Certificate Policy:
For DV-SSL The Issuer DN of a DV-SSL Certificate shall be its Issuer’s subject DN. CAs shall include FQDNs or IP Addresses of the Device in the subject Alternative Name extension. The Subject Alternative Name extension may contain more than one instance of the name form. CAs may include a FQDN or IP Address in the subject DN for backwards compatibility, but this name shall be also included in the Subject Alternative Name extension. Wildcard names are not permitted
https://letsencrypt.org/documents/ISRG-CP-May-5-2015.pdf
Pg. 24 of the Certificate Policy:
For DV-SSL The Issuer DN of a DV-SSL Certificate shall be its Issuer’s subject DN. CAs shall include FQDNs or IP Addresses of the Device in the subject Alternative Name extension. The Subject Alternative Name extension may contain more than one instance of the name form. CAs may include a FQDN or IP Address in the subject DN for backwards compatibility, but this name shall be also included in the Subject Alternative Name extension. Wildcard names are not permitted
https://letsencrypt.org/documents/ISRG-CP-May-5-2015.pdf
The major problem with this is that the IETF validation working group hasn't come up with a definite procedure for deciding what the apex of a domain is, and how to validate control over all subdomains above it yet.
Doesn't ownership of domain.tld also imply ownership of *.domain.tld?
I don't think the owner of "co.uk" should have the power to issue certificates for everything below it.
To make the original comment more precise, should not proving ownership of:
Really, why can't I be a mini-CA for my own domain, with only the power to issue certs for the set of domains I actually have control over? (essentially, why can't I get a nameConstraint CA cert?)
[1]: The Public Suffix list is a list of what a human might call a "tld, essentially"; "com" is a public suffix, but so is "co.uk": https://publicsuffix.org
<some domain>
<some domain>.<some public suffix>
Really, why can't I be a mini-CA for my own domain, with only the power to issue certs for the set of domains I actually have control over? (essentially, why can't I get a nameConstraint CA cert?)
[1]: The Public Suffix list is a list of what a human might call a "tld, essentially"; "com" is a public suffix, but so is "co.uk": https://publicsuffix.org
Because client support isn't there for nameConstraints. I really wish it was though.
That's the relatively simple case, but there are a number of corner cases that make the process much more complicated.
See https://github.com/letsencrypt/acme-spec/pull/97 for a discussion of why this was scraped from the ACME specification proposal.
See https://github.com/letsencrypt/acme-spec/pull/97 for a discussion of why this was scraped from the ACME specification proposal.
I don't get it. Whoever controls the base domain could always just replace the NS records and point any subdomain wherever.
That's what Domain Validation (DV) is for and what most less-expensive wildcards use.
No? I thought I'd seen a list of them somewhere authoritative. Anyone know what I'm talking about?
Yes, the Public Suffix List: https://publicsuffix.org/
That's definitely what I was thinking of, but it's not entirely suitable as a list of domains not to issue certificates for, unless you're happy to accept you won't be issuing certificates for domains like blogspot.com or flynn.io.
Absolutely. I badly need a wildcard cert to do any of the SSL-ing I'd like to do.
Quick question, apart from having a prettier website, what's the differentiator with StartSSL which is also free, automated, and open?
Certificate revocation for free (which is a big deal!), commercial use for free, multiple hosts for free…
StartSSL might also refuse you if you try to request a certificate on behalf of a friend or a client, as they sometimes checks if WHOIS lines up with your identity validation. Quite the hassle for domain-validated certs :-/
Unless things have changed drastically recently (it's been a little while since I've used them), StartSSL is not "open" for any meaningful definition of the word.
I've used StartSSL for my last three customer projects, only because they offer cheap wildcard certs. I for one cannot wait to never have to use them again:
* validation taking up to six weeks, with recurring ridiculous demands for documentation, such as energy provider bills etc
* very unpleasant interface
* nightmarish authentication scheme with client-side certs. Try signing on with Chrome on one box, then exporting the cert to Firefox on another for example
* the client-side cert expires. When it does, there is no way to get back into your account. Support says 'just make a new one'
* there doesn't seem to be a mechanism for designating a technical contact, and I've been admonished by them several times for having the gall of taking over the process for my customers
* validation taking up to six weeks, with recurring ridiculous demands for documentation, such as energy provider bills etc
* very unpleasant interface
* nightmarish authentication scheme with client-side certs. Try signing on with Chrome on one box, then exporting the cert to Firefox on another for example
* the client-side cert expires. When it does, there is no way to get back into your account. Support says 'just make a new one'
* there doesn't seem to be a mechanism for designating a technical contact, and I've been admonished by them several times for having the gall of taking over the process for my customers
StartSSL is not free for any commercial sites, even tiny businesses or personal sites advertising freelance services.
We used StartSSL for free when we started LogNormal. We were definitely commercial.
It might not always be enforced in practice, but StartCom's policy doesn't allow use of the free certs for a commercial purpose:
> Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in obtaining or relaying sensitive information such as health records, financial details, personal information etc.
https://www.startssl.com/policy.pdf
> Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in obtaining or relaying sensitive information such as health records, financial details, personal information etc.
https://www.startssl.com/policy.pdf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
For the record, the cert I've downloaded (using SSL over the Let's Encrypt site) from the Let's Encrypt site has the following SHA256 fingerprint:
SHA256 Fingerprint=96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
Works great. To install on Firefox, just click on the first certificate listed here, in der format (just be sure to 'view certificate' and compare with the SHA256 hash I list above): https://letsencrypt.org/certificates/
For Chrome users, you have to download the cert, then go under "Manage Certificates" in "Advanced Settings". Then click the "Authorities" tab and import button. To check the cert hash, you'll have to run the following on OpenSSL: You can check your own fingerprint using: openssl x509 -fingerprint -sha256 -in isrgrootx1.pem
Command line users on Ubuntu and (I think) Debian can install it to all browsers at once using: chmod 644 isgrootx1.pem sudo mkdir /usr/share/ca-certificates/letsencrypt.org sudo cp isrgrootx1.pem /usr/share/ca-certificates/letsencrypt.org/isrgrootx1.crt sudo dpkg-reconfigure ca-certificates
For the extra paranoid, this is the same cert that another user posted to a Github gist earlier this summer: https://gist.github.com/rmoriz/1211745a21bc6114e770
And you can verify my GPG signature by fetching my PGP key here (note that the keybase profile is linked to this HN username): https://keybase.io/esbullington
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIcBAEBCgAGBQJV95CmAAoJELGyxBAnWFiCpF4P/0sxqdrobdKm02V2cadHWQX3 AqXEENlPoReoVazf6Xhr3xfcyLw7g798q7YG4Bd0XtZLwofTr8Hq2On4q9w6dufu 6yGv+PyBTqL2EiSvuyY1p29ieYJV3tqOLUTaYjlvf7YGS90wLphRsEF1RVOaKfLK J1HSfx5Gctl1IRqa3Lt4zK6pot8xOzvV2d6V+fW1V/Svx5ZrfEUgJ7hgcyrgCSzB wqKJNhpoZCK50iqzrBlwjByRA+yi4LJckzSZ97l2p86QfvSg8xeVuMWVT+Qw6Pll Lw+rlrh4sLtcVGTcc6qUfBa5FXfoNOfT0vL009uBz5UkCs0vTjmbOwfZTGAMxKgC fD9dfOY3f9lA87nxTCP7nKR/USbDJANztNdQ/14qJwKFVmdusAjvf8LR8MzaIi5Q aBiC6otSuAMDGOTPXJ3aex/v+pt1412K5CgLEq83zeTGK04OoEWV/MMzggT+UxH6 eUpChtwKtFQIjqagzhkWWgc6ti2Qy0PnvZZa36PfFa01iK4jOhRPH9aCkg5UQtbl MjMPF2gAbHwTGP8cSs+PIrFUYyEK8FgWW4HhXBVCbNgedIEjRJwuorr/Ug8D7mJk kx+nFENVIsjEHUa5k64fYYc4eRX244jKORvYxH/iwCvvpCaineBkVmXPIFGIBXqp EYdDJBWF/PWfMvjFYHL3 =es48 -----END PGP SIGNATURE-----
For the record, the cert I've downloaded (using SSL over the Let's Encrypt site) from the Let's Encrypt site has the following SHA256 fingerprint:
SHA256 Fingerprint=96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
Works great. To install on Firefox, just click on the first certificate listed here, in der format (just be sure to 'view certificate' and compare with the SHA256 hash I list above): https://letsencrypt.org/certificates/
For Chrome users, you have to download the cert, then go under "Manage Certificates" in "Advanced Settings". Then click the "Authorities" tab and import button. To check the cert hash, you'll have to run the following on OpenSSL: You can check your own fingerprint using: openssl x509 -fingerprint -sha256 -in isrgrootx1.pem
Command line users on Ubuntu and (I think) Debian can install it to all browsers at once using: chmod 644 isgrootx1.pem sudo mkdir /usr/share/ca-certificates/letsencrypt.org sudo cp isrgrootx1.pem /usr/share/ca-certificates/letsencrypt.org/isrgrootx1.crt sudo dpkg-reconfigure ca-certificates
For the extra paranoid, this is the same cert that another user posted to a Github gist earlier this summer: https://gist.github.com/rmoriz/1211745a21bc6114e770
And you can verify my GPG signature by fetching my PGP key here (note that the keybase profile is linked to this HN username): https://keybase.io/esbullington
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIcBAEBCgAGBQJV95CmAAoJELGyxBAnWFiCpF4P/0sxqdrobdKm02V2cadHWQX3 AqXEENlPoReoVazf6Xhr3xfcyLw7g798q7YG4Bd0XtZLwofTr8Hq2On4q9w6dufu 6yGv+PyBTqL2EiSvuyY1p29ieYJV3tqOLUTaYjlvf7YGS90wLphRsEF1RVOaKfLK J1HSfx5Gctl1IRqa3Lt4zK6pot8xOzvV2d6V+fW1V/Svx5ZrfEUgJ7hgcyrgCSzB wqKJNhpoZCK50iqzrBlwjByRA+yi4LJckzSZ97l2p86QfvSg8xeVuMWVT+Qw6Pll Lw+rlrh4sLtcVGTcc6qUfBa5FXfoNOfT0vL009uBz5UkCs0vTjmbOwfZTGAMxKgC fD9dfOY3f9lA87nxTCP7nKR/USbDJANztNdQ/14qJwKFVmdusAjvf8LR8MzaIi5Q aBiC6otSuAMDGOTPXJ3aex/v+pt1412K5CgLEq83zeTGK04OoEWV/MMzggT+UxH6 eUpChtwKtFQIjqagzhkWWgc6ti2Qy0PnvZZa36PfFa01iK4jOhRPH9aCkg5UQtbl MjMPF2gAbHwTGP8cSs+PIrFUYyEK8FgWW4HhXBVCbNgedIEjRJwuorr/Ug8D7mJk kx+nFENVIsjEHUa5k64fYYc4eRX244jKORvYxH/iwCvvpCaineBkVmXPIFGIBXqp EYdDJBWF/PWfMvjFYHL3 =es48 -----END PGP SIGNATURE-----
Thank you for posting the fingerprint, Eric.
Last year they did a talk at CCC. Well worth a watch.
https://www.youtube.com/watch?v=OZyXx8Ie4pA
https://www.youtube.com/watch?v=OZyXx8Ie4pA
This whole effort is making me a little bit giddy! Viva la admin-friendly security!
Getting NET::ERR_CERT_AUTHORITY_INVALID on https://helloworld.letsencrypt.org/
>Our cross signature is not yet in place, however this certificate is fully functional for clients with the ISRG root in their trust store. When we are cross signed, approximately a month from now, our certificates will work just about anywhere while our root propagates.
Visit it on http and it explains why.
>Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself.
>Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself.
Any one else getting a 'Secure Connection Failed' error at https://helloworld.letsencrypt.org/ in FF after adding the root certificate?
I checked the https demo using libcurl, and it failed unexpectedly with error code 35 (Unknown SSL connect error). I was expecting curl error 60 (untrusted certificate).
The test site requires SNI and only accepts TLS 1.1 and 1.2 with ECDHE/DHE+AES-GCM/AES-CBC ciphers[0]. I'm guessing whatever SSL library your libcurl is linked against only supports TLS 1.0, doesn't support SNI, or doesn't support any of those cipher suites (OpenSSL 0.9.x won't work with this site, for example).
[0]: https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le...
[0]: https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le...
I still don't get why Mozilla and Google don't accept CACerts. Couldn't a lot of this be solved by just removing the warnings?
They'll need to pass a webtrust audit, which covers how they handle their key material amongst others. Additionally the Microsoft, Apple and Android roots have their own extra requirements added.
It always seemed odd to me how strictly CACert is treated given that TrustWave got a pass when they deliberately sold a root CA certificate for man-in-the-middle purposes.
It's almost as if money is more important than key management practices.
It's almost as if money is more important than key management practices.
Thanks for all the informed info.
I was just always weirded out when my browsers forced me to perform 2-4 clicks because of untrusted connections when visiting websites of say the CCC (who just switched to StartSSL apparently).
Or the CACert website itself.
Always seemed to me like some kind of joke.
Or the CACert website itself.
Always seemed to me like some kind of joke.
Congrats Josh and team!!!!
How a root CA goes into the trust store? I know Firefox embed them, so older versions of it will not include it. OS minor updates (Windows, OS X, ...) ever updates the trust store?
How much time actually takes it before I can safely use it and be sure that the majority of browsers accept it?
How much time actually takes it before I can safely use it and be sure that the majority of browsers accept it?
In the short term, Let's Encrypt will be primarily trusted through an IdenTrust cross-signature, which should be created in the near future (and before Let's Encrypt certs are available to the general public).
The cross-signature is a delegation of authority from an existing root CA to Let's Encrypt's intermediate CA, saying that Let's Encrypt should also be trusted to issue certificates. Browsers that accept IdenTrust's root, which is widely accepted today, will then also accept the Let's Encrypt certificates as long as the services that present them also present the certificate chain (which includes the cross-signature certificate).
This will happen in parallel to Let's Encrypt's efforts to be accepted as a root CA, and is not dependent on it. For example, if Mozilla decided not to allow Let's Encrypt to be trusted as a root yet, past, current, and future Mozilla browsers would still accept Let's Encrypt end-entity certificates (with the proper chain) because of the cross-signature.
This is discussed in
https://community.letsencrypt.org/t/frequently-asked-questio...
and is also described in more detail at
https://letsencrypt.org/2015/06/04/isrg-ca-certs.html
The cross-signature is a delegation of authority from an existing root CA to Let's Encrypt's intermediate CA, saying that Let's Encrypt should also be trusted to issue certificates. Browsers that accept IdenTrust's root, which is widely accepted today, will then also accept the Let's Encrypt certificates as long as the services that present them also present the certificate chain (which includes the cross-signature certificate).
This will happen in parallel to Let's Encrypt's efforts to be accepted as a root CA, and is not dependent on it. For example, if Mozilla decided not to allow Let's Encrypt to be trusted as a root yet, past, current, and future Mozilla browsers would still accept Let's Encrypt end-entity certificates (with the proper chain) because of the cross-signature.
This is discussed in
https://community.letsencrypt.org/t/frequently-asked-questio...
and is also described in more detail at
https://letsencrypt.org/2015/06/04/isrg-ca-certs.html
I feel like these initiatives to make SSL available for everybody just lead to the same conclusion: EV will be the only viable alternative to show real trust, and EV is much, much more expensive than regular SSL ever was.
As far as I can tell EV certificates are completely worthless.
You know the TLS certificate you got from bankofamerica.com is legitimately from bankofamerica.com because of domain validation. What EV tells you on top of that is only that bankofamerica.com belongs to Bank of America Corporation. But you already have that information. Their website is written on the walls of all their bank branches and all the documents they've ever given you. You don't need a CA to verify that because you can trivially do it your own self. And the same is true for any person you actually know. You know their domain belongs to them because it's the domain they personally told you belongs to them.
So that leaves domains belonging to entities you've never otherwise encountered outside of their internet site. You may have never been to a Google office before. But if you've never encountered the entity outside of its internet site then the association is meaningless. What am I supposed to know of Google other than google.com?
You know the TLS certificate you got from bankofamerica.com is legitimately from bankofamerica.com because of domain validation. What EV tells you on top of that is only that bankofamerica.com belongs to Bank of America Corporation. But you already have that information. Their website is written on the walls of all their bank branches and all the documents they've ever given you. You don't need a CA to verify that because you can trivially do it your own self. And the same is true for any person you actually know. You know their domain belongs to them because it's the domain they personally told you belongs to them.
So that leaves domains belonging to entities you've never otherwise encountered outside of their internet site. You may have never been to a Google office before. But if you've never encountered the entity outside of its internet site then the association is meaningless. What am I supposed to know of Google other than google.com?
There's one difference (I don't think it really matters though) - if you go to bankofarnerica.com and get a valid certificate for bankofarnerica.com, if would not be owned by "Bank of America Corporation". But I agree it's worthless because it relies on you remembering that bankofamerica.com has an EV cert normally. And people are terrible at noticing what's missing.
The benefit is that if I get BankOfAmericaa.com and try to get an EV cert, the CA is going to verify my actual company name, which will unlikely be Bank of America or anything similar. So now when I trick someone into visiting my site, if the EV area doesn't tell them "Bank of America [US]" then they should double check. Or flip it around - if a user is unsure they can go off the EV info instead of the domain name.
In practise, since EV certs aren't used all over (say, WellsFargo doesn't use them), then the value is fairly diminished since lack of EV doesn't mean much.
In practise, since EV certs aren't used all over (say, WellsFargo doesn't use them), then the value is fairly diminished since lack of EV doesn't mean much.
> The benefit is that if I get BankOfAmericaa.com and try to get an EV cert, the CA is going to verify my actual company name, which will unlikely be Bank of America or anything similar.
So the first question is, why not? Can't someone file papers for a shell corporation with whatever name they like? Of course "Bank of Americaa Corp" is likely to raise questions, but is it not possible to BS your way through an EV cert claiming to be "Bunk of America Corp", retailer of bunk beds, or "Bank on America Corp", domestic lobby group?
Going through the process is obviously a huge pain for the attacker, but it's a huge pain for a legitimate business too. If the purpose is to make the process expensive then you might as well dispense with the charade and just say "pay us $20,000 and we'll give you a shiny green bar".
And the attacker still has a problem. Everything you know about Bank of America says their website is bankofamerica.com, not bankofamericaa.com. The difference is right there on the user's screen if they're looking for it. And if they're not looking for it then what difference is a green bar? Especially if all we tell them is "make sure it's green" and not "make sure it doesn't say Back of America Corp".
So the first question is, why not? Can't someone file papers for a shell corporation with whatever name they like? Of course "Bank of Americaa Corp" is likely to raise questions, but is it not possible to BS your way through an EV cert claiming to be "Bunk of America Corp", retailer of bunk beds, or "Bank on America Corp", domestic lobby group?
Going through the process is obviously a huge pain for the attacker, but it's a huge pain for a legitimate business too. If the purpose is to make the process expensive then you might as well dispense with the charade and just say "pay us $20,000 and we'll give you a shiny green bar".
And the attacker still has a problem. Everything you know about Bank of America says their website is bankofamerica.com, not bankofamericaa.com. The difference is right there on the user's screen if they're looking for it. And if they're not looking for it then what difference is a green bar? Especially if all we tell them is "make sure it's green" and not "make sure it doesn't say Back of America Corp".
Part of the label is also the country, if it says "Bank of America [AZ]" your alarms bells should start ringing.
If it says "bankofamericaa.com" your alarm bells should start ringing. Even assuming the attacker can't get a certificate for the right country, how is the user expected to notice (and understand) the wrong country code if they can't notice the wrong domain name?
I'd argue it's at least simpler to notice since it's more readable - it has spaces between words.
Notice that by this point the claimed benefit of the EV cert has lost all connection to the validation process and is now solely an artifact of the impermissibility of spaces in host names.
There's also the fact that obtaining an EV certificate is so unbelievably painful. I swear it gets more difficult every year.
Last time I bought an EV cert, Comodo wanted a certification from a Chartered Accountant. Aside from the confusion associated with Comodo wanting a letter "your CA", we then had them Google for "accountants in Sydney" and complain they weren't listed on the front page.
"Kindly address the search page to show them on the page in order for us to process the order".
It took hours of complaints and escalations before they agreed to proceed, at which point they wanted to call the company's "public" phone number. Now they could have gone to the company's website, or the White Pages, but no, they found some .ru website with an "accountant review" and called the number listed there. Instead of asking what official phone listings Australians use, the only thing they would accept is "kindly update the website".
Yes, this is probably one of the more incredible examples, but the point is, who wants to risk even possibly dealing with this, when you can have a DV certificate in two minutes and it "just works"?
Last time I bought an EV cert, Comodo wanted a certification from a Chartered Accountant. Aside from the confusion associated with Comodo wanting a letter "your CA", we then had them Google for "accountants in Sydney" and complain they weren't listed on the front page.
"Kindly address the search page to show them on the page in order for us to process the order".
It took hours of complaints and escalations before they agreed to proceed, at which point they wanted to call the company's "public" phone number. Now they could have gone to the company's website, or the White Pages, but no, they found some .ru website with an "accountant review" and called the number listed there. Instead of asking what official phone listings Australians use, the only thing they would accept is "kindly update the website".
Yes, this is probably one of the more incredible examples, but the point is, who wants to risk even possibly dealing with this, when you can have a DV certificate in two minutes and it "just works"?
Wow, that's just absurd.
But that's nothing new. If you need real trust, you need EV. The win from LetsEncrypt and any other attempt to make SSL more mainstream is the encryption, not the trust. If you're using SSL you're protected from some government and ISP snooping, and from having the contents of your message or webpage altered in mid-stream by a nefarious third party like AT&T.
I think people are making too big of a deal of SSL. So what if my browser connection to Target or Home Depot is encrypted?
Well it's possible and reasonable that you don't want to have what products your browsing to be snooped on by some sort of MITM attack. While probably not from MITM snooping, Target found out a teenage girl was pregnant before her own parents, and sent her parent's address Diaper and Baby advertisements: http://www.forbes.com/sites/kashmirhill/2012/02/16/how-targe...
My point is all this work and it's only a small part of the equation.
Would you really want you credit card details to be sent in plaintext?
Of course it's new. It's new since there are free certificates. Before, you had to pay, always. The amount was irrelevant, but you had to show your credit card. You had to prove your identity. That's a whole new felony there: stolen ID, carding, etc.
You had to have a credit card, but there was never any matching of the credit card name to the cert. Nobody is going to stop you from buying a cert for my domain with a prepaid credit card.
I don't see how it's a whole new felony. You could use your own credit card, and still convince the CA you own a domain that you don't.
Protected from criminals or from the ISP snooping, yes (with a certain confidence), protected from the government (any government really) snooping most likely no. If not through their own ca (just find the one controlled by your local government. High chances there is at least one in default ca stores) than always by obtaining a warrant and requiring the website in question to share information.
Who do you expect to care whether the certificate is EV or not? (serious question) Google is not EV, facebook isn't either, banks are 50/50, almost none of the big online shops are EV (amazon included). I've never heard anyone raise this as an issue - technical or not.
Does anyone familiar with the "paid-for certificate industry" know if anything major is going to happen? I'd guess they're going to be inundated with lawsuits or something.
Great work, by the way.
Great work, by the way.
Can anyone explain to me what the difficulties of producing secure certs are? What steps do you need to go through to get root CA approval?
Root CA status is conferred by the individual user-agent developers (for example, Mozilla, Microsoft, Google, Apple, among others). Some browser or OS developers may try to follow others' lead to avoid duplicating effort or creating big divergences in trusted status of a given cert.
Each entity that maintains its own root CA list has its own policy and process that people can apply through in order to propose to become a root CA. For example:
https://technet.microsoft.com/en-us/library/cc751157.aspx
https://wiki.mozilla.org/CA
These programs have certain criteria, which became more formal and rigorous over time (it used to be quite informal when the CA system was first set up). One commonality is generally to get a WebTrust CA audit, and there are also rules and meta-rules for CAs from the CA/Browser Forum.
https://cabforum.org/
This will require creating and publishing a certification policy and certification practice statement that have certain elements, and the auditors will look at those.
There are also physical security issues. For example, CAs use hardware security modules (HSMs) to perform their signing.
https://en.wikipedia.org/wiki/Hardware_security_module
The HSM will sign requested data, but won't export its private keys into a less-controlled environment like the CA's web server. It's akin to storing your crypto keys on a smartcard, only more expensive. :-)
Each entity that maintains its own root CA list has its own policy and process that people can apply through in order to propose to become a root CA. For example:
https://technet.microsoft.com/en-us/library/cc751157.aspx
https://wiki.mozilla.org/CA
These programs have certain criteria, which became more formal and rigorous over time (it used to be quite informal when the CA system was first set up). One commonality is generally to get a WebTrust CA audit, and there are also rules and meta-rules for CAs from the CA/Browser Forum.
https://cabforum.org/
This will require creating and publishing a certification policy and certification practice statement that have certain elements, and the auditors will look at those.
There are also physical security issues. For example, CAs use hardware security modules (HSMs) to perform their signing.
https://en.wikipedia.org/wiki/Hardware_security_module
The HSM will sign requested data, but won't export its private keys into a less-controlled environment like the CA's web server. It's akin to storing your crypto keys on a smartcard, only more expensive. :-)
[deleted]
I seem to understand this works just fine with HSTS. I am wondering what happens to key-pinning?
You can also use key pinning with Let's Encrypt certificates. Hopefully a future version of the client will provide tools to make this more convenient.
Anyone tried installing their certificates on AWS or Heroku?
We do a lot of the client testing on AWS, but a bigger question might be which OS image you use.
Can this be used for .onion sites?
Not yet; please see the thread at
https://community.letsencrypt.org/t/if-when-will-le-support-...
https://community.letsencrypt.org/t/if-when-will-le-support-...
Shame, because it would be actually needed. Cannot rely in .onion crypto vs MITM.
you got to use Google to sign-up for the beta... ?
why aren't they sponsored by google nor facebook...? isn't it the only way today to support "open internet" ?
[deleted](2)
To be honest I had not heard of them till now, and I am a bit confused even after reading some of their site...
So if the difficult part of being a CA (which I think is verifying that I, Paul Brian, own and control the rights to barlcaysbank.com and should have a certificate in that name) if that bit is either not done (!) or is reliant on donations to be able to afford it, is this going to work?
So if the difficult part of being a CA (which I think is verifying that I, Paul Brian, own and control the rights to barlcaysbank.com and should have a certificate in that name) if that bit is either not done (!) or is reliant on donations to be able to afford it, is this going to work?
This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive.
The only thing that regular-style certificates verify (this is what current CAs do, you can also grab a free one with automatic validation at https://www.startssl.com/) is that the person who controls the domain name has requested the certificate. This is usually done by serving a specific file over HTTP once, setting a TXT DNS record or responding to mail to [email protected]
The only thing that regular-style certificates verify (this is what current CAs do, you can also grab a free one with automatic validation at https://www.startssl.com/) is that the person who controls the domain name has requested the certificate. This is usually done by serving a specific file over HTTP once, setting a TXT DNS record or responding to mail to [email protected]
> This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive.
I'd like to see LetsEncrypt move into this territory though. What current private business providers are charging for this service is border-line extortion.
I'd like to see LetsEncrypt move into this territory though. What current private business providers are charging for this service is border-line extortion.
EV validation will have a marginal cost because of the offline interactions. DV can be done at almost no marginal cost. That's why Let's Encrypt can exist at all.
FWIW, you can already get an SSL cert for $4/year.
"this territory" was referring to EV certificates. Those cost more than $4.
I misread the post, sorry :|
But the certificate is (supposed) to say we have verified that this person / organisation exists and is "allowed" this domain.
Now if we extend the idea of every business or even human having their own (sub)-domain (lots of good benefits there) then we are in the territory of ensuring the CA's track you from birth - that's what governments do, and boy are they expensive.
I think what I am saying is we either have CA we can trust or we dump the whole thing and go to web of trust
Now if we extend the idea of every business or even human having their own (sub)-domain (lots of good benefits there) then we are in the territory of ensuring the CA's track you from birth - that's what governments do, and boy are they expensive.
I think what I am saying is we either have CA we can trust or we dump the whole thing and go to web of trust
That ship has sailed years ago. And now we have EV certificates to deal with that problem.
For the time being, it's DNS registrars who define who is allowed particular domain names, and DV CAs just try to draw the connection between what the registrars have said and the server you're visiting at a particular moment.
Well. I missed that memo. Or rather I kinda sorta knew it was getting devalued, but a Padlock in my browser is something I trust. If it's not trust worthy or verified should we not go the whole hog, dump trusted public keys from all browsers and move to the web-of-trust / certificate pinning.
From the blog:
From the blog:
just too much of a hassle. The application process can be
confusing. It usually costs money. It’s tricky to install
correctly. It’s a pain to update.
The padlock means you are connecting to the owner of that domain. That's a very valuable guarantee.
EV validation and whatnot is essentially a nice way to burn a ton of money on borderline extortion.
EV validation and whatnot is essentially a nice way to burn a ton of money on borderline extortion.
Vanilla SSL verifies the the website is legit, EV verifies that the business is legit. More competition will lower the price, there's tons of room for cheaper & faster EV providers.
> But a Padlock in my browser is something I trust.
On the padlock note, Microsoft Edge shows a hollowed out, grey padlock for DV certificates.
Only EV certs get a full green one (as well as the legal name as other browsers show for EV). See https://certsimple.com/blog/dv-ssl-in-microsoft-edge
On the padlock note, Microsoft Edge shows a hollowed out, grey padlock for DV certificates.
Only EV certs get a full green one (as well as the legal name as other browsers show for EV). See https://certsimple.com/blog/dv-ssl-in-microsoft-edge
> Microsoft Edge shows a hollowed out, grey padlock for DV certificates.
Firefox does the same. Luckily, Chrome is unlikely to do the same, since google.com itself is "only" domain validated.
Firefox does the same. Luckily, Chrome is unlikely to do the same, since google.com itself is "only" domain validated.
Now we just need to add a big red icon for http sites...
Mozilla actually have announced their plans to deprecate plain HTTP: https://blog.mozilla.org/security/2015/04/30/deprecating-non...
Yeah, verifying that "www.barclays.co.uk" is the correct URL for Barclays Bank PLC is what EV is for.
The other important role of a certificate is verifying that the server you're connected to is the correct one for the URL in the address bar. I may not know or care who "Hacker News" is supposed to belong to, but I do care that I'm connecting to the legit news.ycombinator.com, the same one I connected to yesterday, and that I'm not being Man-in-the-Middle'd.
The latter is what letsencrypt is for.
The other important role of a certificate is verifying that the server you're connected to is the correct one for the URL in the address bar. I may not know or care who "Hacker News" is supposed to belong to, but I do care that I'm connecting to the legit news.ycombinator.com, the same one I connected to yesterday, and that I'm not being Man-in-the-Middle'd.
The latter is what letsencrypt is for.
|browser|- letsencrypt verifies -|server|- EV verifies -|organization|
Why even push this today if you don't have cross-signing available? Without that Let's Encrypt is effectively broken out of the box.
PS - I actually like Let's Encrypt and the work they're doing. I will be all queued up when they go live to grab one (and, yes, will put my money where my mouth is and donate). But doing this today without cross-signing seems strange.