Can a employee steal a company's SSL certificate private key?

Question

Is it possible to a rogue employee to just login in a company server and steal the private keys used to secure SSL connections? Is it as easy as copying a file?

(I've read some questions that the focus was what happens after a certificate was stolen. Here, I want to know how easy is to an insider get the private keys.)

Thanks.

Answer 1

Is it possible to a rogue employee to just login in a company server and steal the private keys used to secure SSL connections?

Yes, except when it's hard, or when it's impossible.

Is it as easy as copying a file?

This is where the gradation comes in. There are a wide variety of security levels, some of which I'll describe here from easy to hard:

1. In the easiest case, yes, the private key is a simple text (PEM) file, and may not even have proper file protections*

2. Or the key file might be stored with restrictive permissions. Now the employee not only needs to be on the server, he needs to have the appropriate (Administrator or application) privileges to copy the key.

3. The key file might be password protected but automated. This usually just means that in addition to the key file, the employee needs to find the config file with the password stored in it and steal that too. (See also "java keystore changeit"...)

4. The key file might be password protected and the key entered at runtime by a human operator. In this case, the password cannot simply be stolen from the system. Of course, your employee might be an operator... Also, in practical terms, very few servers are run to require human intervention upon restart.

5. If I recall correctly, IIS used to be able to import the key into a keystore that was not exportable by users, but would allow use by services. Such things can generally be worked around with enough privileges.

6. Finally, if a Hardware Security Module (HSM) is used, that is designed to protect the keys even from the Operating System itself, to allow their use via cryptographic operations without exposing the keys to the computer hardware and software. In this case, the employee will probably find the key impossible to steal.

Here, I want to know how easy is to an insider get the private keys.

It's going to depend on the site, but in general, my experience has been that most sites store the key with nothing more than file permissions to protect it. The general sense is "Well, if someone breaks into the server, they've already gotten everything, and we'll need to issue a new key anyway when we recover." Of course, this ignores

• the gap between compromise and discovery, and
• the potential use of a private key to quietly read traffic in the meantime.

The shift towards ephemeral TLS ciphers is slowly closing that second gap, rendering the private key far less useful (snooping is often more valuable than impersonation; impersonation can be achieved in other (possibly simpler) ways).

---

*C'mon, guys, don't pretend you haven't seen a dozen poorly secured Apache configurations where the keys were left world readable.

Answer 2

It might or it might not be. Keys can be stored in:

• Files in the filesystem of the servers that serve client requests. Cheaper, but less secure; as you point out, rogue employees can copy the file with the private key.
• In a hardware security module, which generates keys internally and doesn't allow external clients to read the private keys—it only performs cryptographic operations at the client's request. This is more secure, but much more expensive as well.

Also, there exist a safeguards in the form of:

1. Certificate chains: the front-end servers should preferably not have the "master" certificate, but rather a child certificate signed by the master.
2. Certificate revocation: if a certificate's private key is believed to have been compromised, it can be added to a certificate revocation list and publicized.
3. Certificate expiration: Certificates specify a date after which they should not be accepted. This guards against undetected disclosure by limiting the usefulness period of such a certificate.

Answer 3

If the company has rogue employees you have a problem. The employee should only have the rights, he really needs. And if he needs the rights to configure a server, he most likely has the right to read a private key file. Thus is an employee decides to go rogue, you have a problem. If it is this mission critical, you should implement two-man rules.

If you are using HSMs, there will be an employe, who is allowed to generate key pairs and backup private keys of an HSM. And if this employe is going rogue, he might be also able to fetch the backup of the priv key and all means to restore the backup (depending on the HSM used).

Again - this is a place to implement the right processes and two-man rules.