none
Using Code-Signing Cert with SHA256 Signature and Signature Hash Alogrithms in ADFS 1.x?

    Question

  • I have a client who implemented an ADFS 2.0 farm, initially for use with O365.  The third-party code-signing certificate uses SHA256 for the Signature Algorithm and SHA256rsa for the Signature Hash Algorithm.  My client now wants to federate with a relying party who still uses ADFS 1.x, which doesn't support SHA256 and SHA256rsa algorithms.  Has anyone else dealt with this situation and found a work-around?  Replacing the code-signing certificate with one that uses a different algorithm is not an option.

    Thank you.

    Ian Kahn
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    Thursday, September 12, 2013 12:58 PM

Answers

  • yes, you can (re-)enable encryption as needed without recreating the trust. However, if the relying party trust on adfsv2 is for ADFSv1 I would be surprised if you would want to use token encryption as ADFSv1 DOES NOT support it.

    For token encryption encryption to work you must have:

    * a token encryption cert+private key on the federation service of the RP

    * a token encryption cert+publich key on the RP trust for the RP which is configured on the IdP federation service

    * on the RP trust for the RP which is configured on the IdP federation service, token encryption must be enabled




    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    • Marked as answer by Ian Kahn Monday, September 23, 2013 5:33 PM
    Monday, September 23, 2013 5:29 PM

All replies

  • It's a bit kludgy, but you could certainly configure your existing ADFS2 farm as a claims provider to a new ADFS2 instance that uses a signing cert acceptable to the constrained RP.

    Steve Kradel, Zetetic LLC

    Thursday, September 12, 2013 5:42 PM
  • In ADFSv2 you can configure the RP for ADFSv1.x to use SHA1 instead of SHA256. You can do that through the GUI (one of the TABs) or through powershell. That will work.

    You do not need to change your certs to accomodate this


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Friday, September 13, 2013 5:40 AM
  • Jorge,

    On my client's end, we do have the relying party configured to use SHA-1, per the relying party's configuration instructions.  The relying party company is telling us that, because they are only on ADFS 1.x, they can't use our code-signing certificate that is encrypted with SHA256 because it isn't supported in ADFS 1.x.

    Thank you for the input.

    Ian Kahn
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    Friday, September 13, 2013 12:19 PM
  • Steve,

    As ADFS only allows one instance per forest with one active code-signing certificate per instance, and we've already got our instance and cert configured, how would we make that happen without standing up an entirely new forest?  That is too much effort for one "nice-to-have" from my client's perspective.

    Thank you for providing feedback and suggestions.

    Ian Kahn
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    Friday, September 13, 2013 12:22 PM
  • In the past I have configured ADFSv2 as and IdP for ADFSv1 without a problem. I configured the RP trust with SHA1 (done through GUI or PoSH) and I disabled Token/Claims encryption the RP trust (done through PoSH only). Token encryption is by default enabled on every RP trust and for ADFSv1 you need to disable it

    what's the error they are getting or experiencing?


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Friday, September 13, 2013 12:27 PM
  • Jorge,

    Is disabling Token/Claims encryption global or on a per RP trust basis?  My client has other RP trusts in place that need to remain encrypted (like O365 and the RP trust with their HR provider).

    Thanks.

    Ian Kahn
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    Friday, September 13, 2013 1:34 PM
  • per RP trust

    Get-ADFSRelyingPartyTrust -TargetName <trustname> | Set-ADFSRelyingPartyTrust -EncryptClaims $false


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Friday, September 13, 2013 2:09 PM
  • Jorge,

    Thanks for this information.  I'll run this solution by my client and the relying party and see if they are amenable to testing.  My client, due to their line of work, may be opposed to sending the token unencrypted, but at least this gives me something new to propose to them.

    Ian Kahn
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    Friday, September 13, 2013 2:22 PM
  • Steve,

    As ADFS only allows one instance per forest with one active code-signing certificate per instance, and we've already got our instance and cert configured, how would we make that happen without standing up an entirely new forest?  That is too much effort for one "nice-to-have" from my client's perspective.

    Thank you for providing feedback and suggestions.

    Ian Kahn
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    ADFS is not a per-forest or per-domain feature.  You can have as many instances of ADFS2 in the forest as you like--plus as many instances of other STSes like Thinktecture, Ping, Oracle, etc., etc.

    If the token-signing cert in your ADFS2 instance is genuinely unusable by the ADFS1 RP then it's time to set up a second, federated STS, as ADFS2 does not support varying the signing cert by RP.  WIF supports it, but I imagine the ADFS2 designers decided not to as it would make a mess of the federation metadata document...


    Steve Kradel, Zetetic LLC

    Friday, September 13, 2013 2:55 PM
  • Adfsv1 does not support token encryption and you cannot specify an token encryption cert!

    For Adfsv2 to send an encrypted token to adfsv1, token encryption must be enabled on the rp trust in adfsv2 that represents adfsv1 and a token encryption cert must be specified on the same rp trust. The token encryption cert on an rp trust is the public version of the cert to encrypt the token so that the receiver can decrypt it with its own private version.

    Remember that traffic is already encrypted by ssl (https)


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Friday, September 13, 2013 3:06 PM
  • Jorge, I have one follow-up item that I want to be sure of before continuing with my client.  If we decide later to re-encrypt the token before it gets passed to the client, can I simply run the PowerShell cmdlet above and change the Boolean "false" in "Set-ADFSRelyingPartyTrust -EncryptClaims $false" to a "true"?  Or is there some other mechanism, like rebuilding the RP trust, that I have to go through to re-enable encryption on the one RP trust?

    Thank you.

    Ian Kahn
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    Monday, September 23, 2013 5:07 PM
  • yes, you can (re-)enable encryption as needed without recreating the trust. However, if the relying party trust on adfsv2 is for ADFSv1 I would be surprised if you would want to use token encryption as ADFSv1 DOES NOT support it.

    For token encryption encryption to work you must have:

    * a token encryption cert+private key on the federation service of the RP

    * a token encryption cert+publich key on the RP trust for the RP which is configured on the IdP federation service

    * on the RP trust for the RP which is configured on the IdP federation service, token encryption must be enabled




    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    • Marked as answer by Ian Kahn Monday, September 23, 2013 5:33 PM
    Monday, September 23, 2013 5:29 PM
  • Jorge,

    Thanks for the confirmation.  The RP has a very short-term horizon for upgrading to ADFS 2.0.  They told us they'll likely require us to create a new RP trust and disable/delete the old one when they do so, but I'd like to be prepared if they decide we can just turn encryption back on and make some other modifications to the existing RP trust once they upgrade.

    I certainly appreciate your guidance through all this.  Thank you for your time and efforts.

    Ian Kahn
    Senior Consultant
    InfraScience, LLC
    Alpharetta, GA
    ikahn@infrascience.com

    Monday, September 23, 2013 5:33 PM