In our company we have an internal CA certificate for signing various things including the proxied (MITM'd) HTTPS connections.

Suppose we use this CA to sign a key for "localhost" for use in automated testing (so we don't have to mess about with custom Firefox profiles). This key would be distributed to the developers, probably by checking it into the source repo.

What are the dangers of this approach? Suppose an attacker stole the key, and could then sign localhost HTTPS. What could they do?


4 Answers 4


Two years after the initial question, things seem to have changed a bit. Facing the same issue, I found that the letsencrypt service does not sign certificates for localhost and the reason for that is stated here: https://github.com/letsencrypt/boulder/issues/137 and here: https://cabforum.org/pipermail/public/2015-June/005673.html

In a nutshell, indeed "multiple resolvers (notably, OS X's) send localhost queries to the network" instead of keeping them local, so having a signed certificate for localhost can be a security risk.


With such a certificate, any system who trusts your internal CA will trust a server running on "localhost" as being genuine, i.e. running really on "localhost". But "localhost" can be reached, network wise, only locally, so if your client successfully connects to https://localhost/whatever then it already knows that it is talking with the local machine. Therefore, no extra security issue.

Of course, the certificate only authenticates the host name. It says nothing about whether the server is malicious or benign, only about who the server is.

Mind, though, that if someone modifies the local "hosts" file, then accesses to "localhost" could be redirected elsewhere -- but someone who can do that on your machine already owns it and could insert his own rogue CA in your trust store anyway.


I don't see any more significant threat for localhost than any other certificate. The main abuse of an SSL cert is to convince a system that you are the system they want to talk to when you are not, but an attacker couldn't compromise the traffic going to localhost unless the client computer is already compromised at a fairly low level (at least has access to modify the HOSTS file). At which point, the entire charade is unnecessary since they could simply install their own cert or do whatever else they want.

  • So would you agree that it's a reasonably safe thing to do?
    – artbristol
    Apr 29, 2013 at 13:14
  • I think it is safe, but not necessarily the best. What do you gain over a self-signed and locally trusted certificate produced on the developer's machine? Locally signed certs could also be used for the developer's machine name. For example, my development box has a self signed cert that is valid for both localhost and mymachine.mycompany.com and is only trusted on my machine since nobody else actually needs to trust it. Apr 29, 2013 at 13:24
  • All I'm trying to gain is a bit of build simplicity - when you run Firefox in WebDriver, it starts with a clean profile, which in our organisation already trusts the internal CA. I'd have to add a self-signed certificate by hand otherwise. But I like the idea of signing the developer's machine name, maybe I'll look into that.
    – artbristol
    Apr 29, 2013 at 13:31
  • @Artbristol - I'm trying to remember, does Firefox by default trust certificate's in the Windows Crypto API? It's reasonably easy to write automated code to create certificates and register them to the Crypto API. There is actually even a .Net Library for doing it on CodePlex (though the name eludes me at the moment unfortunately). Apr 29, 2013 at 13:51

There's almost no threat at all. Do you trust your own computer not to attempt an MITM attack against you? Then there ought to be no problem.

When you try to access localhost, the network adapter isn't even touched. If someone stole the key, the could use it to convince their own computer that it is itself. Or any computer that they have access to (if they have access to computers, however, you have a bigger problem since they can intercept the unencrypted data before it goes through TLS)

The only danger would be if your hosts file has been tampered with.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .