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.


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?

  • 5
    Even if the server you use didn't allow you to export it, it still has to be in memory and can thus be extracted. The only option I see is using a hardware crypto module, like a smartcard be three only one with the key, but anyone with physical access to the machine could steal it. You still can revoke it if it's stolen. Dec 9, 2014 at 17:46
  • 27
    If you can't trust your admins, you have an HR problem. Dec 9, 2014 at 18:04
  • 5
    Why did you copy the key to those USB media in the first place? The secret key used with SSL does not need to be in other places than the server where it is used. (It may of course be included in backup copies of the server, but it is less important to back up that key than the other data on the server, since you can always generate a new secret key and have it signed like you did with the old one.)
    – kasperd
    Dec 9, 2014 at 19:00
  • I'm not an expert in this area, but don't hardware encryprion modules exist that contain a key that stays inside them and only the signing requests go in and signatures come out? Soldering or gluing one into the server could be the solution.
    – matega
    Dec 10, 2014 at 8:33

4 Answers 4


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.

  • 2
    +1 for "Your administrators have access to the private keys of your web servers. Accept this as fact, and work around that". Questions to the effect of "How do I prevent people with admin rights from doing X?" indicate a deeper problem to me. Either too distrustful, or too lax in giving out admin rights.
    – Brandon
    Dec 10, 2014 at 13:33
  • 2
    I updated with why I asked. It's not a concern with the sysadmins, it's a desire to follow best practices. Dec 10, 2014 at 20:21

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.


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.

  • 1
    Wouldn't this cause SSL warnings for users for an untrusted CA?
    – ceejayoz
    Dec 10, 2014 at 14:59
  • 1
    I guess this would only work well if you can install the CA as a trusted cert on the user's browser, such as in a corporate intranet setting. I knew something was wrong with my brillant scheme. :(
    – LawrenceC
    Dec 10, 2014 at 15:43

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.