3 ms·

The short answer is: because client software doesn't implement that. The longer answer is: the certificate system absolutely does support issuing sub-CAs with

by wiml 5y ago

The short answer is: because client software doesn't implement that. The longer answer is: the certificate system absolutely does support issuing sub-CAs with "name constraints", which would let LE issue you, instead of a wildcard host certificate, an intermediate CA which you can use to issue host certs only in your own part of the name space. It solves this problem very neatly. However, see point 1 again: client support is lacking. OpenSSL and NSS handle it, IIRC the Windows and Android implementations are tolerable, but Apple's homegrown SSL implementation doesn't. (It's not even a new feature — it's in the original PKIX RFCs from, what, 25 years ago.) And without client support, CAs aren't going to do the work to be able to issue them, which means we're stuck with the far-less-secure approach of wildcard certs with shared (!) private keys, or unconstrained sub-CAs.

infogulch 5y ago
Thanks, that makes sense. The only way I can see Apple making this change is if there were external pressure, which means implementing it without support for Apple products at first. Someone has to make the first move, and it won't be Apple. I did a bit of searching and it looks like this feature has been requested a few times on the LetsEncrypt community site, and this [1] is the best thread I think. Commenters there bring up another potential roadblock: aiui current regulatory requirements mean that there's a bunch of manual paperwork for every issued CA, name constrained or not. If anyone could automate and operationalize that process it would be LetsEncrypt. It would still be a lot of work, on the same scale as their initial (long, arduous) effort to automate issuance of leaf certs. Maybe a solution could be found by leaning on DNSSEC as a stronger validation of domain ownership than dns01. (As a side benefit, it would also be a small step towards eliminating the need for CAs in general.) [1]: https://community.letsencrypt.org/t/standardized-tools-for-automating-subordinate-name-constrained-cas/136969 https://community.letsencrypt.org/t/standardized-tools-for-a...
- tptacek 5y ago
  On-the-wire DNS forgery isn't even close to the biggest DNS hijacking threat (that'd be registrar account takeover), so it's hard to imagine a CA policy shift motivated by DNSSEC.
gregmac 5y ago
Isn't a sub-CA just another "intermediate", basically in the same way the actually CA certificate Let's Encrypt uses to sign is an intermediate? In that case, I'd have expected the failure mode of something not supporting the name constraints extension to be that it doesn't recognize the constraints: it would accept any certificate issued by the sub-CA. Is that not true? Or is the problem that Apple devices are a big enough target that allowing these bad certificates to be issued in the wild would be too much of a problem?
- wiml 5y ago
  Mostly right, yes: You can mark the field containing the constraint as "critical" or "non critical", which indicates to the end software what it should do if it doesn't understand this constraint. Apple software doesn't understand it, so it looks at the critical bit (at least Apple got that right): you can choose whether to fail by having it accept invalid certificates for any other website on the planet, or to fail by having it reject the intermediate completely. I just assume that any general CA who's issuing a sub-CA instead of a wildcard would be unwilling to leave it marked non-critical.
  - infogulch 5y ago
    I would be satisfied with that solution. Sure it would exclude Apple devices until Apple gets its act together but at least we'd have something. Mark it as Beta and note that it doesn't support Apple prominently and maybe we can start making progress. CA management and issuance software is not very well developed and needs broad scale active use to get it into a usable state.
    - infogulch 5y ago
      Apparently this issue has been resolved in newer Apple OS versions: https://news.ycombinator.com/item?id=29812443 https://news.ycombinator.com/item?id=29812443

by wiml 5y ago

infogulch 5y ago

Thanks, that makes sense. The only way I can see Apple making this change is if there were external pressure, which means implementing it without support for Apple products at first. Someone has to make the first move, and it won't be Apple. I did a bit of searching and it looks like this feature has been requested a few times on the LetsEncrypt community site, and this [1] is the best thread I think. Commenters there bring up another potential roadblock: aiui current regulatory requirements mean that there's a bunch of manual paperwork for every issued CA, name constrained or not. If anyone could automate and operationalize that process it would be LetsEncrypt. It would still be a lot of work, on the same scale as their initial (long, arduous) effort to automate issuance of leaf certs. Maybe a solution could be found by leaning on DNSSEC as a stronger validation of domain ownership than dns01. (As a side benefit, it would also be a small step towards eliminating the need for CAs in general.) [1]: https://community.letsencrypt.org/t/standardized-tools-for-automating-subordinate-name-constrained-cas/136969 https://community.letsencrypt.org/t/standardized-tools-for-a...

tptacek 5y ago
On-the-wire DNS forgery isn't even close to the biggest DNS hijacking threat (that'd be registrar account takeover), so it's hard to imagine a CA policy shift motivated by DNSSEC.

gregmac 5y ago

Isn't a sub-CA just another "intermediate", basically in the same way the actually CA certificate Let's Encrypt uses to sign is an intermediate? In that case, I'd have expected the failure mode of something not supporting the name constraints extension to be that it doesn't recognize the constraints: it would accept any certificate issued by the sub-CA. Is that not true? Or is the problem that Apple devices are a big enough target that allowing these bad certificates to be issued in the wild would be too much of a problem?

wiml 5y ago
Mostly right, yes: You can mark the field containing the constraint as "critical" or "non critical", which indicates to the end software what it should do if it doesn't understand this constraint. Apple software doesn't understand it, so it looks at the critical bit (at least Apple got that right): you can choose whether to fail by having it accept invalid certificates for any other website on the planet, or to fail by having it reject the intermediate completely. I just assume that any general CA who's issuing a sub-CA instead of a wildcard would be unwilling to leave it marked non-critical.
- infogulch 5y ago
  I would be satisfied with that solution. Sure it would exclude Apple devices until Apple gets its act together but at least we'd have something. Mark it as Beta and note that it doesn't support Apple prominently and maybe we can start making progress. CA management and issuance software is not very well developed and needs broad scale active use to get it into a usable state.
  - infogulch 5y ago
    Apparently this issue has been resolved in newer Apple OS versions: https://news.ycombinator.com/item?id=29812443 https://news.ycombinator.com/item?id=29812443