24 ms·

Let's Encrypt Root Trusted by All Major Root Programs

1532 points by okket 8y ago

wwhitlow 8y ago
That's great I'm always glad to hear about the progress updates from them. Setting there service up on my personal website was one of the easiest improvements I have ever made. Thanks mostly to the fact that I have shell access to the server I host on. The auto renew works perfectly haven't even had to put thought about renewing my cert since last year and Let's Encrypt Certs don't last that long. We are getting very close for there to be no reason not to have an HTTPS connection to any website which is a great progression. Thanks For Everything You Guys Have Done To Accomplish This Let's Encrypt!
classichasclass 8y ago
This is very good news, though they don't really show their work on that five year number. Are they waiting on a specific operating system to drop below a certain level?
- duskwuff 8y ago
  Reading between the lines a bit: the last major vendor to accept the ISRG Root was Microsoft. Windows is supposed to pick up new roots through updates, but there are probably enough systems out there with updates disabled or broken that it's safest to wait a few years for them to cycle out.
- collinmanderson 8y ago
  They'll probably re-evaluate market share once they get closer to the five year number. I bet they'll find they'll need to cross-sign for more like 10 years.
- tialaramex 8y ago
  I don't have an explanation for the five years beyond your guess. Rather sooner, at the end of September 2021 the DST Root CA X3 that cross-signs their existing intermediates expires. In practice many systems don't directly obey expiries baked into root certs, a self-signed root certificate is largely a vehicle for conveniently moving the key inside it, it's not signed by anybody we trust independently so why care what it does or does not say about that key? And of course if the IdenTrust / ISRG relationship remains good there's no reason IdenTrust can't sign new Let's Encrypt intermediates with another of their CA roots that hasn't expired. The short lifetime of Let's Encrypt leaf certs means they wouldn't even need to have decided before 2021 what to do about this.
hardwaresofton 8y ago
Glad to hear this! Let's Encrypt is such an amazing resource -- it single-handedly caused a leap in internet security as well as removing what was essentially a artificially inflated (IMO) barrier to entry (for most people) to getting certs. Has anyone set up the new wildcard certs? If so, who did you choose as your DNS 01 Challenge[0] provider? I currently do DNS through a local provider and they don't have an API so it's been out of my reach.
- DrPhish 8y ago
  For wildcard certs, I run my own DNS infrastructure, so I just created the _acme-challenge records as indicated by the first run of certbot Are you unable to add arbitrary TXT records with your provider?
  - hardwaresofton 8y ago
    I am, but I'm trying not to do it manually -- I actually use cert-manager[0] on a tiny kubernetes cluster -- which means when I make an Ingress for an application (app.example.com) (which does what it sounds like), watcher processes kick off and go get a cert for me with http 01 validation currently. This works thanks to cert-manager being able to automate the process of setting up the proper /.well-known/xxx route with access to kubernetes features. cert-manager also supports DNS 01, but of course they support the bigger providers (so they'll take some options and do the web requests to set up the TXT records)... I haven't looked into it a crazy amount (since in the end I can still just make multiple http 01 validated certs), but was just curious. [0]: https://github.com/jetstack/cert-manager/ https://github.com/jetstack/cert-manager/
    - MertsA 8y ago
      FWIW Personally I just use the DNS RFC2136 plugin for certbot. I use bind for DNS.
      - hardwaresofton 8y ago
        Could you expand on this? You run bind on your server, then you add your own server as an (additional?) nameserver to your domain's registrar?
OnlyRepliesToBS 8y ago
What a low bar.
projektir 8y ago
I would really like it if some of these services would support non-Paypal donations. I have little interest in supporting Paypal and their questionable practices, but many services have no other donation option.
- jaas 8y ago
  We provide multiple options, including PayPal. The primary option here uses Stripe via DonorBox: https://letsencrypt.org/donate/ https://letsencrypt.org/donate/
  - deleted 8y ago
    [deleted]
  - projektir 8y ago
    Looks like the Stripe widget is completely invisible when JS is disabled, so all I saw was the PayPal button. There isn't even so much as a link or text, it's just completely blank. Now I'm wondering how many invisible Stripe widgets I've been missing.
