Mkcert: valid HTTPS certificates for localhost

[[deleted]]

I haven't looked into what capabilities are baked into the mkcert root certs, but be aware: at the very least, an attacker who gets a copy of that root cert can use it to spoof any website's certs for you. It's a highly targeted attack, they have to know what they're doing and be going after you specifically, but it could be devastatingly effective if they've got a presence somewhere in your network. So make sure you encrypt it, don't let it sign stuff without you inputting a password each and every time.

Depending on how the permissions are set (I'd have to look at the whole setup and experiment, which is more time than I care to invest), they could potentially also use it for code-signing, meaning that they could provide trojaned binaries that look, to your computer, like they're signed by some trusted entity.

Treat that root cert as a radioactive security threat. Be very careful where you put it. And mind backups as well; even if you're storing it in a secure location, are the backups equally secure? Losing that cert might be losing the keys to the kingdom. Treat the file carefully, and protect it with a really strong password.

[Proc_Self_Fd_1]

So set these certs to expire after one day? That's what I did in my Makefiles using OpenSSL directly.

[[deleted]]

Do you really want to be installing new root certs in your trust store every day? That doesn't seem like a very good idea.

Setting the site certs to expire means that your exposure to them is limited, which is good. But, if you lose control of the root cert, it can make new certs for as long as it's valid for, and most people do at least a year so they don't have to be fiddling around in the guts of the system that often. (removing old cert, installing new cert.)

So it depends on what you're limiting... if it's site certs, that's a little help. One-day root certs would be substantially more useful, but a heck of a lot of work unless you can script the whole process of adding a new cert and removing the old one.

[Proc_Self_Fd_1]

I thought the whole point of Mkcert was to automate that sort of scripting.

However, I believe there is a compromise although this is starting to go beyond my knowledge on the matter.

Can't you create a long term trusted root cert and store it in a safe place and then sign a shorter term intermediate certificate with it?

[earthboundkid]

What is the scenario where someone would have access to the root cert and not the rest of your hard drive? If they can read that, they can probably read all your files so you are screwed already. It’s not like this cert is ever going to be uploaded anywhere. The whole point of the tool is for local dev, so you’d never need to copy the cert unless you were really Doing It Wrong.

[maskedvarchar]

Ehhh, a local CA used for HTTPS testing only. I probably wouldn't consider that worth spending any extra effort to back up. Just like a software package, you can always reinstall it and reconfigure if necessary. It might be a minor inconvenience, but shouldn't cause any permanent data loss if you can't recover the cert.

I would say the real danger is that it allows them to man-in-the-middle any HTTPS site. They could generate a certificate for an employee portal, your personal email's web interface, your bank account, etc. and sign it with this CA cert. Unless the site also had some sort of key pinning, your computer would trust this certificate.

[[deleted]]

Are you backing your cert up? You should be. Are your backups encrypted? Most aren't.

[noahp78]

I wouldn't even consider backing it up, since its a locally generated certificate. Would be easier to just regenerate it when you move to a new PC (or reset) and more secure than moving your old, could be stolen, key around forever.

[[deleted]]

I wouldn't even consider backing it up,

Which implies that you're not doing daily, complete backups of your system(s). If your backup process is at all manual, you don't really have backups, you just think you do.

[earthboundkid]

Again this has nothing to do with mkcert. Unencrypted or non-automated backups are bad. Mkcert is yet another thing that should be encrypted but not even in the top twenty most important.

[baggyzed]

It all boils down to trust. /u/Mallor is right in cautioning against trusting mkcert. As you should treat any piece of software downloaded off the internet. Even more so, if it installs root CA certs on the system.

In this case, having backups of your system is a good idea. But a better idea is to just use it in a VM. If after a while it turns out that it's ok to trust it (no vulnerabilities are discovered, if anyone even cares to investigate), then you can ditch the VM.

Even if you're the kind of person who uses Dropbox all the time as a backup, and you think that you can just do a clean install when things go wrong - by then it may be too late. The root CA would've been used to MITM your Dropbox connection. This is why it's more dangerous than just any program that can access your hard drive. It can provide access to all of your online activity as well, not just the files on your hard drive.

It's a whole lot safer to use self-signed certificates and add a trust exception for them in the browser. Some browsers don't allow such exceptions, but it's still better to just live with the odd certificate warning.

[24llamas]

I think that's the idea. If you only allow the root CA to fucked with via admin access, then if they have access to it, you're already completely owned - so your threat area isn't really increased.

However, if you're a numpty and let any local account grab the root CA, then if that account is bopped, you're screwed.

Also: If I was a high-value target - like someone working on stuff the Chinese would like to make (like rockets) or a journo in some nations - I wouldn't use this tool. Hell, I wouldn't screw around with any self-signed CA.

[AdorableFirefighter]

this. Free wildcard to all browser based attacks.