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.
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.
EDIT: Kudos everyone working on Let's Encrypt. You're doing awesome work.
https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
Firefox trusts the cert on TFA because letsencrypt.org itself is using a certificate signed by IdenTrust.
https://letsencrypt.org/howitworks/
I'd actually pay more than I do now for SSL certs to get that kind of simplicity.
And this is in Firefox, which renders fonts more bold than other browsers.
I can't wait until letsencrypt is done.
Text needs to be legible, please try and stick to normal and bold weights.
(No affiliation, I just saw their HN post some time before)
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.
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.
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
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.
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).
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.
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 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.
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?
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?
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 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?
You have to trust something.
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.
(just hoping they will appear next year)
One more nail in the coffin of the ssl cert mafia.
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.
Altough because of SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) the need for wildcard certificates has greatly diminished.
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.
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
* 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
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-----
>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.
[0]: https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le...
It's almost as if money is more important than key management practices.
How much time actually takes it before I can safely use it and be sure that the majority of browsers accept it?
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
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?
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"?
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.
Great work, by the way.
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
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.
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. :-)
https://community.letsencrypt.org/t/if-when-will-le-support-...
And I don't think they will/should ever go for it. After the CAcert experience, I don't believe community based certificate signing will work in the current TLS ecosystem.
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?
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 postmaster@yourdomain.tld
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.
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 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|