schoen 8y ago
Just in case anyone isn't aware, this isn't about browser compatibility today (which uses the DST certificate from IdenTrust) but about future compatibility without the IdenTrust cross signature. https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/ Edit: lvh has explained this better at https://news.ycombinator.com/item?id=17699037 https://news.ycombinator.com/item?id=17699037
mholt 8y ago
Also of note, they've raised the rate limit for certificates per registered domain per week: https://community.letsencrypt.org/t/certificates-per-registered-domain-per-week-limit-raised/68657 https://community.letsencrypt.org/t/certificates-per-registe... > The ‘certificates per registered domain per week’ limit has been raised from 20 to 50. https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/
- driverdan 8y ago
  Why would you need 50 new certs a week for a single domain?
  - deleted 8y ago
    [deleted]
  - dumbfounder 8y ago
    "The main limit is Certificates per Registered Domain, (50 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain. If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week. A certificate with multiple names is often called a SAN certificate, or sometimes a UCC certificate."
  - Operyl 8y ago
    In my case, we provision a wild card for accounts on our service (*.account.companycustomers.com). While we bundle these together with a few other sign ups, it's sometimes better to get it out the door initially, and then bundle them with more subdomains on renewal. We have received an exemption to the certificate limit per domain to achieve this at least.
  - apawloski 8y ago
    Because you could have 50 subdomains, for which you'd need either a wildcard cert or 50 separate certs. That might seem like a ton per week, but consider a PaaS (example-123.herokuapp.com) or a blog platform (example-diary.someblogapp.com). Personally I'd prefer a wildcard cert there, but at organizations where certificate inventory is a requirement (where they need to track, procure, and invalidate on a per-subdomain basis) Let's Encrypt is a solid option.
lvh 8y ago
Some context on how this works: your system (usually OS) ships with a bunch of root certificates that are allowed to sign any certificate (de facto). New CAs need to get in that store to be trusted, but they don't get to be in that store until they convince a vendor (here, "root program") to include them. But LE has been around for a while and its certs mostly work fine everywhere! That's partially because it was already in a ton of root programs, and partially because of cross-signed roots. A cross-signed root is effectively the root CA except signed by a different CA. A client that doesn't trust the new root yet trusts it via the cros-signed root. Most sites need 2 certificates in the chain to be validated: the leaf certificate certifying the site itself and the intermediate online CA that signs leaf certs. The intermediate is signed by the root, which is in your trust store so you don't need to send it. Lots of sites send it anyway. This is a misconfiguration and just serves to make TLS connections slower: you're sending an extra certificate along that by definition nobody uses. This is because it's self-signed: you either already trusted it anyway (and then didn't need it) or you don't trust it and then the self-signed certificate is unconvincing. New CAs also need their cross signed root sent along to be widely supported, so they basically get that worse performance all the time. Unfortunately, you don't know in advance which roots a TLS client will trust, so until you're in every major trust store, you have to. Now that LE is in every major trust store, it's a real first-class CA and everyone gets to look forward to doing away with the cross-signed root crutch. (You can't do it immediately because old, unpatched machines.) LE is great and has done wonders to make all the other CAs up their game. You can read more about LE's trust chain here: https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/
- tialaramex 8y ago
  A reason you might want to send a "root" in some cases: New roots get spun up all the time (maybe a dozen a year? That sort of ballpark). For Let's Encrypt that meant the cross signing arrangement described, but for an existing CA they can use their older roots to sign newer ones while they wait for trust stores to do their thing, this produces a certificate for the same name, but instead of being self-signed it's signed by the old root. If you send this cert as well as your ordinary intermediate, some older clients that had no reason to trust the intermediate can now connect it back to a root they do trust. So for a few bytes you get a compatibility win. This type of thing is also done when a root is replaced urgently due to distrust. Clients that are on top of their game trust the replacement root. Clients that don't know about this distrust trust the old root, which has signed the replacement. So everybody trusts the replacement, yet up-to-date devices aren't at risk from the old root any more. A mechanism called AIA chasing lets browsers which use it "fix" an incomplete chain, but at some cost to privacy, another approach is to cache bits of chains and try to use the cached bits to fix broken chains, again this has privacy problems. Definitely send your intermediate (any modern leaf cert in the Web PKI has an intermediate) but more might be necessary. I would like to see AIA chasing done by TLS servers (there's no major privacy concern there) so that this isn't extra work for admins, but we don't live in that world, so it's on you (or tools you use) to get it right.
dddw 8y ago
congrats Letsencrypt!
burdzwastaken 8y ago
I am so proud of letsencrypt. This is a huge step forward for https everywhere!
lawn 8y ago
As a side question is there a guide to setup https for a static website hosted at AWS buckets?
- jimwalsh 8y ago
  Yes, you will need to front the bucket with CloudFront and use the AWS Cert Manager to manage your own cert or to get one through AWS (free) and apply it to CloudFront.
- geofft 8y ago
  I looked at using Let's Encrypt for this, but it's much simpler to use AWS Certificate Manager's own certificate authority for this, because it's also free and it's built in so it will handle renewals for you. It's basically a checkbox in CloudFront; just put your files in S3 and set up a CloudFront distribution. (If you're hosting an apex domain, e.g., example.com and not just www.example.com, it also makes things easier if you can use Route 53 as your DNS host, because CloudFront IPs keep changing and you can't make a CNAME for an apex.)
- mahesh_rm 8y ago
  Cloudflare is your friend. Either with a cloud front distribution or with a simple S3 bucket website. Guide: step 1, sign up for free at cloudflare. Step 2, follow instructions. As simple as it comes!
  - Qwertie 8y ago
    Doesn't that only encrypt half the trip?
    - tialaramex 8y ago
      The description is vague. Cloudflare offers customers a certificate from its private CA which can secure connections from Cloudflare to your systems without you needing a publicly trusted cert. This secures the other half of the circuit successfully if you take that route. Arguably in this limited role it's more secure since there's no third party.
forapurpose 8y ago
> Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry. What about Linux and the BSD's? Tangential questions: OS's usually are the system's primary stores of root certs, if I understand correctly[0], but browsers and other applications store them too. How are conflicts resolved? If Mozilla untrusts Fubar CA's root cert and the OS still trusts it, what happens? And why have redundant stores? I suspect the answer is that the browser vendor wants to ensure the user has a happy TLS experience despite OS problems, but that's just a reasonable guess. [0] A reference right in front of my nose: https://news.ycombinator.com/item?id=17699037 https://news.ycombinator.com/item?id=17699037
- hsivonen 8y ago
  > What about Linux and the BSD's? Linux distros typically use Mozilla's root list. > If Mozilla untrusts Fubar CA's root cert and the OS still trusts it, what happens? Then it no longer works in Firefox but works in other apps.
- walrus01 8y ago
  using debian as an example, the ca-certificates package uses the mozilla root CA list as an upstream source. https://packages.debian.org/stretch/ca-certificates https://packages.debian.org/stretch/ca-certificates
- tialaramex 8y ago
  To answer your tangent: Only two major browser vendors also operate a distinct major trust store. If you're Microsoft (IE, Edge) or Apple (Safari) this is de facto not a problem since you also control the OS. For Mozilla their NSS is almost completely independent of OS trust stores, with the special case that on Windows (maybe macOS but I'm not sure) they offer to look in your OS trust store for any additions you've made to the OS vendor store and trust those on the rationale that you must have had some reason to do that. For Chrome the OS trust store is used, (on Android this of course is Google's trust store but on a desktop it isn't) but, Chrome layers some Google policy rules on top.
  - 8y ago
