Ryfujk

I want to keep our SSL key for our website confidential. It's stored on 2 USB sticks, one in a safe deposit box and one I keep secure. And then I'm the only one who applies it to the web server so that it is totally secure.

Except...

On IIS at least, you can export the key. So anyone who's an admin can then get a copy of the key. Is there any way around this? Or by definition do all admins have full access to all keys?

Update:
I do have sysadmins I fully trust. What led to this is one of them quit (they had an hour commute to our company, a 5 minute commute to the new one). While I trust this individual, just as we disable their Active Directory account when someone leaves, I thought we should have a way to insure they don't retain the ability to use our SSL.

And what struck me as easiest is if I'm the only one who has it. Our cert expires in January so this was the time to change the practice if we could. Based on the answers it looks like we cannot.

So this leads to a new question - when someone who has access to the cert leaves, is it standard practice to get a new cert and have the existing one revoked. Or if the person who left is trustworthy, then do we continue with the cert we have?

A person with administrative (or often even physical) access to a server is going to be able to extract the private key. Whether through exporting, memory sniffing, or other such trickery.

Your administrators have access to the private keys of your web servers. Accept this as fact, and work around that. If your sysadmins aren't trustworthy, then you may need better sysadmins or at least fewer sysadmins with access to the web servers. If it's a matter of management security paranoia, then there may be a deeper issue regarding their ability to trust a sysadmin.

This isn't to say that you should just let everybody have access to the private key. There should always be a need for access before access is granted. With that in mind, are you going to take extreme measures to make sure that a sysadmin with full control of a website can not export the private key, but can still manipulate the website itself in any number of nearly untraceable ways? We're back to trust here, and I think that's the core of the problem that needs to be addressed.

When you import the key, you have the option of marking it as non-exportable. This will prevent you from using IIS or the certificate MMC to export it. At least, it makes it a little harder.

However, if they have an administrator account on the machine, or have physical access to it - they will still be able to get the key through other means.

This is where an "intermediate CA" can help.

The "Root CA" in this example below is one owned by an SSL company and not you.

You don't have direct control of keys created by the Root CA, so if a key signed by the Root CA gets compromised, you have to go through them to revoke it.

But:

Root CA (SSL company)

 |

 +-Intermediate CA (You)

   |

   +-Server Key for site

If you place another CA in the middle, and have your bought SSL certificate sign your own CA certificate instead of directly signing your server certificate, you can retain control of server certificates below and issue revocation certificates or do whatever else if things below it are compromised.

You keep the Intermediate CA private key to yourself and the admins don't need to see it.

You can also do this:

Root CA (SSL company)

 |

 +-Intermediate CA (You)

   |

   +-Server Key 1 for site

   +-Server Key 2 for site 

   +-Server Key 3 for site

You can prepare for compromise, and generate certificates ahead of time, so you can switch quickly in the event an individual key is revoked. Admins do not get keys for 2 or 3 until compromise of 1. You can put a notice on your site about this scheme, and this would also communicate to your admins that you are ready in the event of a compromise and that funny business on their end won't destroy your site.

There are many articles that suggest storing the private keys somewhere other than the server but those private keys are for code signing certificates. Imagine you have the keys on an offline computer that only you have access to, some software is written, you get the private key from offline server, sign the code and then you don't need the private key again until you need to sign some code again.

The best solution has always been, and will continue to be storing your key offline. How you do it is completely up to you (there are a few methods), just remember to keep it well guarded in an office safe or somewhere that it’s not easy for someone to pocket.

Read more at: https://www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/

In contrast, SSL certificates are for websites to enable HTTPS communication: The private key is needed during each and every handshake by the web server. Therefore, storing it offline will not work.