4 ms·
I don't understand why you made the CA private key user-readable. On my system, modifying the trust anchors requires root privileges. mkcert undoes this bound
by regecks 8y ago
I don't understand why you made the CA private key user-readable.
On my system, modifying the trust anchors requires root privileges.
mkcert undoes this boundary by opening a "shortcut" where any code on the machine can mint trusted certificates for any domain (like internet banking).
Why not make the CA private key only readable as root, and the issuance of new leaf certificates a privileged operation?
I would also expect that if/when you add ACME, that the CA key material is locked away in a different user to the one in the DE.
Maybe not every platform you support actually has this boundary, but I would expect that mkcert doesn't remove the boundary on platforms where it does exist.
Fan of your work since your Heartbleed scanner!
- amelius 8y agoI don't like the idea of the root requirement. Sometimes you are logged into a system maintained by someone else, and you want to do things as a normal user.
- regecks 8y agoThere's already a root requirement so that `mkcert -install` can deploy to the trust store. The problem is that after this point, the trust store is totally undermined, because the new CA's private key sits around unprotected. I feel like this is a similar pitfall to how if you add a user to the `docker` group for convenience, you (perhaps unknowingly) gave that user root access to the host. With this minor change, mkcert still retains its full function and convenience. Just type your password once in a blue moon when you need a certificate for a new fake real domain.
- grahamedgecombe 8y agoI don't think `mkcert -install` requires root in all cases. The NSS trust store is stored in ~/.pki/nssdb/ and can be written to without root.
- vectorEQ 8y agocan you create/use a local CA as non-root too?
- SomeHacker44 8y agoIs there no passphrase on these private keys? Especially the local CA?
- FiloSottile 8y agoThat is a fair argument, but it is already possible to get the behavior you want: the root key is generated with permissions 0400, so if your first run of mkcert is with root, all following invocations will also require root. My reason for not making it a first class feature (with its complexity cost) is that in the vast majority of cases, an attacker with the ability to read local files can also directly attack the browser. (At least in mkcert’s use case, which is development not deployment.) Also, I don’t really see how to maintain that boundary once ACME gives certificates to anything that can connect to a local port (without sending headers suggesting it’s a tricked browser).
- Natanael_L 8y agoHow about instead adding an alert when not running it as root?
- morpheuskafka 8y agoIt's similar to the approach used by Telerik Fiddler, you only have to be admin once to install the CA and it autogenerates certificates as needed for the HTTPS mitm proxy. However, it's ca is labelled "DO NOT TRUST" so it's easy to notice in the certificate info window.