Live data from Hacker News

Let’s Encrypt to transition to ISRG root

scotthelme.co.uk

31–40 of 114 posts

Re: Let’s Encrypt to transition to ISRG root

#31
post #18

Earlier quoted context omitted.

I actually have the reverse model: requesting certs is done by its own isolated and dedicated container and scp’d to the server which needs it. Compromising a web-server will thus not compromise my DNS.

I like the sound of this idea, happen to have a Dockerfile/scripts for it on GitHub?

Nope. I’m using LXC and have set things up manually.

It’s just a basic setup with dehydrated[1], some bash scripts for deployment and cron though.

[1] https://github.com/lukas2511/dehydrated

Re: Let’s Encrypt to transition to ISRG root

#32

Earlier quoted context omitted.

Hard in what way? Using my favorite client/library ( https://go-acme.github.io/lego/ ) I can generate wildcard cert with: lego \ --email="info@example.com" \ --accept-tos \ --path="./ssl" \ --domains="*.example.com" \ --dns="route53" (AWS credentials need to be available in the environment)

So you need to execute 3rd party software on your machine and let it fiddle with your DNS settings? Personally, I would not want to do that.

Then write your own acme client, it's not a terrible burden -- although I've only personally done it with the normal URL validation method

Re: Let’s Encrypt to transition to ISRG root

#33

Earlier quoted context omitted.

Hard in what way? Using my favorite client/library ( https://go-acme.github.io/lego/ ) I can generate wildcard cert with: lego \ --email="info@example.com" \ --accept-tos \ --path="./ssl" \ --domains="*.example.com" \ --dns="route53" (AWS credentials need to be available in the environment)

So you need to execute 3rd party software on your machine and let it fiddle with your DNS settings? Personally, I would not want to do that.

Well, you could use certbot (https://github.com/certbot/certbot, see https://certbot.eff.org/docs/using.html#dns-plugins), which is from EFF, so not exactly third party, to do that.

Re: Let’s Encrypt to transition to ISRG root

#35

Earlier quoted context omitted.

Hard in what way? Using my favorite client/library ( https://go-acme.github.io/lego/ ) I can generate wildcard cert with: lego \ --email="info@example.com" \ --accept-tos \ --path="./ssl" \ --domains="*.example.com" \ --dns="route53" (AWS credentials need to be available in the environment)

So you need to execute 3rd party software on your machine and let it fiddle with your DNS settings? Personally, I would not want to do that.

Nope, the protocol is well-documented so that anyone who wants to reinvent the wheel can do so.

Re: Let’s Encrypt to transition to ISRG root

#36
post #12
post #4

They haven't really published a list of good/bad clients. I'm interested in what's the practical cutoff point with mobile phones? I expect desktop browsers will be less of an issue.

On Android, the root was first added in Nougat (~half of devices according to Android Distribution Dashboard). But I think that browsers (like Firefox and Chrome) on Android tend to bring their own cacerts rather than using the device's, so it's probably not as bad as it looks. To that end, it was added to NSS 3.26/Firefox 50 (November 2016) and to Chrome 57 (March 2017). On iOS, it was first added in iOS 10 (2016).…

That website list is for SHA-2 compatibility, not the new root.

Re: Let’s Encrypt to transition to ISRG root

#37
post #27

I'm not an expert of certificates, but some quick skimming of https://tools.ietf.org/html/rfc5280#section-4.1 suggests that a certificate only references the issuer certificate by name. Since, according to the article, the two different Lets encrypt intermediates have the same key, and the same name, they are interchangeable? As in, could I just replace the intermediate in my cert-chain and have everything continue s…

> If you get a new certificate issued from the X3 intermediate that chains to the ISRG root, but you serve the old, cross-signed X3 intermediate in the TLS handshake, the connection will still work (* for now, keep reading).

Seems to suggest "yes"

Re: Let’s Encrypt to transition to ISRG root

#38
post #20
post #2

ISRG stands for Internet Security Research Group.

This is in their latest blog post "Christine expands our board’s global perspective with her career experience. She worked for many years in the Australian government" I was wondering what impact if she, a board member of ISRG, has to comply with the Australian encryption laws?

CA have zero control over your encryption keys as is. As for the MitM there likely several CAs actually based and doing business in Australia. Yet with certificate transparency being mandatory it's almost guaranteed that entity doing something shady will go out of business really fast.

Re: Let’s Encrypt to transition to ISRG root

#39
post #19
post #12

Earlier quoted context omitted.

On Android, the root was first added in Nougat (~half of devices according to Android Distribution Dashboard). But I think that browsers (like Firefox and Chrome) on Android tend to bring their own cacerts rather than using the device's, so it's probably not as bad as it looks. To that end, it was added to NSS 3.26/Firefox 50 (November 2016) and to Chrome 57 (March 2017). On iOS, it was first added in iOS 10 (2016).…

I was eating breakfast with a multitude of Android phones around me and four "older ones" could not access that site. The oldest that could connect was ~5 months old, all using new Mobile Chrome versions.

I have a first-generation Pixel, so a couple years old now, and it accessed the test site fine.

Re: Let’s Encrypt to transition to ISRG root

#40

So what motivates one CA to cross-sign another? I would have thought, if you were a CA you'd prefer not to enable your competitors - especially one who's planning to give away the product for free.

The greatest motivator of all, money!

How much money are we talking here?

Because most businesses, if you ask them "How much $$$ to destroy your business?" will respond "absolutely loads"

Post reply on HN