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: https://technet.microsoft.com/en-us/library/dd807040.aspx 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 (https://technet.microsoft.com/en-us/library/ee892351.aspx ) 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
ADFS Token Signing/Decryption public/private CA?
- 189 Views
- Last Post 10 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.
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!
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.).
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
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
#Force a rollover of
the certificates -