dev_dull 8y ago
It’s amazing to me that there a multiple entities which can sign valid TLS certain for the same domain. Seems like a serious design flaw, especially with some of those trust authorities being overseas
- jaas 8y ago
  You can limit that by deploying CAA records for your domain in DNS. All trusted CAs are required to respect those records.
- pornel 8y ago
  This is being fixed: • You can use CAA DNS records to choose which CAs can create certs for your domain. • You can watch Certificate Transparency logs to catch CAs that didn't obey. AFAIK both are becoming mandatory for CAs. It doesn't technically stop violations, but ensures they get caught and shut down if they fail to obey the rules (like StartCom and Symantec).
  - kardos 8y ago
    > You can watch Certificate Transparency logs to catch CAs that didn't obey. Isn't there a timing issue there? Eg, if I get a cert from Comodo and change my CAA record to specify Let's Encrypt immediately afterwards, anyone checking if issuer doesn't match CAA can get a false positive
    - homero 8y ago
      It's only for issuers to check not clients
    - icebraining 8y ago
      > if I get a cert from Comodo and change my CAA record to specify Let's Encrypt immediately afterwards Why would you do that?
      - kardos 8y ago
bks 8y ago
Congratulations to the LE team, we have been a very happy major sponsor the product. It works amazingly well in conjunction with Caddy for https://www.phishprotection.com https://www.phishprotection.com. I would be very interested to see the percentage of the Internet that is actively using LE certificates vs. the number of certificates that have simply been generated for valid domains.
kimdotcom 8y ago
JRE7?
- tialaramex 8y ago
  That's a very terse question, but I'll take it that you're interested in whether TLS clients running on Java 7 will (out of the box) trust Let's Encrypt server certificates The answer is that for Oracle's Java updating to 7u111 is necessary for this to work (or to 8u101 if you run Java 8) and that for other people's Java implementations it will depend upon where they get their trust store, Oracle's is the most popular in Java.
