
Let's Encrypt root certificate trusted by Mozilla - _jomo
https://bugzilla.mozilla.org/show_bug.cgi?id=1289889#c6
======
xutopia
The one thing stopping adoption for a lot of people is wilcard support.

[https://community.letsencrypt.org/t/please-support-
wildcard-...](https://community.letsencrypt.org/t/please-support-wildcard-
certificates/258)

~~~
devy
It's been discussed in details here the reason why they don't support
wildcard: "doing domain validation for wildcard certificates is not currently
in the ACME spec because it's a hard problem."[1]

LetsEncrypt CA allows Subject Alternative Names (SAN), the true need for an
unlimited sub-domains TLS cert vs. a SAN TLS cert is minimum, given Certbot's
automation capability.

[1]:
[https://github.com/certbot/certbot/issues/66#issuecomment-16...](https://github.com/certbot/certbot/issues/66#issuecomment-160487331)

~~~
Nullabillity
SAN isn't a practical solution for cases where you don't want to expose which
subdomains exist, or where you allocate them dynamically.

~~~
aroch
Unless all your subdomains are unique (e.g. coming out of a PRNG) AND there
are no public DNS entries for them, subdomain enumeration by DNS or IP space
is super easy. Not using SAN because of info disclosure concerns is security
through obscurity.

~~~
kentonv
Well yes, that's the idea: Say you have a wildcard DNS entry and you
cryptographically-randomly-generate hostnames in it, as an added layer of
defense against CSRF bugs in the applications running on these hosts.

[https://docs.sandstorm.io/en/latest/administering/wildcard/#...](https://docs.sandstorm.io/en/latest/administering/wildcard/#why-
sandstorm-needs-wildcard-dns)

~~~
aroch
That doesn't prevent domain enumeration for your application though. Once you
publish an application, anyone using it can find the address its hosted behind

~~~
icebraining
_> publish_

Sandstorm is a platform for personal computing; each person runs their own
applications, much like in a PC. Also, applications don't get hostnames; each
_document_ (or equivalent) in the application gets its own hostname.

~~~
tracker1
For such applications, there are plenty of relatively inexpensive paid options
for wildcard certs. I don't think this is something Let's Encrypt should
solve. I'd rather see them invest more time into supporting dynamic dns
provider domains better, which imho is a much larger issue for
small/hobby/free projects.

~~~
patates
I'm ready to pay a reasonable amount for a wildcard cert to use with some
hobby projects. Is there a trustworthy cheap wildcard cert provider which is
not Comodo?

~~~
gnyman
Have you checked StartSSL? They've worked fine for me.

------
mholt
Let's Encrypt's blog post: [https://letsencrypt.org/2016/08/05/le-root-to-be-
trusted-by-...](https://letsencrypt.org/2016/08/05/le-root-to-be-trusted-by-
mozilla.html)

------
UnoriginalGuy
Just to be clear, this is important because eventually Let's Encrypt wants to
no longer have to cross-sign their certificates for them to be considered
valid.

For that to happen they have to be added as a trusted CA in most major
platforms (and Firefox which has their own CA store for some reason).

~~~
gkanai
> (and Firefox which has their own CA store for some reason).

Firefox has it's own CA store because it's built for all 3 major (desktop)
platforms. OSX and Windows have their own but Linux does not and uses
Mozilla's.

~~~
mynameisvlad
Does Chrome provide its own CA store on Linux? It's also built for all 3 major
desktop platforms but uses the OSX and Windows stores.

~~~
gsnedders
They just use a copy of Mozilla's one on Linux. Of course, distro packages of
Chromium if they use the system NSS library may well use some system CA store.

------
chillydawg
Excellent news. The more trust the better. It's still no good using LE for API
endpoints as many client libs (java, etc) don't trust it or it's cross-signer.

~~~
pfg
The most recent Java update added the DST (IdenTrust) root certificate. Of
course it's going to take a while until that version is widely deployed, but
this gives vendors the option to tell API consumers to just update Java (as
opposed to manually modifying the key store), so that should help with
adoption.

~~~
teach
Oh, that's excellent news!

------
lllorddino
Hacker News should switch from Comodo to Let's Encrypt. Scumbags attempted to
trademark Let's Encrypt. [https://letsencrypt.org/2016/06/23/defending-our-
brand.html](https://letsencrypt.org/2016/06/23/defending-our-brand.html)

~~~
theandrewbailey
HN uses ycombinator's wildcard certificate, and it's not up until August 2019.
It's likely that they don't want to go through the trouble until it's really
needed.

~~~
Walkman
With Let's Encrypt, the trouble became "Whoaaa I just ran a command and
everything works like magic!"

~~~
lucb1e
Yeah until two hours later when you notice it messed with random shit it
wasn't even supposed to touch. At least, that was my experience; I suppose it
depends on how common your setup happens to be.

I still love Let's Encrypt for its principle, but I don't dare running it in
full auto mode anymore. A few custom shell scripts get the job done easily
enough.

~~~
fredsted
The auto mode just confused me. Every setup is different. Some use Apache,
nginx, or both -- and proxied behind Haproxy or varnish. Then there's stuff
like cpanel or virtualmin. So you got to expect any combination of those --
one or more, or combined. Their scripts would have to accommodate for so many
different things. How could I anticipate what it would do?

Am I missing something that would make this magically work?

Installing a SSL certificate is relatively easy anyhow. It's one of the most
common things you do with a http server.

~~~
tracker1
Depends on where you want SSL termination, and if you want it federated out...
The default Let's Encrypt project(s) integration tooling afaik isn't used by
many people, but there have been a lot of tools to do more simple ACME
integration into various web servers, reverse proxies and other
configurations. It's pretty cool.

I'm overall, very happy that it works at all... Some things I'd like to see...

Namely, automatically allow higher thresholds for domains used/provided by
dynamic dns providers such as freedns, that have more domains that may
want/need to register than limits allow.

Have a more transparent interface for requesting higher thresholds, or for
submission of virtual tlds for those domains that offer subdomains to others.

~~~
pfg
Dynamic DNS providers that are on the Public Suffix List are essentially
treated like TLDs in terms of rate limiting, meaning each client subdomain has
a separate counter. They should probably be on the PSL anyway; browsers rely
on it for cookie scoping.

~~~
tracker1
True enough, but would be nice if it detected that the SOA IP corresponds to a
public suffix dns provider.

Also, not sure where to put public suffix list additions for such a
provider... I was going to add bbs.io, as well as say the top 25 domains for
freedns.afraid.org, but wasn't sure where to add them.

~~~
pfg
The process is described here[1]. It needs to be performed by the domain
owner.

[1]: [https://publicsuffix.org/submit/](https://publicsuffix.org/submit/)

------
kibwen
Have any other browsers announced their intent to do the same?

~~~
heinrich5991
Other browsers do not have their own certificate stores but use those provided
by the OS. Next interesting things are whether Windows and Mac OS X add the
root certificate. I think Linux distributions tend to follow Mozilla's trust.

~~~
aroch
RE: Linux, You're correct, they're provided through the ca-certificates
package[0]:

"It includes, among others, certificate authorities used by the Debian
infrastructure and those shipped with Mozilla's browsers. "

RE: OSX - If you can get into Mozilla's trust stores, it's the same steps (and
pro forma, more or less) [1]

[0] [https://packages.debian.org/wheezy/ca-
certificates](https://packages.debian.org/wheezy/ca-certificates)

[1]
[https://www.apple.com/certificateauthority/ca_program.html](https://www.apple.com/certificateauthority/ca_program.html)

~~~
gsnedders
Historically ca-certificates has included certificates that Mozilla had
declined to include due to lack of audits, most notably the SPI root
certificate because some Debian infrastructure relied upon it. They've also
generally been relatively slow in removing root certificates after they're
removed upstream, despite any removal essentially being a security issue. I
think as of six months or so ago there is no longer any difference between ca-
certificates and upstream.

------
wiradikusuma
Question: any possible case of bad apples that make let's encrypt suddenly
lose their trust? Eg bcoz it's free, it's used by "bad guys" just like .info
tld.

~~~
jerf
The purpose of Let's Encrypt, and the SSL certificate infrastructure in
general, isn't to prevent "bad guys" from getting certificates. It's to ensure
that if you own the box, the certificate verifies that a web client is
speaking directly to that box with nothing in between. (Or more generally,
directly to an authorized end point by the owner of that DNS entry. Authority
can be delegated.)

In other words, it keeps bad guys out of the middle, not the end point. That's
all SSL can do, even if it works perfectly. Bad guys will still own end
points, in both the conventional sense of the word own and the pwning sense of
the word own. SSL can not (directly) do much about that. If you speak SSL to a
bad actor, well, there aren't any _other_ actors between you and the bad
actor, but you're still speaking on an encrypted, authenticated channel to a
bad actor.

This is in contrast to the DNS infrastructure in which it is sensible for a
TLD owner to attempt to prevent "people they don't want on their TLD" (more
generally than "bad guys" since a lot of the restrictions enforced are far
beyond that).

~~~
saynsedit
Source?

I remember reports in the past decrying CAs for issuing certificates for
phishing sites in the style of "gooogle.com" etc.

~~~
jerf
That's properly understood as a variant of getting a certificate of a domain
you don't own, for practical purposes. And the point there is still that the
"bad guys" shouldn't be able to get a cert that _appears to identify them as
Google_ , not that the bad guys _can 't get a cert_. It's two different
things. It is not a bug for Let's Encrypt to hand out certs to "bad" people.

~~~
saynsedit
That's fair and makes sense. Still, do you have a source for that type of CA
policy? With all due respect, I can't tell if this is just your opinion or a
codified threat model.

------
discreditable
I find it a little hilarious that the cert for the Test URL,
[https://helloworld.letsencrypt.org](https://helloworld.letsencrypt.org) is a
90-day certificate that is expired as of a long time ago.

[https://i.imgur.com/1bQLHuF.png](https://i.imgur.com/1bQLHuF.png)

~~~
joecool1029
If you read through the linked bug inside the bug, I think they had to do that
as part of the review process. They had to wait 90 days after the initial cert
was issued to have it reviewed. Since LE only issues 90 day certs this means
they'd have to review an expired one.

The whole Mozilla CA review process is a little crazy and the thread talks
about ways they could reform it in the future. (overview:
[https://wiki.mozilla.org/CA](https://wiki.mozilla.org/CA) )

~~~
discreditable
It's funny because LE's stance has been that 90-day certs are cool because it
is easy to automate renewal. However, no one bothered to set up renewal on
their example server.

~~~
pfg
You're missing the point here. helloworld.letsencrypt.org was used as the Test
URL in the root inclusion ticket[1]. The certificate was renewed multiple
times[2], but the expired certificate had to be restored at one point in order
to satisfy some of the requirements of the root inclusion process.

[1]:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1204656](https://bugzilla.mozilla.org/show_bug.cgi?id=1204656)

[2]:
[https://crt.sh/?q=helloworld.letsencrypt.org](https://crt.sh/?q=helloworld.letsencrypt.org)

------
cmdrfred
I think comodo had the idea to be added as a root CA by Mozilla first. They
should sue.

~~~
0xmohit
Comodo also had the idea to trademark "Let's Encrypt" [0].

[0] [https://letsencrypt.org/2016/06/23/defending-our-
brand.html](https://letsencrypt.org/2016/06/23/defending-our-brand.html)

~~~
polysaturate
That's the joke

~~~
wlesieutre
More specifically, Comodo's defense of that included "We did a 30 day free SSL
certificate first! Let's Encrypt is copying our business model!"

The free certificate they were referring to was a time-limited free trial that
you could use once and then start paying for.

~~~
__jal
They are truly amazing. Every time I think they've scraped the bottom of
either the incompetence or the sleaze barrels, Comodo manages to get even
worse.

One of their sales droids hassled me a while back with some deeply slimy
tactics, so I started grilling him about this and the various hacks they've
had. Flat out lied about ever having had unauthorized certs made, and claimed
he'd never heard of LE, but he just _knew_ they'd never do that, and I must
have bad information. (The first part of the second part I can believe.)

Who knows, maybe Comodo could come back after some strategic executive-
ectomies. Microsoft seems to be trying hard to rejoin the ranks of the not-
outstandingly-terrible. But as of now, I have serious doubts I'd ever choose
their services over someone more trustworthy, like, say, Bernie Madoff.

------
0xmohit
It's about time that HN switches to Let's Encrypt.

~~~
chc
Why? Is there something wrong with HN's current cert?

~~~
Nullabillity
1\. Funds Comodo's shady behaviour, and arguably increases their brand
recognition

2\. Ridiculous expiry time

~~~
stephenr
You know that Comodo won't issue a refund if they decide not to use them any
more right? They've paid the money.

I can understand moving things to show support for better alternatives but
let's not kid ourselves - moving now or moving when the cert expires, doesn't
hurt Comodo any differently.

