
Let's Encrypt Root Trusted by All Major Root Programs - okket
https://letsencrypt.org/2018/08/06/trusted-by-all-major-root-programs.html
======
lvh
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/)

~~~
0xakhil
If somehow the private key of a root CA gets leaked, will that make all
devices vulnerable?

Also what is stopping a government from getting access to these private keys?

~~~
lvh
Until we discover the compromise, yes. We have a few better tools for doing
that now, like Certificate Transparency.

A number of CAs are effectively under the control of a government:
[https://ccadb-
public.secure.force.com/mozilla/IncludedCACert...](https://ccadb-
public.secure.force.com/mozilla/IncludedCACertificateReport)

The CABforum BRs define, de facto, the rules/requirements for being a CA:
[https://cabforum.org/baseline-requirements-
documents/](https://cabforum.org/baseline-requirements-documents/)

~~~
gsnedders
> The CABforum BRs define, de facto, the rules/requirements for being a CA:
> [https://cabforum.org/baseline-requirements-
> documents/](https://cabforum.org/baseline-requirements-documents/)

Note that there have been several ballots which have been won by the CAs
against the browsers, after which the browsers have turned around, shrugged,
and just enforced the new requirements for their root stores without them
becoming CAB BRs.

Most obviously this applies to Google and Apple _requiring_ all newly issued
certificates to be CT qualified.

~~~
bracewel
Note that CABF bylaws require a simple majority of browsers to vote positively
for a ballot for it to pass, regardless of how CAs vote.

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

~~~
kragniz
You can also set up a CNAME record to delegate the challenges to a provider
with a supported API.

~~~
Ajedi32
Doing it this way is also more secure, since it means you don't have to give
your web server unrestricted write access to every DNS record under your
domain.

acme-dns is specifically designed for this purpose:
[https://github.com/joohoi/acme-dns](https://github.com/joohoi/acme-dns)

~~~
fanf2
If you use BIND you can set an UPDATE ACL that allows your web server access
to change acme challenges only:
[https://fanf.dreamwidth.org/123294.html](https://fanf.dreamwidth.org/123294.html)

~~~
hardwaresofton
BIND looks fantastic but I really like the restricted nature of acme-dns -- I
don't know much about DNS and I don't want to inherit a huge amount of
functionality that I don't know how to properly administer -- I really only
want to manage a nameserver for acme challenges.

By "UPDATE ACL" I believe that you are referring to the DNS UPDATE RFC[0] --
it looks like cert-manager doesn't support generic UPDATEs yet[1].

[0]:
[https://tools.ietf.org/html/rfc2136](https://tools.ietf.org/html/rfc2136)

[1]: [https://github.com/jetstack/cert-
manager/issues/468](https://github.com/jetstack/cert-manager/issues/468)

~~~
fanf2
It’s pretty easy to make `dehydrated` use `nsupdate` for DNS challenges:
[https://github.com/fanf2/doh101/blob/master/roles/doh101/fil...](https://github.com/fanf2/doh101/blob/master/roles/doh101/files/dehydrated-
nsupdate.sh)

------
wwhitlow
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!

------
mholt
Also of note, they've raised the rate limit for certificates per registered
domain per week: [https://community.letsencrypt.org/t/certificates-per-
registe...](https://community.letsencrypt.org/t/certificates-per-registered-
domain-per-week-limit-raised/68657)

> 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
Why would you need 50 new certs a week for a single domain?

~~~
profmonocle
The 20 per week limit has been an issue for large organizations with tons of
different subdomains managed by different groups. Universities are a good
example: you might have things like bobsmith.faculty.example.edu,
cs101.compsci.example.edu, etc., which all count against the example.edu rate
limit.

This can especially be a problem because the renewal exception to the rate
limit doesn't work like you might expect. If a particular cert (meaning the
exact same set of domains) has already been created, it can be renewed
regardless of whether it would exceed the rate limit - but it still _counts
against_ the rate limit. If 45 certs have already been renewed in the last
week, you can only create 5 new ones. If 80 certs have been renewed in the
last week, you can't create any new ones. They plan to change this, but it
hasn't happened yet:
[https://github.com/letsencrypt/boulder/issues/2800](https://github.com/letsencrypt/boulder/issues/2800)

Some organizations have gotten rate limit exceptions to handle this particular
issue. Maybe they looked at some internal metrics and decided raising it to 50
would reduce the number of exceptions they have to make while still curbing
misuse.

~~~
cm2187
Why wouldn’t they use multi domains certs (SAN) or wildcard certs? (Unless
there is no trust between departments).

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

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

~~~
tialaramex
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.

~~~
forapurpose
Thanks; that's helpful. One point confuses me:

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

If only two major browser vendors operate a distinct major trust store, and
they aren't Microsoft or Apple, I infer that Google operates a distinct major
trust store (along with Mozilla). But that seems to contradict the second
statement: Why operates a trust store that you don't use. For ChromeOS?

~~~
tialaramex
For both ChromeOS and Android Google are the OS vendor. That's a lot of
devices, so certainly not a "trust store that you don't use" although if you
only run Chrome on Windows it might seem that way.

~~~
forapurpose
Android, of course. I really wish HN would let me go back and edit that one.

------
tialaramex
Here's Microsoft's notice:

[https://social.technet.microsoft.com/wiki/contents/articles/...](https://social.technet.microsoft.com/wiki/contents/articles/31680.microsoft-
trusted-root-certificate-program-updates.aspx#july18)

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.

------
dev_dull
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

~~~
pornel
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
> 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

~~~
CydeWeys
There are people who store historical DNS records for forensic and validation
purposes. And any CA worth its salt that does DV will be doing the same for
any domain they're issuing certs for, at a minimum.

Point is, people will be able to figure out that you're lying if you attempt
to claim that the cert was issued incorrectly.

~~~
kardos
Ah, quite interesting, thanks for that. On one hand, sounds good that the
obvious loophole is not wide open, on the other, it smells a bit like self
regulation. I guess the next frontier is getting one of these historical DNS
records made readily available alongside the CT logs.

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

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

------
rushughes
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?

~~~
perlgeek
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."?).

~~~
Qwertie
I heard the cost of EV certs is pretty high so it's much less likely a scammer
will buy an EV cert vs just a similar domain and a regular cert.

~~~
tommorris
Took this guy $177 to register a Delaware corporation called Stripe Inc and
get Comodo to issue him an EV certificate that looks exactly like the real
payment gateway. After Comodo revoked his cert, GoDaddy gave him one.

[https://stripe.ian.sh/](https://stripe.ian.sh/)

EV certificates tell you that a site is owned by a company with a particular
name, not that it is the company you actually want. There's a reason browser
vendors are de-emphasising EV: it isn't very useful.

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

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

~~~
mahesh_rm
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
Doesn't that only encrypt half the trip?

~~~
tialaramex
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.

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

~~~
tialaramex
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
I wonder why LE certs specify TLS Client EKU.

~~~
aaronmdjones
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.

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

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

~~~
Ajedi32
`certbot --certonly` + `heroku certs:add` + cron?

------
thingsilearned
Congrats Josh!

------
samgranieri
Awesome!

------
kimdotcom
JRE7?

~~~
tialaramex
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.

------
dddw
congrats Letsencrypt!

------
azerooth
congrats

------
projektir
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
We provide multiple options, including PayPal. The primary option here uses
Stripe via DonorBox:

[https://letsencrypt.org/donate/](https://letsencrypt.org/donate/)

~~~
projektir
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.