rushughes 8y ago
Is Let's Encrypt good enough for say a production e-commerce site, or is it more for personal blogs and the HTTPS everywhere movement?
- blahyawnblah 8y ago
  Its certs are the same in the end as anyone else's certs. You just don't have to pay or go through a bunch of hoops to get one. Fine for e-commerce. They don't do extended validation or any of the more "I am really who I say I am certs."
- mike1o1 8y ago
  Shopify uses Let Encrypt for their shops, so I'd imagine it's pretty safe for e-commerce sites. https://www.shopify.com/blog/73511365-all-shopify-stores-now-use-ssl-encryption-everywhere https://www.shopify.com/blog/73511365-all-shopify-stores-now...
  - rushughes 8y ago
    Awesome, that's great to hear! Thank you.
- perlgeek 8y ago
  Let's Encrypt gives you a DV (domain validated) cert. That is good enough for most use cases, including amazon.com. Most German banks for example use EV (extended Validation) certs, where the organization name appears in the browser's address bar. However, the benefit of EV certificates is debatable, since it's pretty easy to register a valid-sounding company under some jurisdiction or another. Also, organization structure aren't transparent to everybody (how many of your non-tech friends would be surprised if google.com had a certificate issued for "Alphabet Inc."?).
  - gsnedders 8y ago
    > Also, organization structure aren't transparent to everybody (how many of your non-tech friends would be surprised if google.com had a certificate issued for "Alphabet Inc."?). A clear example of this is KLM, where www.klm.com's certificate is registered to "KONINKLIJKE LUCHTVAART MAATSCHAPPIJ N.V." (try that on a mobile browser!). It's sufficiently different to what people expect (which is, admittedly, just an initialism) that I've known various people who actually understand EV certificates get thrown by it.
apo 8y ago
Odd question I know, but does this mean that LE certs can be used to sign Java applets?
- newman314 8y ago
  The last time I looked into this, the LE certs did not support code signing.
