Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

previnder.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

#11

Post by GauntletWizard »

Plasmoid wrote: post #4

There is just one thing missing from this. Name Constraints. This doesn't get brought up enough but a Name Constraint on a root cert lets you limit where the root cert can be signed to. So instead of this cert being able to impersonate any website on the internet, you ratchet it down to just the domain (or single website) that you want to sign for.

Browser support for it is pretty new, which is why it's so often missed. It only happened in mid/late 2023.

I've been shopping a talk since then about how to set up a name-constrained root certificate, and what it should look like. It's still hard! CFSSL is my go-to tool, and it doesn't have support. I had to fork it to make it work. OpenSSL has support, but it's configuration is like all OpenSSL configuration - Poorly documented and nonstandard, mixing INI objects and object-refs.

Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

#13

Post by westurner »

Plasmoid wrote: post #4

There is just one thing missing from this. Name Constraints. This doesn't get brought up enough but a Name Constraint on a root cert lets you limit where the root cert can be signed to. So instead of this cert being able to impersonate any website on the internet, you ratchet it down to just the domain (or single website) that you want to sign for.

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

Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

#16

Post by taosx »

ikiris wrote: post #6
Plasmoid wrote: post #4

There is just one thing missing from this. Name Constraints. This doesn't get brought up enough but a Name Constraint on a root cert lets you limit where the root cert can be signed to. So instead of this cert being able to impersonate any website on the internet, you ratchet it down to just the domain (or single website) that you want to sign for.

Stuff like this is why I consider giving people a CA how to akin to a loaded gun. They almost invariably are not going to securely store the keys properly, set up CRLs, or manage their PKI in a safe manner.

Some of us are aware of the risks and choose to accept them. Last week I tried to analyze HTTPS traffic on my Linux machine using MITM to check what some programs were sending back home, but omg, it was a pain, I also partially failed. Some apps just ignore system certs and use their own. Tools like mitmproxy help (docs are lacking btw). I paid for both the devices and the software, shouldn't I be able to take a peek at what they are doing?

Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

#18

Post by otabdeveloper4 »

ikiris wrote: post #6
Plasmoid wrote: post #4

There is just one thing missing from this. Name Constraints. This doesn't get brought up enough but a Name Constraint on a root cert lets you limit where the root cert can be signed to. So instead of this cert being able to impersonate any website on the internet, you ratchet it down to just the domain (or single website) that you want to sign for.

Stuff like this is why I consider giving people a CA how to akin to a loaded gun. They almost invariably are not going to securely store the keys properly, set up CRLs, or manage their PKI in a safe manner.

Doesn't matter. PKI for https is a solution in search of a problem. In reality all it does is just validate domain name ownership, something that could have more easily been done with DKIM keys. We don't need certificate authorities.

Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

#19

Post by nh2 »

Plasmoid wrote: post #4

There is just one thing missing from this. Name Constraints. This doesn't get brought up enough but a Name Constraint on a root cert lets you limit where the root cert can be signed to. So instead of this cert being able to impersonate any website on the internet, you ratchet it down to just the domain (or single website) that you want to sign for.

See this for a simple CA tutorial script including Name Constraints using only OpenSSL:

https://github.com/nh2/internal-contstrained-pki

Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

#20

Post by 3np »

GauntletWizard wrote: post #11
Plasmoid wrote: post #4

There is just one thing missing from this. Name Constraints. This doesn't get brought up enough but a Name Constraint on a root cert lets you limit where the root cert can be signed to. So instead of this cert being able to impersonate any website on the internet, you ratchet it down to just the domain (or single website) that you want to sign for.

Browser support for it is pretty new, which is why it's so often missed. It only happened in mid/late 2023. I've been shopping a talk since then about how to set up a name-constrained root certificate, and what it should look like. It's still hard! CFSSL is my go-to tool, and it doesn't have support. I had to fork it to make it work. OpenSSL has support, but it's configuration is like all OpenSSL configuration - Poor…

There is mainstream browser support for name constraints now?! That is huge, I had given up hoping for adoption progress already and was one of my major gripes regarding web stagnation.
Post reply on HN