Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
1–10 of 39 posts
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#2Been looking for a fix like this. Thanks
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#3I've kept this in my notes
openssl genrsa -out private.key 4096 && openssl req -new -key private.key -out signreq.csr -subj "/CN=FQDN" && openssl x509 -req -days 365 -in signreq.csr -signkey private.key -out cert.crt
But ideally everyone could just use something like mkcert to take care of this
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#4There 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.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#5i use mkcert and /etc/hosts for local dev website building
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#6There 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.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#7There 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.
Interesting, just checked out if mkcert (the popular way of doing this) supports it and found two issues:
https://github.com/FiloSottile/mkcert/issues/131
https://github.com/FiloSottile/mkcert/pull/113
Hopefully Filippo revisits this now that it's broadly supported.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#8for user wants to have self hosted CA (for testing) with easy to use GUI, XCA is a great option
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#9I previously used openssl-based scripts to generate certificates to use for local development or applications on a private network. I have since moved to using the step CLI [1].
OpenSSL is powerful, but it's hard to figure out how to use correctly. Each command seems cryptic no matter how many times I use it.
The step CLI is a lot simpler, even though it has a few quirks: generating PKCS1 formatted private keys instead of the newer PKCS7 format, making every leaf certificate eligible to be either a server certificate or a client certificate, and absurdly low default certificate expirations.
Re: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux
#10There 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.
None of those things are appropriate in the context of this article.