- tialaramex 8y ago
  No. Let's Encrypt is focused only on the Web PKI. So that includes web servers (obviously), and everything that speaks TLS on the Internet (e.g an IMAP server for your email) but it doesn't include either type of end-to-end email encryption (S/MIME or PGP), nor any kind of code signing, document signing, timestamp services or similar. Technically this is implemented in two ways. One: Where Trust Stores themselves have distinct trust for different feature sets, ISRG/ Let's Encrypt asked only for the flags needed to do Web PKI. e.g. In Mozilla they didn't ask for S/MIME or code signing (today Mozilla doesn't do code signing anyway). Two: Certificates have a section called Extended Key Usage (EKU) which can list arbitrary purposes for which the certificate's issuer says the Public Key included in this certificate is to be used. EKUs on Let's Encrypt certificates specify two purposes, 1.3.6.1.5.5.7.3.1 (TLS Server) and 1.3.6.1.5.5.7.3.2 (TLS Client) so these certificate proclaim themselves not to be suitable for other purposes.
  - pritambaral 8y ago
    I wonder why LE certs specify TLS Client EKU.
    - zimmerfrei 8y ago
      That enables mutually-authenticated TLS connections between servers.
    - aaronmdjones 8y ago
      As zimmerfrei said, it allows one webserver to connect to another (e.g. a load balancer, with a certificate, to connect to a backend webserver) and present that cert to the server it is connecting to. Without the client EKU bit, a conforming TLS implementation would reject the connection.
jmtame 8y ago
I'm wondering when I can use them for my wildcard SSL certs on Heroku. Anyone hear of them adding support?
- Ajedi32 8y ago
  `certbot --certonly` + `heroku certs:add` + cron?
tialaramex 8y ago
Here's Microsoft's notice: https://social.technet.microsoft.com/wiki/contents/articles/31680.microsoft-trusted-root-certificate-program-updates.aspx#july18 https://social.technet.microsoft.com/wiki/contents/articles/... I don't know anything about Gordon Bock (credited with that page), or indeed Microsoft's PM for their root trust programme, Mike Reilly. All the trust programmes (except Mozilla's) are run in a way that doesn't give us (as relying parties, or as subscribers) much insight. I'd love to know more about why it took so long to approve ISRG, but likely we'll never be told.
dgroves 8y ago
For the record, we should be destroying root not securing it.
thingsilearned 8y ago
Congrats Josh!
samgranieri 8y ago
Awesome!
azerooth 8y ago
congrats
quintin 8y ago
I have a letsencrypt cert for my domain but I still use the cloudflare’s certificate and terminate (I keep my cert code commented). I do think so that I reduce the load/content between Cloudflare and my web server. Is this a good approach? FYI, I have a blog and not too paranoid about security between CF and my web server.

1532 points by okket 8y ago

That's great I'm always glad to hear about the progress updates from them. Setting there service up on my personal website was one of the easiest improvements I have ever made. Thanks mostly to the fact that I have shell access to the server I host on. The auto renew works perfectly haven't even had to put thought about renewing my cert since last year and Let's Encrypt Certs don't last that long. We are getting very close for there to be no reason not to have an HTTPS connection to any website which is a great progression. Thanks For Everything You Guys Have Done To Accomplish This Let's Encrypt!

classichasclass 8y ago

This is very good news, though they don't really show their work on that five year number. Are they waiting on a specific operating system to drop below a certain level?

duskwuff 8y ago
Reading between the lines a bit: the last major vendor to accept the ISRG Root was Microsoft. Windows is supposed to pick up new roots through updates, but there are probably enough systems out there with updates disabled or broken that it's safest to wait a few years for them to cycle out.
collinmanderson 8y ago
They'll probably re-evaluate market share once they get closer to the five year number. I bet they'll find they'll need to cross-sign for more like 10 years.
tialaramex 8y ago
I don't have an explanation for the five years beyond your guess. Rather sooner, at the end of September 2021 the DST Root CA X3 that cross-signs their existing intermediates expires. In practice many systems don't directly obey expiries baked into root certs, a self-signed root certificate is largely a vehicle for conveniently moving the key inside it, it's not signed by anybody we trust independently so why care what it does or does not say about that key? And of course if the IdenTrust / ISRG relationship remains good there's no reason IdenTrust can't sign new Let's Encrypt intermediates with another of their CA roots that hasn't expired. The short lifetime of Let's Encrypt leaf certs means they wouldn't even need to have decided before 2021 what to do about this.

hardwaresofton 8y ago

Glad to hear this! Let's Encrypt is such an amazing resource -- it single-handedly caused a leap in internet security as well as removing what was essentially a artificially inflated (IMO) barrier to entry (for most people) to getting certs. Has anyone set up the new wildcard certs? If so, who did you choose as your DNS 01 Challenge[0] provider? I currently do DNS through a local provider and they don't have an API so it's been out of my reach.

DrPhish 8y ago
For wildcard certs, I run my own DNS infrastructure, so I just created the _acme-challenge records as indicated by the first run of certbot Are you unable to add arbitrary TXT records with your provider?
- hardwaresofton 8y ago
  I am, but I'm trying not to do it manually -- I actually use cert-manager[0] on a tiny kubernetes cluster -- which means when I make an Ingress for an application (app.example.com) (which does what it sounds like), watcher processes kick off and go get a cert for me with http 01 validation currently. This works thanks to cert-manager being able to automate the process of setting up the proper /.well-known/xxx route with access to kubernetes features. cert-manager also supports DNS 01, but of course they support the bigger providers (so they'll take some options and do the web requests to set up the TXT records)... I haven't looked into it a crazy amount (since in the end I can still just make multiple http 01 validated certs), but was just curious. [0]: https://github.com/jetstack/cert-manager/ https://github.com/jetstack/cert-manager/
  - MertsA 8y ago
    FWIW Personally I just use the DNS RFC2136 plugin for certbot. I use bind for DNS.
    - hardwaresofton 8y ago
      Could you expand on this? You run bind on your server, then you add your own server as an (additional?) nameserver to your domain's registrar?

OnlyRepliesToBS 8y ago

What a low bar.

projektir 8y ago

I would really like it if some of these services would support non-Paypal donations. I have little interest in supporting Paypal and their questionable practices, but many services have no other donation option.

jaas 8y ago
We provide multiple options, including PayPal. The primary option here uses Stripe via DonorBox: https://letsencrypt.org/donate/ https://letsencrypt.org/donate/
- deleted 8y ago
  [deleted]
- projektir 8y ago
  Looks like the Stripe widget is completely invisible when JS is disabled, so all I saw was the PayPal button. There isn't even so much as a link or text, it's just completely blank. Now I'm wondering how many invisible Stripe widgets I've been missing.

schoen 8y ago

Just in case anyone isn't aware, this isn't about browser compatibility today (which uses the DST certificate from IdenTrust) but about future compatibility without the IdenTrust cross signature. https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/ Edit: lvh has explained this better at https://news.ycombinator.com/item?id=17699037 https://news.ycombinator.com/item?id=17699037

mholt 8y ago

