Live data from Hacker News

Let's Encrypt root certificate trusted by Mozilla

bugzilla.mozilla.org

101–110 of 166 posts

Re: Let's Encrypt root certificate trusted by Mozilla

#101
post #97

Earlier quoted context omitted.

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

At which point we're back to my original point of why does the information disclosure matter?

Defense-in-depth against CSRF attacks, which are still way too common. Sandstorm can't security-review the apps for you but it can mitigate most vulnerabilities.

Re: Let's Encrypt root certificate trusted by Mozilla

#102
post #47

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.

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.

Oh, that's excellent news!

Re: Let's Encrypt root certificate trusted by Mozilla

#103

I find it a little hilarious that the cert for the Test URL, https://helloworld.letsencrypt.org is a 90-day certificate that is expired as of a long time ago. https://i.imgur.com/1bQLHuF.png

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

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.

Re: Let's Encrypt root certificate trusted by Mozilla

#104
post #33

Earlier quoted context omitted.

I spoke about this earlier this week at a meetup. The consensus in the group was that wildcard certificates are desirable because they're easier to manage. If your tooling is good, the automation afforded by ACME can invalidate the need for wildcard certificates.

The problem is that Let's Encrypt enforces rate limits on how frequently you can request new certificates. According to the documentation[1], the limit averages out to one certificate (which can include up to 100 hostnames) per roughly 8 hours, per domain. That's probably good enough for almost everyone who uses hostnames to represent physical machines or services. But it's totally unusable if you want to create cert…

I'd imagine you might be able to reach out to them in that case.

Re: Let's Encrypt root certificate trusted by Mozilla

#105
post #85

Earlier quoted context omitted.

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.

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 wo…

Use lego. It works brilliantly in DNS mode

Re: Let's Encrypt root certificate trusted by Mozilla

#106
post #85

Earlier quoted context omitted.

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.

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 wo…

Use lego. It works brilliantly in DNS mode

Re: Let's Encrypt root certificate trusted by Mozilla

#107
post #26

Earlier quoted context omitted.

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 b…

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

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.

Re: Let's Encrypt root certificate trusted by Mozilla

#108

Earlier quoted context omitted.

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

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.

if you read the posters comment he explains why, they had to leave the original cert with the hash in place while the CA was being validated, despite it being expired.

Re: Let's Encrypt root certificate trusted by Mozilla

#109

Earlier quoted context omitted.

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

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.

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

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

Re: Let's Encrypt root certificate trusted by Mozilla

#110

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.

Java 8u101 added trust for their cross signer, IdenTrust.

https://bugs.openjdk.java.net/browse/JDK-8154757

Post reply on HN