Hacker News new | ask | show | jobs
by westurner 489 days ago
https://github.com/caddyserver/caddy/issues/5759 :

> When generating a CA cert via caddy and putting that in the trust store, those private keys can also forge certificates for any other domain.

RFC5280 (2008) "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" > Section 4.2.1.10 Name Constraints: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... :

> The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.

> Name constraints are not applied to self-issued certificates (unless the certificate is the final certificate in the path). (This could prevent CAs that use name constraints from employing self-issued certificates to implement key rollover.)

1 comments

If this is now finally supported that's great. The issue was that for it to be useful it has to be marked critical / fail-closed, because a CA with ignored name constraint == an unrestricted CA. But if you make it critical, then clients who don't understand it will just fail. You can see how this doesn't help adoption.
It says "Proposed Standard" on the RFC; maybe that's why it's not widely implemented if that's the case?

https://bettertls.com/ has Name Constraints implementation validation tests, but "Archived Results" doesn't seem to have recent versions of SSL clients listed?

  nameConstraints=critical,
DNS Certification Authority Authorization: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au... :

> Registrants publish a "CAA" Domain Name System (DNS) resource record which compliant certificate authorities check for before issuing digital certificates.

And hopefully they require DNSSEC signatures and DoH/DoT/DoQ when querying for CAA records.

Name Constraints has been around at least since 1999 (RFC 2459).

I'm not sure why CAA is brought up here. I guess it is somewhat complementary in "reducing" the power of CAs, but it defends against good CAs misissuing stuff, not limiting the power of arbitrary CAs (as it's checked at issuance time, not at time of use).

CAA does not require DNSSEC or DOH.