Also of note, they've raised the rate limit for certificates per registered domain per week: https://community.letsencrypt.org/t/certificates-per-registered-domain-per-week-limit-raised/68657 https://community.letsencrypt.org/t/certificates-per-registe... > The ‘certificates per registered domain per week’ limit has been raised from 20 to 50. https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/

driverdan 8y ago
Why would you need 50 new certs a week for a single domain?
- deleted 8y ago
  [deleted]
- dumbfounder 8y ago
  "The main limit is Certificates per Registered Domain, (50 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain. If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week. A certificate with multiple names is often called a SAN certificate, or sometimes a UCC certificate."
- Operyl 8y ago
  In my case, we provision a wild card for accounts on our service (*.account.companycustomers.com). While we bundle these together with a few other sign ups, it's sometimes better to get it out the door initially, and then bundle them with more subdomains on renewal. We have received an exemption to the certificate limit per domain to achieve this at least.
- apawloski 8y ago
  Because you could have 50 subdomains, for which you'd need either a wildcard cert or 50 separate certs. That might seem like a ton per week, but consider a PaaS (example-123.herokuapp.com) or a blog platform (example-diary.someblogapp.com). Personally I'd prefer a wildcard cert there, but at organizations where certificate inventory is a requirement (where they need to track, procure, and invalidate on a per-subdomain basis) Let's Encrypt is a solid option.

lvh 8y ago

Some context on how this works: your system (usually OS) ships with a bunch of root certificates that are allowed to sign any certificate (de facto). New CAs need to get in that store to be trusted, but they don't get to be in that store until they convince a vendor (here, "root program") to include them. But LE has been around for a while and its certs mostly work fine everywhere! That's partially because it was already in a ton of root programs, and partially because of cross-signed roots. A cross-signed root is effectively the root CA except signed by a different CA. A client that doesn't trust the new root yet trusts it via the cros-signed root. Most sites need 2 certificates in the chain to be validated: the leaf certificate certifying the site itself and the intermediate online CA that signs leaf certs. The intermediate is signed by the root, which is in your trust store so you don't need to send it. Lots of sites send it anyway. This is a misconfiguration and just serves to make TLS connections slower: you're sending an extra certificate along that by definition nobody uses. This is because it's self-signed: you either already trusted it anyway (and then didn't need it) or you don't trust it and then the self-signed certificate is unconvincing. New CAs also need their cross signed root sent along to be widely supported, so they basically get that worse performance all the time. Unfortunately, you don't know in advance which roots a TLS client will trust, so until you're in every major trust store, you have to. Now that LE is in every major trust store, it's a real first-class CA and everyone gets to look forward to doing away with the cross-signed root crutch. (You can't do it immediately because old, unpatched machines.) LE is great and has done wonders to make all the other CAs up their game. You can read more about LE's trust chain here: https://letsencrypt.org/certificates/ https://letsencrypt.org/certificates/

