Setting up Azure ACS was fun. It’s so easy to get it up/running/connected to SharePoint and you have the instant satisfaction of using Microsoft/Google/Facebook accounts to login to SharePoint. Great success! Note: Microsoft only gives you the UPN claim..which is a unique ID so when users log in it looks gross. Google and Facebook are able to pull in a lot more claims..but Microsoft is more secure in that fashion I suppose.
Anyways there is great documentation out there already on how to get rocking and rolling. Here’s a few I’ve used:
Anyways there isn’t really much documentation out there on the Token Signing Certificate. Most of the documentation out there states to use a self-signed certificate for DEV and get a certificate from a Commercial Certificate Authority for PROD. Alrighty then. Here’s the screen in Azure
Not knowing too much in the ADFS token signing cert space (In the past most environments I have worked with use ADCS or PKI to generate these) I took to the interwebs.
The reason I was researching is because if I were to put in a CSR for acstenant.accesscontrol.windows.net I wouldn’t get it or it would get revoked…I don’t own windows.net. Companies like Comodo have a DCV (Domain Control Validation) questionnaire built right into the certificate purchasing process. For the self-signed cert you can use whatever you want.
I researched to see if Azure ACS could have a friendly name or DNS CName that we could pull the cert for. NOOPE!
I found a great tool by Steve Peschka that allows you to actually export the token signing certificate right out of ACS. The ACS tenant is actually already an HTTPS site so there is a preexisting cert. SWEEET! It works like a charm too..
This specific client had their heart set on using the commercial certificate authority so I kept trucking.
The certificate for ACS is described in detail here: https://msdn.microsoft.com/en-us/library/gg185932.aspx
Alright I’m still not sure what subject name to use..until I found this forum post: https://social.msdn.microsoft.com/Forums/vstudio/en-US/0dc942cd-ced1-4d09-9f10-73e325c241a9/adfs-installation-and-token-signning-certficate?forum=Geneva
Frank Lesniak had the answer I was looking for (This was for ADFS, but still applied to ACS):
**I’m just copying his answer in here in case the forum post ever gets deleted
- The certificate’s key length should be at least 2048 bits.
- Validity period should be as long as possible (given cost), up to 5 years
- The signing algorithm should be either SHA-1 or SHA-256. If you need to support ADFS 1.x legacy federation, Windows 2000, Windows XP SP2, or Windows Server 2003, use SHA-1. Otherwise, for best security, use SHA-256. You may need to call your publically-trusted certificate issuer to validate the signing algorithm.
- Ensure that the private key is exportable
- Subject name does not matter… but something like adfstoken.yourdomainname.com would be a common implementation.
- Key usage does not matter.
The key points being #5 and #6 – ADFS does not care what you name the certificate or what kind of certificate is being used (i.e. code signing, server authentication, client authentication, etc.). My advice would be to generate a certificate however you’d normally feel comfortable doing so. For example, many of my clients use IIS to generate the certificate signing request (CSR), then submit the CSR to the commercial CA. Once you’ve loaded the certificate into the computer store, it should be available for AD FS to use.
In summary – It doesn’t matter! Use acstoken.yourdomain.com or if you’re already rocking a wildcard cert for everything use that. Any X.509 certificate will do…