Wednesday, December 23, 2009 11:38 PM
ADFS v2 RC and IIS certificates
In topic of ADFS Laura said once “If your ADFS is broken, it’s PKI. If it’s not PKI, you’ve got a typo. If it’s not a typo, it’s PKI”. Very true … in different aspects of PKI.
Because of Christmas break I have a bit more free time than usual, still taking under consideration free time which is available when I put my son to sleep. I decided to take a look at just released ADFSv2 RC bits. And I know that it is probably because of me but I managed to produce little problem during the setup procedure, which I think might affect also others so as always … time for blog post.
ADFSv2 and PKI requirements …
For those who have not gone through ADFSv2 setup procedure quick outline of its PKI requirements.
After ADFSv2 is installed as a service on machine next step is to configure it as federation server either standalone or part of a farm. Part of this setup is to provide information about certificate, which will be used as token signing certificate and card space signing certificate. This certificate has to be present in local system store for ADFS setup to be able to pick it up.
My setup …
In order to setup ADFS I’ve created a single machine on which I’ve loaded AD \ Certificate authority and IIS server (not best practice but in my lab I have to take care about available RAM and spindles so … less VMs is better).
To get certificate for my IIS server and later for ADFS service I’ve created cert request using IIS console and based on this request I’ve issued certificate from CA, installed it on my IIS and what *is important* I set this certificate to be used in HTTP binding on my IIS machine.
ADFS service setup and later procedure for configuring it as federation server went smooth and everything worked as it was expected. When I was asked which certificate to use I just choose certificate I’ve created earlier and configured for my IIS machine.
So where the problem begins?
Later I’ve decided that I want to setup my ADFS server using FQDN to avoid problems with SPNs configuration etc (BTW – I believe that after PKI and typos SPNs will be next common issue with ADFS v2 setup … I don’t know why … maybe it is called experience).
So I’ve added DNS record for new name, I’ve done all IIS stuff and among others I’ve revoked previous certificate and removed it from IIS configuration (just deleted it using IIS console), issued new request, new cert ... installed … done. Almost.
Next step is to change ADFS configuration to:
- use new FQDN (easy)
- use different certificate (should be easy).
First step was OK, but then when I wanted to change token signing certificate in ADFS i got error message which said something similar to:
The SSL certificate with thumbprint 42161585196B80292A675BA95D54429D1E1CF7CE is configured in IIS but could not be found in the Local Computer Personal certificate store. SSL Certificates configured in IIS must also be present in the Local Computer Personal certificate store in order for AD FS 2.0 to use them.
Thumbprint referred to certificate which I previously revoked and removed. Checked things few times … even if I was asked to select new certificate for ADFS to use, and I was ale to choose new certificate every attempt changed in way similar to described above.
Cause and solution …
After thinking about it for a while I’ve checked what certificate is assigned to HTTPS binding for IIS. And it turned out that there is no certificate … at least none was shown in UI. But apparently some reference to previously configured certificate was hold somewhere in IIS configuration and this was causing problem with ADFS configuration.
Once I selected new certificate to be also used for HTTP binding in IIS I was able to change signing certificate for ADFS and finish my setup.
So as it turned out:
- deleting certificate in IIS setup and replacing it with new one is not enough. Remember about *BINDINGS*.
- error messages are right but no always are pointing you directly in right place.
- “If your ADFS is broken, it’s PKI. If it’s not PKI, you’ve got a typo. If it’s not a typo, it’s PKI” … with addition of SPNs :).
Hope this will help at least one person in a future ;).
Update: through Laura's blog I found Juan Pablo entry on this problem with a bit different solution. Look at it here. I don't know if cause was the same but probably it will help even if not (I don't have same lab right now to check it). Worth to know.