tialaramex 8y ago
A reason you might want to send a "root" in some cases: New roots get spun up all the time (maybe a dozen a year? That sort of ballpark). For Let's Encrypt that meant the cross signing arrangement described, but for an existing CA they can use their older roots to sign newer ones while they wait for trust stores to do their thing, this produces a certificate for the same name, but instead of being self-signed it's signed by the old root. If you send this cert as well as your ordinary intermediate, some older clients that had no reason to trust the intermediate can now connect it back to a root they do trust. So for a few bytes you get a compatibility win. This type of thing is also done when a root is replaced urgently due to distrust. Clients that are on top of their game trust the replacement root. Clients that don't know about this distrust trust the old root, which has signed the replacement. So everybody trusts the replacement, yet up-to-date devices aren't at risk from the old root any more. A mechanism called AIA chasing lets browsers which use it "fix" an incomplete chain, but at some cost to privacy, another approach is to cache bits of chains and try to use the cached bits to fix broken chains, again this has privacy problems. Definitely send your intermediate (any modern leaf cert in the Web PKI has an intermediate) but more might be necessary. I would like to see AIA chasing done by TLS servers (there's no major privacy concern there) so that this isn't extra work for admins, but we don't live in that world, so it's on you (or tools you use) to get it right.

dddw 8y ago

congrats Letsencrypt!

burdzwastaken 8y ago

I am so proud of letsencrypt. This is a huge step forward for https everywhere!

lawn 8y ago

As a side question is there a guide to setup https for a static website hosted at AWS buckets?

jimwalsh 8y ago
Yes, you will need to front the bucket with CloudFront and use the AWS Cert Manager to manage your own cert or to get one through AWS (free) and apply it to CloudFront.
geofft 8y ago
I looked at using Let's Encrypt for this, but it's much simpler to use AWS Certificate Manager's own certificate authority for this, because it's also free and it's built in so it will handle renewals for you. It's basically a checkbox in CloudFront; just put your files in S3 and set up a CloudFront distribution. (If you're hosting an apex domain, e.g., example.com and not just www.example.com, it also makes things easier if you can use Route 53 as your DNS host, because CloudFront IPs keep changing and you can't make a CNAME for an apex.)
mahesh_rm 8y ago
Cloudflare is your friend. Either with a cloud front distribution or with a simple S3 bucket website. Guide: step 1, sign up for free at cloudflare. Step 2, follow instructions. As simple as it comes!
- Qwertie 8y ago
  Doesn't that only encrypt half the trip?
  - tialaramex 8y ago
    The description is vague. Cloudflare offers customers a certificate from its private CA which can secure connections from Cloudflare to your systems without you needing a publicly trusted cert. This secures the other half of the circuit successfully if you take that route. Arguably in this limited role it's more secure since there's no third party.

forapurpose 8y ago

> Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry. What about Linux and the BSD's? Tangential questions: OS's usually are the system's primary stores of root certs, if I understand correctly[0], but browsers and other applications store them too. How are conflicts resolved? If Mozilla untrusts Fubar CA's root cert and the OS still trusts it, what happens? And why have redundant stores? I suspect the answer is that the browser vendor wants to ensure the user has a happy TLS experience despite OS problems, but that's just a reasonable guess. [0] A reference right in front of my nose: https://news.ycombinator.com/item?id=17699037 https://news.ycombinator.com/item?id=17699037

hsivonen 8y ago
> What about Linux and the BSD's? Linux distros typically use Mozilla's root list. > If Mozilla untrusts Fubar CA's root cert and the OS still trusts it, what happens? Then it no longer works in Firefox but works in other apps.
walrus01 8y ago
using debian as an example, the ca-certificates package uses the mozilla root CA list as an upstream source. https://packages.debian.org/stretch/ca-certificates https://packages.debian.org/stretch/ca-certificates
tialaramex 8y ago
To answer your tangent: Only two major browser vendors also operate a distinct major trust store. If you're Microsoft (IE, Edge) or Apple (Safari) this is de facto not a problem since you also control the OS. For Mozilla their NSS is almost completely independent of OS trust stores, with the special case that on Windows (maybe macOS but I'm not sure) they offer to look in your OS trust store for any additions you've made to the OS vendor store and trust those on the rationale that you must have had some reason to do that. For Chrome the OS trust store is used, (on Android this of course is Google's trust store but on a desktop it isn't) but, Chrome layers some Google policy rules on top.
- 8y ago

dev_dull 8y ago

It’s amazing to me that there a multiple entities which can sign valid TLS certain for the same domain. Seems like a serious design flaw, especially with some of those trust authorities being overseas

jaas 8y ago
You can limit that by deploying CAA records for your domain in DNS. All trusted CAs are required to respect those records.
pornel 8y ago
This is being fixed: • You can use CAA DNS records to choose which CAs can create certs for your domain. • You can watch Certificate Transparency logs to catch CAs that didn't obey. AFAIK both are becoming mandatory for CAs. It doesn't technically stop violations, but ensures they get caught and shut down if they fail to obey the rules (like StartCom and Symantec).
- kardos 8y ago
  > You can watch Certificate Transparency logs to catch CAs that didn't obey. Isn't there a timing issue there? Eg, if I get a cert from Comodo and change my CAA record to specify Let's Encrypt immediately afterwards, anyone checking if issuer doesn't match CAA can get a false positive
  - homero 8y ago
    It's only for issuers to check not clients
  - icebraining 8y ago
    > if I get a cert from Comodo and change my CAA record to specify Let's Encrypt immediately afterwards Why would you do that?
    - kardos 8y ago

bks 8y ago

Congratulations to the LE team, we have been a very happy major sponsor the product. It works amazingly well in conjunction with Caddy for https://www.phishprotection.com https://www.phishprotection.com. I would be very interested to see the percentage of the Internet that is actively using LE certificates vs. the number of certificates that have simply been generated for valid domains.

kimdotcom 8y ago

JRE7?

tialaramex 8y ago
That's a very terse question, but I'll take it that you're interested in whether TLS clients running on Java 7 will (out of the box) trust Let's Encrypt server certificates The answer is that for Oracle's Java updating to 7u111 is necessary for this to work (or to 8u101 if you run Java 8) and that for other people's Java implementations it will depend upon where they get their trust store, Oracle's is the most popular in Java.

rushughes 8y ago

