How do I keep the ssl key for our website confidential?What is a Pem file and how does it differ from other...
Is there a low-level alternative to Animate Objects?
I am on the US no-fly list. What can I do in order to be allowed on flights which go through US airspace?
Why zero tolerance on nudity in space?
The change directory (cd) command is not working with a USB drive
Compare four integers, return word based on maximum
It took me a lot of time to make this, pls like. (YouTube Comments #1)
Avoiding unpacking an array when altering its dimension
What is a term for a function that when called repeatedly, has the same effect as calling once?
What's the purpose of these copper coils with resistors inside them in A Yamaha RX-V396RDS amplifier?
Make me a metasequence
Borrowing Characters
What can I substitute for soda pop in a sweet pork recipe?
Easy code troubleshooting in wordpress
Is there any relevance to Thor getting his hair cut other than comedic value?
Logistics of a hovering watercraft in a fantasy setting
Sometimes a banana is just a banana
Should I choose Itemized or Standard deduction?
You'll find me clean when something is full
Which aircraft had such a luxurious-looking navigator's station?
How would we write a misogynistic character without offending people?
chrony vs. systemd-timesyncd – What are the differences and use cases as NTP clients?
Accessing something inside the object when you don't know the key
How can atoms be electrically neutral when there is a difference in the positions of the charges?
What to do when being responsible for data protection in your lab, yet advice is ignored?
How do I keep the ssl key for our website confidential?
What is a Pem file and how does it differ from other OpenSSL Generated Key File Formats?SSL Cert VendorsHow can I renew SSL on IIS7 with No Downtime?IIS7: How to import public key and private key as two seperate files?How to trust my own self-signed SSL cert?Many web servers, one SSL certificate, IIS 7How do I clear Chrome's SSL cache?SSL 2048-bit certs, how to upgrade our web app without breaking legacy API customers?Https for embedded devices, local addressesVendor asking for SSL certificates for an internal API
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?
ssl certificate iis
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
migrated from security.stackexchange.com Dec 9 '14 at 18:01
This question came from our site for information security professionals.
add a comment |
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?
ssl certificate iis
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
migrated from security.stackexchange.com Dec 9 '14 at 18:01
This question came from our site for information security professionals.
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.
– user2313067
Dec 9 '14 at 17:46
27
If you can't trust your admins, you have an HR problem.
– Michael Hampton♦
Dec 9 '14 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 '14 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 '14 at 8:33
add a comment |
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?
ssl certificate iis
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
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?
ssl certificate iis
ssl certificate iis
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
edited Dec 10 '14 at 16:52
David Thielen
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
asked Dec 9 '14 at 17:09
David ThielenDavid Thielen
1709
1709
migrated from security.stackexchange.com Dec 9 '14 at 18:01
This question came from our site for information security professionals.
migrated from security.stackexchange.com Dec 9 '14 at 18:01
This question came from our site for information security professionals.
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.
– user2313067
Dec 9 '14 at 17:46
27
If you can't trust your admins, you have an HR problem.
– Michael Hampton♦
Dec 9 '14 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 '14 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 '14 at 8:33
add a comment |
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.
– user2313067
Dec 9 '14 at 17:46
27
If you can't trust your admins, you have an HR problem.
– Michael Hampton♦
Dec 9 '14 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 '14 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 '14 at 8:33
5
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.
– user2313067
Dec 9 '14 at 17:46
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.
– user2313067
Dec 9 '14 at 17:46
27
27
If you can't trust your admins, you have an HR problem.
– Michael Hampton♦
Dec 9 '14 at 18:04
If you can't trust your admins, you have an HR problem.
– Michael Hampton♦
Dec 9 '14 at 18:04
5
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 '14 at 19:00
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 '14 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 '14 at 8:33
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 '14 at 8:33
add a comment |
4 Answers
4
active
oldest
votes
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.
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
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 '14 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.
– David Thielen
Dec 10 '14 at 20:21
add a comment |
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.
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
1
It really isn't that much harder. isecpartners.com/tools/application-security/jailbreak.aspx
– Greg Askew
Dec 10 '14 at 13:20
add a comment |
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.
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
1
Wouldn't this cause SSL warnings for users for an untrusted CA?
– ceejayoz
Dec 10 '14 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 '14 at 15:43
add a comment |
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.
answered 4 hours ago
CodingYoshiCodingYoshi
1163
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f650339%2fhow-do-i-keep-the-ssl-key-for-our-website-confidential%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
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 '14 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.
– David Thielen
Dec 10 '14 at 20:21
add a comment |
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.
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
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 '14 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.
– David Thielen
Dec 10 '14 at 20:21
add a comment |
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.
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
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.
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
answered Dec 9 '14 at 18:17
HyppyHyppy
14.4k12857
14.4k12857
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 '14 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.
– David Thielen
Dec 10 '14 at 20:21
add a comment |
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 '14 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.
– David Thielen
Dec 10 '14 at 20:21
2
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 '14 at 13:33
+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 '14 at 13:33
2
2
I updated with why I asked. It's not a concern with the sysadmins, it's a desire to follow best practices.
– David Thielen
Dec 10 '14 at 20:21
I updated with why I asked. It's not a concern with the sysadmins, it's a desire to follow best practices.
– David Thielen
Dec 10 '14 at 20:21
add a comment |
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.
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
1
It really isn't that much harder. isecpartners.com/tools/application-security/jailbreak.aspx
– Greg Askew
Dec 10 '14 at 13:20
add a comment |
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.
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
1
It really isn't that much harder. isecpartners.com/tools/application-security/jailbreak.aspx
– Greg Askew
Dec 10 '14 at 13:20
add a comment |
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.
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
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.
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
answered Dec 9 '14 at 18:25
GrantGrant
14k104990
14k104990
1
It really isn't that much harder. isecpartners.com/tools/application-security/jailbreak.aspx
– Greg Askew
Dec 10 '14 at 13:20
add a comment |
1
It really isn't that much harder. isecpartners.com/tools/application-security/jailbreak.aspx
– Greg Askew
Dec 10 '14 at 13:20
1
1
It really isn't that much harder. isecpartners.com/tools/application-security/jailbreak.aspx
– Greg Askew
Dec 10 '14 at 13:20
It really isn't that much harder. isecpartners.com/tools/application-security/jailbreak.aspx
– Greg Askew
Dec 10 '14 at 13:20
add a comment |
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.
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
1
Wouldn't this cause SSL warnings for users for an untrusted CA?
– ceejayoz
Dec 10 '14 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 '14 at 15:43
add a comment |
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.
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
1
Wouldn't this cause SSL warnings for users for an untrusted CA?
– ceejayoz
Dec 10 '14 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 '14 at 15:43
add a comment |
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.
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
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.
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
answered Dec 10 '14 at 13:12
LawrenceCLawrenceC
1,057612
1,057612
1
Wouldn't this cause SSL warnings for users for an untrusted CA?
– ceejayoz
Dec 10 '14 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 '14 at 15:43
add a comment |
1
Wouldn't this cause SSL warnings for users for an untrusted CA?
– ceejayoz
Dec 10 '14 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 '14 at 15:43
1
1
Wouldn't this cause SSL warnings for users for an untrusted CA?
– ceejayoz
Dec 10 '14 at 14:59
Wouldn't this cause SSL warnings for users for an untrusted CA?
– ceejayoz
Dec 10 '14 at 14:59
1
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 '14 at 15:43
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 '14 at 15:43
add a comment |
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.
answered 4 hours ago
CodingYoshiCodingYoshi
1163
add a comment |
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.
answered 4 hours ago
CodingYoshiCodingYoshi
1163
add a comment |
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.
answered 4 hours ago
CodingYoshiCodingYoshi
1163
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.
answered 4 hours ago
CodingYoshiCodingYoshi
1163
answered 4 hours ago
CodingYoshiCodingYoshi
1163
answered 4 hours ago
CodingYoshiCodingYoshi
1163
answered 4 hours ago
CodingYoshiCodingYoshi
1163
1163
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f650339%2fhow-do-i-keep-the-ssl-key-for-our-website-confidential%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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.
– user2313067
Dec 9 '14 at 17:46
27
If you can't trust your admins, you have an HR problem.
– Michael Hampton♦
Dec 9 '14 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 '14 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 '14 at 8:33