locked
Export Private Key of ADFS Self-signed Token Signing certificate RRS feed

  • Question

  • Hi all,

    I'm running on the following issue. I'm rebuilding an exact copy of an existing ADFS farm. I've already exported the original ADFS WID Database which I can use at the "new" ADFS farm copy.

    I also want to reuse the existing Token Signing and Token Decrypting certificates. Those are the self-signed certificates ADFS generated itself during initial setup. I assume I have to export those certificates and reimport them somehow in my "new" ADFS Farm copy.

    Question 1: Is this right? Or is it enough to copy the whole WID Database and can I forget about the TS/TD certificates?

    If question 1 is yes:

    How do I export the Certificates? I can go to the ADFS 2.0 Management console, but I only have the option to export the public key. Regarding diffrent articles I should get the option wether or not to export the private key, but it doesn't. I'm Local Admin on the ADFS servers.

    Replacing the TS/TD certs(thus downtime) with new one's isn't an option.

    Kind regards,

    Robin Gaal


    Find me on linkedin: http://nl.linkedin.com/in/tranet



    • Edited by Robin Gaal Wednesday, May 1, 2013 12:04 PM
    Wednesday, May 1, 2013 12:02 PM

Answers

  • The problem is solved, I connected my "copy" to the existing old farm which pulled in the old Token Signing Private certs from *somewhere*(I still suspect the AD container). After that I copied the SQL config DB and connected the "new" farm to the new copy of the SQL DB.

    This way I copied my existing farm without having to export the private keys from the original one, which was kinda impossible.


    Find me on linkedin: http://nl.linkedin.com/in/tranet

    • Marked as answer by Robin Gaal Friday, May 3, 2013 1:17 PM
    Friday, May 3, 2013 9:47 AM

All replies

  • Well, the keys, or something related to the keys, is stashed in Active Directory (see CN=ADFS,CN=Microsoft,CN=Program Data,DC=your,DC=domain with an administrator account), but I don't think there is any supported way to export, import, or interact with the key data.

    If I had to guess, most likely the private keys are encrypted values in WID or MSSQL, and these AD objects' 256-bit jpegPhoto values are symmetric keys to decrypt them.  You'd have to dig around to figure out which one is for signing vs. encryption in both environments.  Since there are only two, maybe trial and error is good enough.  Again, this all presumes you don't care about having a supported configuration.


    Steve Kradel, Zetetic LLC

    Wednesday, May 1, 2013 3:42 PM
  • I spent some time poking around in this area a while back but didn't come up with anything concrete.

    The certificate container seems to be related to when you specify certificate rollover. Every time my certificates rollover, there are another two entries.

    Wednesday, May 1, 2013 6:59 PM
  • I've browsed through the WID DB but there is not much going on there except for the RP/CP/claim configurations. Noticed a funny thing though, it almost looks like ADFS makes a hidden RP for the ADFS proxy.

    What is the reason exporting the private keys is almost impossible?


    Find me on linkedin: http://nl.linkedin.com/in/tranet

    Thursday, May 2, 2013 6:42 AM
  • What's also interesting is if it's a third-party certificate registered for token-signing, these can be exported through the UI directly (assuming private key is marked as exportable). This problem seems to be limited to self-signed certs generated by AD FS.

    Regards,

    Mylo

    Thursday, May 2, 2013 9:24 AM
  • Yes I also noted that. The ScopeSigningCertificate table in the AdfsConfiguration.mdf looks interessting. Could this be the private keys?

    Find me on linkedin: http://nl.linkedin.com/in/tranet

    Thursday, May 2, 2013 9:35 AM
  • I came till the conclusion the WID/SQL DB stores nothing regarding the private keys. Best guess is the AD container.

    Find me on linkedin: http://nl.linkedin.com/in/tranet

    Thursday, May 2, 2013 11:36 AM
  • The problem is solved, I connected my "copy" to the existing old farm which pulled in the old Token Signing Private certs from *somewhere*(I still suspect the AD container). After that I copied the SQL config DB and connected the "new" farm to the new copy of the SQL DB.

    This way I copied my existing farm without having to export the private keys from the original one, which was kinda impossible.


    Find me on linkedin: http://nl.linkedin.com/in/tranet

    • Marked as answer by Robin Gaal Friday, May 3, 2013 1:17 PM
    Friday, May 3, 2013 9:47 AM
  • Well, you could have done that in the first place...

    I took a quick look around and found the self-signed certs in the database at IdentityServerPolicy.ServiceSettings.ServiceSettingsData, which is a medium-large XML document.  Within it are EncryptedPfx attributes.  I didn't delve into EncryptedPfx too thoroughly, but it appears to contain a little bit of structure, in addition to the payload which is no doubt symmetrically encrypted with the keys held in AD.


    Steve Kradel, Zetetic LLC

    Friday, May 3, 2013 5:33 PM
  • True, but the new farm has to be in the same domain to do this. I was curious if it was possible to actually export the private keys out of ADFS instead of copying them "beneath the surface" to another farm.


    Find me on linkedin: http://nl.linkedin.com/in/tranet

    Tuesday, May 7, 2013 12:00 PM
  • Apologies for resurrecting an ancient post but there's a good article on how the rollover certificates are stored:

    The use of Distributed Key Manager (DKM) in Active Directory Federation Services (AD FS).

    Thursday, May 5, 2016 7:08 PM