Is Let's Encrypt good enough for say a production e-commerce site, or is it more for personal blogs and the HTTPS everywhere movement?

blahyawnblah 8y ago
Its certs are the same in the end as anyone else's certs. You just don't have to pay or go through a bunch of hoops to get one. Fine for e-commerce. They don't do extended validation or any of the more "I am really who I say I am certs."
mike1o1 8y ago
Shopify uses Let Encrypt for their shops, so I'd imagine it's pretty safe for e-commerce sites. https://www.shopify.com/blog/73511365-all-shopify-stores-now-use-ssl-encryption-everywhere https://www.shopify.com/blog/73511365-all-shopify-stores-now...
- rushughes 8y ago
  Awesome, that's great to hear! Thank you.
perlgeek 8y ago
Let's Encrypt gives you a DV (domain validated) cert. That is good enough for most use cases, including amazon.com. Most German banks for example use EV (extended Validation) certs, where the organization name appears in the browser's address bar. However, the benefit of EV certificates is debatable, since it's pretty easy to register a valid-sounding company under some jurisdiction or another. Also, organization structure aren't transparent to everybody (how many of your non-tech friends would be surprised if google.com had a certificate issued for "Alphabet Inc."?).
- gsnedders 8y ago
  > Also, organization structure aren't transparent to everybody (how many of your non-tech friends would be surprised if google.com had a certificate issued for "Alphabet Inc."?). A clear example of this is KLM, where www.klm.com's certificate is registered to "KONINKLIJKE LUCHTVAART MAATSCHAPPIJ N.V." (try that on a mobile browser!). It's sufficiently different to what people expect (which is, admittedly, just an initialism) that I've known various people who actually understand EV certificates get thrown by it.

apo 8y ago

Odd question I know, but does this mean that LE certs can be used to sign Java applets?

newman314 8y ago
The last time I looked into this, the LE certs did not support code signing.
tialaramex 8y ago
No. Let's Encrypt is focused only on the Web PKI. So that includes web servers (obviously), and everything that speaks TLS on the Internet (e.g an IMAP server for your email) but it doesn't include either type of end-to-end email encryption (S/MIME or PGP), nor any kind of code signing, document signing, timestamp services or similar. Technically this is implemented in two ways. One: Where Trust Stores themselves have distinct trust for different feature sets, ISRG/ Let's Encrypt asked only for the flags needed to do Web PKI. e.g. In Mozilla they didn't ask for S/MIME or code signing (today Mozilla doesn't do code signing anyway). Two: Certificates have a section called Extended Key Usage (EKU) which can list arbitrary purposes for which the certificate's issuer says the Public Key included in this certificate is to be used. EKUs on Let's Encrypt certificates specify two purposes, 1.3.6.1.5.5.7.3.1 (TLS Server) and 1.3.6.1.5.5.7.3.2 (TLS Client) so these certificate proclaim themselves not to be suitable for other purposes.
- pritambaral 8y ago
  I wonder why LE certs specify TLS Client EKU.
  - zimmerfrei 8y ago
    That enables mutually-authenticated TLS connections between servers.
  - aaronmdjones 8y ago
    As zimmerfrei said, it allows one webserver to connect to another (e.g. a load balancer, with a certificate, to connect to a backend webserver) and present that cert to the server it is connecting to. Without the client EKU bit, a conforming TLS implementation would reject the connection.

jmtame 8y ago

I'm wondering when I can use them for my wildcard SSL certs on Heroku. Anyone hear of them adding support?

Ajedi32 8y ago
`certbot --certonly` + `heroku certs:add` + cron?

tialaramex 8y ago

Here's Microsoft's notice: https://social.technet.microsoft.com/wiki/contents/articles/31680.microsoft-trusted-root-certificate-program-updates.aspx#july18 https://social.technet.microsoft.com/wiki/contents/articles/... I don't know anything about Gordon Bock (credited with that page), or indeed Microsoft's PM for their root trust programme, Mike Reilly. All the trust programmes (except Mozilla's) are run in a way that doesn't give us (as relying parties, or as subscribers) much insight. I'd love to know more about why it took so long to approve ISRG, but likely we'll never be told.

dgroves 8y ago

For the record, we should be destroying root not securing it.

thingsilearned 8y ago

Congrats Josh!

samgranieri 8y ago

Awesome!

azerooth 8y ago

congrats

quintin 8y ago

I have a letsencrypt cert for my domain but I still use the cloudflare’s certificate and terminate (I keep my cert code commented). I do think so that I reduce the load/content between Cloudflare and my web server. Is this a good approach? FYI, I have a blog and not too paranoid about security between CF and my web server.