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

21–30 of 39 posts

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

#21

Post by GoblinSlayer »

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.

Deleting the key immediately should be safe enough.

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

#22

Post by chgs »

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.

I certainly wouldn’t trust myself. Now if I could import a root cert and specify what domains to trust that would be another thing, and it seems browsers are starting to pay attention to name constraints which has not taken 20 odd years.

I’d rather be able to further constraint at the cert store though.

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

#23

Post by IrishTechie »

otabdeveloper4 wrote: post #18
ikiris wrote: post #6

Earlier quoted context omitted.

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.

That’s an interesting take that would probably make for a fascinating separate HN thread to discuss

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

#25

Post by gear54rus »

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.

And thankfully, just like a loaded gun, there are still ways to get it without paternalistic types getting in the way.

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

#26

Post by zwp »

vlovich123 wrote: post #24

I really wish that we would have the option to get rid of CAs and just use DNSSEC as the root of the chain of trust.

Is it coming? I notice that OpenSSL now has support for raw public keys.

The spec (RFC 7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)") suggests DANE/DNSSEC as a mechanism to bind identities to public keys (section 6).

https://datatracker.ietf.org/doc/html/rfc7250

Will this really be simpler?

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

#28

Post by jakupovic »

IrishTechie wrote: post #23
otabdeveloper4 wrote: post #18

Earlier quoted context omitted.

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.

That’s an interesting take that would probably make for a fascinating separate HN thread to discuss

Probably not much to say other than all of our current takes are based on a half-finished system originally designed for telephone and X.500 (DAP+LDAP && GoBlue) standards. Pretty new to me, after 25+ years ;), and the x509v3 things I kept using in openssl finally made some sense, see

https://en.m.wikipedia.org/wiki/X.500 and especially the "The relationship of the X.500 Directory and X.509v3 digital certificates" which say that web servers/commerce was crafted on a system which didn't support remote directories and needed something local, hence the CAs and CA stores. Copied here for reference:

"The current use of X.509v3 certificates outside the Directory structure loaded directly into web browsers was necessary for e-commerce to develop by allowing for secure web based (SSL/TLS) communications which did not require the X.500 directory as a source of digital certificates as originally conceived in X.500 (1988). One should contrast the role of X.500 and X.509 to understand their relationship in that X.509 was designed to be the secure access method for updating X.500 before the WWW, but when web browsers became popular there needed to be a simple method of encrypting connections on the transport layer to web sites. Hence the trusted root certificates for supported certificate authorities were pre loaded into certificate storage areas on the personal computer or device."

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

#29

Post by lmz »

westurner wrote: post #13
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.... : > Th…

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.

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

#30

Post by lazyweb »

I'm hosting my own internal CA using Hashicorp Vault and some ansible + CI. The root CA is valid for 20 years, intermediate CA 10 years, client certs three months.

Initial setup is a handful of commands interacting with Vault's CLI, from there, with CI in place, client certs are renewed automatically. Services are restarted / reloaded as well. Works flawlessly.

I should maybe write a (small) blog explaining how it works.

Post reply on HN