Because Active Directory Federation Services (AD FS) rely heavily on certificates, you’ll want the most straightforward SSL/TLS certificate as the Service Communications Certificate throughout your Active Directory Federation Services (AD FS) implementation.

Notice however, that I’m not recommending to use the strongest certificates for your Active Directory Federation Services (AD FS) implementation? You won’t hear me recommending to use certificates with the longest keylength available, the most impressive hashing algorithm or even the most advanced private key generation…

There’s a couple of reasons for that, and, in this series, I’ll try to give you a couple of best practices on the certificates to use as the Active Directory Federation Services (AD FS) Service Communication Certificate.

Let’s start with the hashing algorithm.

About hashing algorithms

Certificates in the world of Active Directory Federation Services (AD FS) allow you to make sure it is the Security Token Service (STS) you’re communicating with. You’ll encrypt the traffic towards the STS with the public certificate of the STS and since the STS is the only one with the corresponding private key, it is the only host that can decrypt the traffic.

This is adequate to protect data in transit, as long as there are no SSL vulnerabilities, no big possibilities for collisions and no downward compatibility in play to increase the possibility for collision attacks. With a collision attack, a private key could be used that may or may not be the real private key, but is a key that offers the same functionality as the private key; the ability to decrypt and encrypt traffic.

The stronger the hashing algorithms used, the harder it is to find a private key that collides and the harder it is to impersonate the Security Token Service (STS).

Available hashing algorithms

The world has seen a lot of hashing algorithms. MD5 and the likes are all considered unsafe these days. As Certification Authorities (CAs) don’t issue these certificates for SSL/TLS, we’ll leave them out of scope.

As far as hashing algorithms go today, you’ll stumble upon four distinct algorithms that are all part of the Secure Hash Algorithm (SHA) standard, designed by the NSA and standardized by NIST.

SHA-0

SHA0 is the original version of SHA, released in 1993. It is no longer in use, since it contains some alleged weaknesses. No-one in the industry uses this hashing algorithm.

SHA-1

The SHA-1 standard, released in 1995, replaced the SHA0 standard. SHA1 is the most widely used hashing algorithm. Microsoft states SHA-1 certificates account for 98% of certificates issued worldwide. It, too, has weaknesses.

SHA-2

SHA-2, the hashing algorithm that supersedes SHA1, was released as draft in 2001 and published in August 2002. It is significantly different to SHA1.

SHA-3

In 2012, following a long-running competition, NIST selected an additional algorithm, Keccak, for standardization under SHA-3.

Choosing the right hashing algorithm

With publicly trusted Certification Authorities (CAs), you can order a SSL/TLS certificate for a limited time period for which it is trusted, usually 1 or 2 years. This is known as the certificate lifetime. So, today, you can order a SSL/TLS certificate that has a certificate lifetime reaching as far as July 2017.

Why you can’t use SHA-3

Now, of course, you’d want to use SHA-3 for the Service Communications Certificate throughout your Active Directory Federation Services (AD FS) implementation. Unfortunately, Microsoft doesn’t support SHA-3 in Windows Server, yet.

Why you don’t want to use SHA-1

Since SHA-1 was designed and released in a time when CPU was costly, certificates using the SHA-1 algorithm offer more performance, when compared to SHA-2 certificates. However, SHA-1 has weaknesses. This is way the industry is moving away from SHA-1 certificates. This means, that even though you have perfectly valid certificates, browsers and Operating Systems will mark your SHA-1 certificates as invalid in a short period.

Certification Authorities (CAs) in the Windows Root Certificate Program offer certificates that are trusted (and thus deemed valid within the certificate lifetime) throughout the Microsoft ecosystem. These CAs are only allowed to issue certificates based on the SHA-2 hashing algorithm, starting January 1, 2016.  By January 1, 2017, all Microsoft products will no longer trust SHA1 certificates for SSL/TLS.

Google has stated that Chrome 39 will mark SHA-1 SSL/TLS certificates with an end date beyond January 1, 2017 as ‘secure, but minor issues’. This is represented by an icon consisting of a lock with a yellow triangle. For Chrome 40, these certificates will be marked ‘neutral, no security’. SHA-1 SSL/TLS certificates ending between June 1, 2016 and December 31, 2016 will be marked as ‘secure, but minor issues’. Chrome 41 SHA-1 certificates expiring after January 1, 2017 will be marked as ‘Affirmatively insecure, major errors’, represented by an icon consisting of a lock with a red X. As per Google’s own documentation, people using Chrome need to be hesitant to enter data in pages marked as ‘secure, but minor issues’ and ‘Affirmatively insecure, major errors’.

After January 1, 2016, Mozilla plans to show the “Untrusted Connection” error whenever a newly issued SHA-1 certificate is encountered in Firefox. After January 1, 2017, Mozilla plans to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox.

So, SHA-2?

If you want your SSL/TLS certificate to be trusted for its entire lifetime (beyond January 2017), you’ll want to order a certificate, based on the SHA-2 hashing algorithm. At the moment of writing, no collision attacks on these algorithms have been successful.

SHA-2 is the collective name for six hash algorithms: SHA-256, SHA-384 and SHA-512 were part of the FIPS BUB 180-2 NIST publication in August 2002. In August 2008, SHA-224 was added and published as FIPS BUB 180-3. In March 2012, as part of FIPS BUB 180-4, SHA512/224 and SHA512/256 were added.

From a performance point of view, SHA512-224 and SHA-256 offer great performance, but the same message digest size as SHA-224 and SHA-256. Microsoft does not support SHA-224.

Additionally, SHA-512 is not supported in AD FS 2.x as stated by Microsoft:

AD FS 2.0 does not support the use of certificates with other hash methods, such as MD5 (the default hash algorithm that is used with the Makecert.exe command-line tool). As a security best practice, we recommend that you use SHA-256 (which is set by default) for all signatures.

Furthermore, it’s no much use to use a stronger hashing algorithm than the hashing algorithms used by the Root Certification Authority (CA) and intermediate Certification Authorities (CAs). When you’re using a stronger algorithm, the CA could have its weaker private key collided and a new (stronger) certificate could be issued for a Man-in-the-Middle attack. Many CAs have certificates based on SHA-256, so using SHA-256 for the Service Communications Certificate throughout your Active Directory Federation Services (AD FS) implementation is more than adequate.

SHA-384 could be opted, but only when it doesn’t cost more and the CA issuing the certificate has plans to move their CAs to SHA-384 too.

Concluding

When requesting a certificate for the Service Communications Certificate throughout your Active Directory Federation Services (AD FS) implementation, opt for a certificate with the SHA-256 hashing algorithm.

DISCLAIMER SHA-1 Signatures

When you’re working with SHA-2 certificates, the thumbprint in the certificate properties will show SHA-1. In this case, your certificate will use the SHA-2 hashing algorithm.

The thumbprint is the hash of the entire certificate in binary DER format; it is not actually part of the certificate. The thumbprint is calculated by the Operating System and Windows uses SHA-1 by default, regardless of the signature algorithm on the certificate.

Further reading

SHA-256 Compatibility
Common Questions about SHA2 and Windows
Google ‘Sunsetting’ Weak SHA-1 Crypto Algorithm
SHA-1 Deprecation and Changing the Root CA’s Hash Algorithm
SHA1, SHA2 und Windows XP & Windows Server 2003