Just a quick post today on something that should be more simple than it is…
AD FS on Windows Server 2012 R2 (often referred to as “AD FS 3.0”) no longer has a dependency on IIS. One of the common methods used to generate a “Certificate Signing Request” (CSR) is to use IIS on the server you need the certificate on or by using another IIS server in the organization. Without access to IIS, your options for generating the CSR are to use the MMC snap-in, one of the native command line utilities or some third-party tools.
While there are a number of ways to generate your CSR, the method below is the one I find the easiest while also meeting current security requirements.
Requirements
There are two basic requirements when requesting a certificate for AD FS; some of the other methods for requesting a certificate such as using IIS or the MMC snap-in do not meet these requirements.
AD FS does not support Cryptography Next Generation (CNG) private keys. If you try to use a certificate with a CNG private key, you’ll be greeted with the error below during installation.
You will need to request a new certificate with a legacy private key.SHA-2
Over the next couple years, support for SHA-1 certificates will end. Expect to start seeing warnings after December 31, 2015 and support ending for SHA-1 after December 31, 2016. This means any certificates request from here forward should really use SHA-2.
If you try to use tools like the MMC snap-in, you’ll find odd restrictions like you can select legacy private keys but then can’t select SHA-2.
Quick and Easy
Here is an easy way to generate the CSR using the native CertReq.exe utility.
First, create a file called “request.inf” with the following content (customized to your organization):
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=sts.company.com,O=Company Name,L=Holly,S=Michigan,C=US"
Exportable = TRUE
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
HashAlgorithm = sha256
RequestType = PKCS10
FriendlyName = "sts.company.com (SHA2)"
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
If you need a Subject Alternative Name (SAN) such as “enterpriseregistration.company.com” because you’re using “Workplace Join” or if you need SANs for any other reason, check out “How to Request a Certificate With a Custom Subject Alternative Name“.
Now execute the following command on your primary AD FS server:
certreq.exe -new request.inf sts_company_com.reqAfter receiving the response back from your third-party Certificate Authority, run the following to complete the request:
certreq.exe -accept sts.company.com.crtFrom here, you can export out the certificate using the MMC snap-in and import it into your other AD FS servers and proxies.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
Question – when I install a new cert will it also force a new token-signing and token-decrypting cert to be generated? I’m concerned about causing an outage from this while I update our third parties with the new certificates.
Michael-
If you are using the self-signed certificate for token-signing/token-decryption, then there should be no impact when you update the public certificate.
Thanks
Joe