3

I'm using openssl on linux to generate a certificate signing request (CSR) that will be submitted to a Windows Certificate Services Certification Authority that has been configured to archive private keys.

Unfortunately, I can't figure out how to use openssl to generate a CSR that includes the private key so that the CA can both issue my cert and archive the private key.

Edit: Based on this Microsoft Documentation, it looks like what I'm trying to do is generate a CSR using the CMC format, which is what allows the private key to "go along" with the request for archival.

From that link:

One of the formats the certificate request uses is the CMC format for certificate requests, which supports an optional encrypted data payload. This is the format required for certificate requests with private key archival. Technically, any client that supports the CMC protocol may enroll with an Enterprise CA and request that the private key be archived by the CA.

Yet More Findings:

The combination of these two links (one, two) is how you would do it using Microsoft's certreq utility. I've tested it and it works. I'd like to do this with openssl, if possible.

John Ruiz
  • 323
  • 1
  • 4
  • 9
  • Just out of curiosity, What are you doing on Linux that would make you need to recover the keys? – Zoredache Aug 26 '13 at 23:24
  • Installing a service that encrypts data that MUST be retrievable, even if the private key is lost because the hard disk catches on fire. The service is not under my control. I can tell the service provider to make sure they backup their private key somewhere safe, but if they don't, and something happens, I must be able to retrieve the encrypted files. The only solution I know of for this is key archival. – John Ruiz Aug 26 '13 at 23:56
  • 1
    I just put private keys in a safe deposit box. – Michael Hampton Aug 27 '13 at 00:04
  • Unless it's [this safe deposit box](http://www.youtube.com/watch?v=Fdjf4lMmiiI), Uncle Sam isn't having that. – John Ruiz Aug 27 '13 at 00:13
  • 1
    But before you put the private keys in a safe deposit box, you must retrieve them. That's easy enough, but I think that John is really looking for a way to automate that retrieval so his team doesn't need to go in and grab each key every single time or doesn't need to rely on the user to deliver the private key. – Stefan Lasiewski Aug 27 '13 at 00:43
  • I don't have an answer, but I do see that rfc5272 talks about 'shrouding' the private key using [EnvelopedData](http://tools.ietf.org/html/rfc5272#section-3.2.1.3.3): _ EnvelopedData can also be used to wrap private key material for key archival. _ A few more keywords might help you in your search. If it's in an RFC, how bad can it be, right? – Stefan Lasiewski Aug 27 '13 at 00:50
  • It looks like [this is a start](http://sourceforge.net/apps/mediawiki/cmpforopenssl/index.php?title=Main_Page), but it's not mature enough to be included in openssl yet. Also, it doesn't yet cover the CMC portion, unless I'm mistaken. – John Ruiz Aug 27 '13 at 00:56

1 Answers1

6

Stop. You're doing it wrong.

A private key is called private for a reason. It is private. It is not to be shared with any third party, not even a certificate authority. It does not need it to sign the CSR and has no business whatsoever knowing it.

Dennis Kaarsemaker
  • 19,277
  • 2
  • 44
  • 70
  • 1
    That's a cute notion, but in a real PKI environment, users are going to lose their private keys. If there's no mechanism for key recovery, any encrypted data will be permanently lost. That's why Microsoft includes the feature in AD CS.http://social.technet.microsoft.com/wiki/contents/articles/7573.active-directory-certificate-services-pki-key-archival-and-management.aspx – John Ruiz Aug 26 '13 at 21:31
  • 1
    Oh wow, that's incredibly broken. In a real,secure, PKI environment, it's easy to generate and enroll a new key. Not to completely undo the benefits of asymmetric cryptography by storing private keys centrally... And valuable data is backed up. By sysadmins who don't lose their private keys. – Dennis Kaarsemaker Aug 26 '13 at 21:37
  • 1
    Remember that PKI is as much (or more) about policy than technology. Just because I generate and enroll a new key doesn't mean that my users will be able to use that to get at data encrypted with their old key. Moreover, I work in a non-commercial environment in which designated key recovery agents must be able to recover keys and information in the event that - say - an end-user is... no longer available? A SRS business PKI environment, where it's security for the overall environment, not security for the end-user. – John Ruiz Aug 26 '13 at 21:43
  • 1
    That's why good sysadmins do not rely on users. Users will lose their data, encrypted or not. So you make backups. – Dennis Kaarsemaker Aug 26 '13 at 21:50
  • Dennis, I live in a completely different/unique world where the backups are also encrypted with the users' private keys, so I still have the same problem. – John Ruiz Aug 26 '13 at 21:54
  • 4
    Now how does that improve "security for the overall environment, not security for the end-user"? Fix your backups and you won't need to do asymmetric encryption wrong. – Dennis Kaarsemaker Aug 26 '13 at 21:57
  • 1
    I agree, and upvoted, the 'you're doing it wrong' - nobody should send an unencrypted private key to a third party - but **if I read that Microsoft documentation correctly**, the private key would be encrypted. Essentially the CA is acting as an offsite backup. – mikemaccana Feb 20 '15 at 11:15