ADFS Token Signing/Decryption public/private CA?

  • Last Post 10 August 2015
ThomasVuylsteke posted this 07 August 2015

Hey All,   We’re getting ourselves ready for a round of certificate renewals on our ADFS infrastructure. In the past I’ve mostly read/used a public cert for service communications and private cert of token signing/decryption. As explained here:   Recommended CA issuers for a given certificate   I’m aware that the fact that they are self-signed, even when exchanged with another organisation isn’t much of a security issue. At least when the federation metadata exchange happens in a secure way. But I’ve seen ADFS 3.0 (2012 R2) validate the token signing certificate CRL stuff. And it can be disabled by using set-ADFSClaimsProviderTrust –SigningCertificateRevocationCheck ( )   Does the fact that this check is on by default suggests it’s advised to use public issues certs for token signing/decryption from now on?   Any thoughts?   Kind regards, Thomas      

Order By: Standard | Newest | Votes
joe posted this 07 August 2015

Self-signed certs generally aren't going to have revocation information published in them so won't be checked for revocation status even if this is enabled. As such, that probably isn't the piece to worry about.
My experience with revocation checking is that it can have performance impacts and if revocation status validation is not highly available from your ADFS servers, it may be unreliable. A thing to decide is whether or not your partners who are sending you signed tokens will rely on revocation publication as a mechanism to convey a breach or not. If they won't, that would beg the question as to why you'd elect to check it.
It may be a conversation you have with each claims provider as to how they wish to be treated regarding revocation status and then setting each claims provider manually.
Joe K.


ThomasVuylsteke posted this 10 August 2015

Hmz, good remark about self-signed not containing any CRL information. However when using an inhouse CA those certs will contain CRL information that is (typically)

not available externally.


But I get your point.

Thanks for the feedback!



joe posted this 10 August 2015

My very strong opinion is that internal PKIs have no place in ADFS deployments. External parties won't trust them and frequently won't be able to access important resources like OCSP, CRL and cert info endpoints. Given that ADFS is very much about establishing trust outside of organizational boundaries, either self-signed or publicly rooted certs are the way to go, depending on which certificate application in ADFS we are talking about (token signing, SSL, etc.).
Joe K.


KenHooveroxfordcomputergroupcom posted this 10 August 2015

IMO since the signing/decryption certs in ADFS are

never used by clients, it’s much easier to create those two certs as self-signed so there is no dependency on outside trust chains. 


Generating them yourself (I use makecert) also allows you to specify the bitlength and lifetime of these two certificates.  Ten years is a good lifetime,

for example, since it’s likely ADFS will be replaced by something completely different before the cert expires.  :-/


As you add RP’s to your ADFS setup over time, refreshing those two certs can become a major event – with lots of risk – if the applications don’t

properly process the metadata.


Changing the SSL (communications) cert is much easier and that must absolutely be something with a widely-accepted third-party trust chain for smooth



Ken Hoover



Ken Hoover



Ravi.Sabharanjak posted this 10 August 2015

instead of makecert, you can also use the below. I don't know if there is a way to set the bit length however

#This command has to

be run AFTER the farm is created, but before adding more servers -

#This sets the certificate validity of the token encryption and decryption certs to be 5 years. #(The default is 1 year). These certs are self-signed and generated automatically.Set-AdfsProperties

-CertificateDuration 1825


#Force a rollover of

the certificates -