Anonymous self-signed x509 certs for testing are pretty much useless now. Browsers are getting more and more picky, and server software is starting to validate the full chain and refusing to work with anonymous self-signed certificates.
The solution is to create your own CA certs/keys, register them with the system, and use those to sign your certificates. This is a P.I.T.A, so
mkcert simplifies things (a little bit).
Written in Go, so distributed as a single big-assed binary which is nice. Supported on all the major 3 platforms.
mkcert does the following:
Run as normal user rather than
sudo or root. It automatically calls
sudo when necessary (which is entirely terrifying).
# generate and install CA cert/key pair in $CAROOT (which defaults to ~/.local/share/mkcert) mkcert -install # figure out where it generated the CA cert/key pair mkcert -CAROOT # change the CAROOT CAROOT=/some/other/place mkcert -install # create and sign a certificate in current dir mkcert localhost # create a PKCS12 bundle (password is 'changeit') mkcert -pkcs12 localhost # change the stores that it installs the CA certs in TRUST_STORES=system,java,nss mkcert -install # remove CA certs from trust stores mkcert -uninstall
/usr/local/share/ca-certificates/mkcert*with symlinks in
/etc/ca-certificates/extracted/cadir/mkcert*with symlinks in
/etc/ssl/certs/java/cacertskeystore. View/edit via
keytool -cacerts. Default password is
~/.pki/nssdb. View/edit via
certutil -L -d ~/.pki/nssdb
As mentioned above,
mkcert will automatically run
sudo for system operations, so thinking you are safe to run it from a user account for playing around, or making user-only changes to NSS DBs is a bad idea. If you have recently run a
sudo operation and run
mkcert within the previous
sudo's timeout window you will be making system-level changes. I have complained about this on the GitBucket for the project, but have so far been ignored. If you are worried about this, then run
sudo -k to invalidate your
sudo session which means you will at least be prompted for a password before
mkcert makes system changes.
The following powershell one-liner sets the CAROOT to the current directory, set the TRUST_STORES to system only, and creates and installs the CA certs in the system store.
$env:CAROOT = pwd; $env:TRUST_STORES = 'system'; .\mkcert.exe -install
This does not seem to need to be run from an administrator terminal. There is a pop-up box that asks for permission, so the authorization seems to be via the usual 'get the user to click yes' approach. It doesn't even require UAC...
The CA cert can be viewed/deleted via certmgr. Run the following command to start it:
Create signed certificates using
$env:CAROOT = pwd; .\mkcert.exe -pkcs12 localhost
Pretty much the same as Linux, however using the
nss trust store is not necessary as the browsers use the system store.
Chrome and browsers based on Chrome use the system store. Firefox is not supported by mkcert on Windows.
Safari uses the system store. I am assuming that Chrome does too, but have not tested it.
Both Chrome (and derivatives) and Firefox use NSS, so you need to install the CA into the
nss trust store.