←back to thread

238 points edent | 1 comments | | HN request time: 0.292s | source
Show context
rusk ◴[] No.29813411[source]
I read somewhere a while ago that LE are working on what’s called “intermediate CA” [0] which would solve the problem. Apparently from a regulatory standpoint there are some questions around abuse that need to be answered before they can go ahead. The basic idea is that you can issue your own certificates based on the LE CA that is already recognised by the browsers.

EDIT [0] https://community.letsencrypt.org/t/does-lets-encrypt-offer-...

replies(1): >>29813642 #
Ajedi32 ◴[] No.29813642[source]
We're a long ways away from name-constrained intermediaries being viable from a regulatory and technical perspective. I'd explain, but commenter in a thread linked to the one you posted has a pretty detailed explanation already: https://community.letsencrypt.org/t/sign-me-as-an-intermedia...
replies(1): >>29814296 #
infogulch ◴[] No.29814296[source]
From that it looks like the main issue is regulatory requirements that force CAs to log all issued certificates via CT (certificate transparency) logs. Given that this is the very thing we're trying to avoid with a private CA ("CT" and "leaking internal hostnames" are functionally synonymous) we seem to be at an impasse at the level of base requirements.

Maybe an IP constraint that restricts certs to only be valid in private IP spaces (10.*, 192.168.1.*, etc)?

replies(2): >>29814341 #>>29814620 #
zozbot234 ◴[] No.29814341[source]
You can still use wildcard certificates to avoid leaking the entirety of your private hostnames, while providing transparency around the "authority" portion of your domains.
replies(2): >>29816000 #>>29816132 #
1. vetinari ◴[] No.29816132[source]
But then your constrained CA doesn't get you anything, you could not get from the parent CA. You could save your troubles as well.