Heya! It has been a while, but the sun is out so I thought I’d share a gem of a find!
One of the longest running logistical headaches with certificates has been renewing them, and subsequently binding them in IIS. Client certificates aren’t a problem; a wee sprinkle of Group Policy, and all your certificates just automagically renew. However, when you throw server authentication couple with Subject Alternative Names into the mix, you lose the truly luxurious option of automatic renewal.
Following on from my previous blog here, I had jumped through the Microsoft hoops to get my nice shiny gold padlock and green bar.
However all was not delivered as expected!
Ever since I started tinkering with SSL and HTTPS, I have had an unnatural hankering to move over into Extended Validation. It sounded simple enough, as per these Microsoft articles here, here and here.
I do occasionally take the time to monitor the FSP logs, specifically for client deployment failures. I came across this little beauty of a problem:
Of course the error “Client deployment is waiting for client installation content from distributions points.” is erroneous. It’s a symptom of the problem, and can be ignored. I dug deeper, and looked at the ccmsetup.log. It was a sea of red, as per below:
Follow the White Rabbit.
…but now we’re starting to get somewhere. It’s not a “Distribution Points” issue at all; the client is complaining about certificate problems. Specifically: “Finding certificate by issuer chain returned error 80092004”, and if you read further down:
“There are no certificates in the ‘MY’ store”
Bingo! I checked the Personal Store on the affected PC, and it was empty. So now this isn’t a Config Manager issue per se, the machine isn’t even automatically enrolling. I tried to do this manually, and it too failed with the error:
Helpful. Thanks for that.
I checked the enrollment properties and found:
On the trail!
No policy ID! So the PC isn’t even talking to the enrollment point. I checked logs, nothing.
So I am a bit stuck. I suppose these things do happen! I have posted on TechNet and I’ll come back to this post later(tm)!
My final blog about this topic… and following on from here.
The CDP is up and running, and immediately clients are “happier”, insofar as a machine can be happy >_>
In order to confirm the certificates are picking up the CDP, they need to be reissued, as these changes will only affect certificates issued post change.
Firstly I viewed an existing certificate:
No reference to a HTTP source.
…and as you can see htere is no reference to a CDP at the bottom. I then manually renewed a certificate on my test PC, opened the certificate and confirmed the presence of a CDP.
…and now we have a publicly available CRL.
Le fin! Well sort of… now I have to deploy an updated certificate to several thousand PCs. Joy.
Following on from my earlier blog, I had managed to successfully publish the CRL to my web server. However, in order to verify everything is working, you should browse to the URL and access the .CRL files.
I could browse to the files, either with or without HTTPS:
…but I could not download them; I received a 404 error message. I did some digging and verified that I had set allowDoubleEscaping, and that the .CRL was specificed as a valid MIME type on the web server. I checked the IIS logs and they indicated this was a MIME type error. So what was wrong?
Well the clue is in the above screenshot! Both files are missing their .CRL extension. Verifying the MIME entries made me realise that the published CRL files were missing their .crl extension. Hence IIS did not have a valid MIME type to handle the files which resulted in the 404 error.
I manually added .CRL to one of the files and bingo, I could download the content. I then went back to the CA to review the previous work I had done, setting up the Certificate Distribution Point.
I found a glaring oversight:
I had missed the .CRL extension when creating the file location. I removed and added a new location, this time including the .CRL extension and I could now download the file via the website:
The final job is to confirm the new certificates contain the CDP. All done here!
I setup the website and folder as per this guide. I added the file and http entries to the properties of the Certificate Authority (CA), and tried to publish via the MMC console.
However I received an error when publishing:
Ya make me sad…
I reviewed what I had done and it seemed to match the guide. Then I noticed a discrepancy between what the guide said and what I was seeing on the properties of the CA. Namely, the file path was preceeded with “file://”. However the guide stated to type \\<server>\<share>
Unfortunately I’d taken this too literally… I added the correct location, prefixed with file:// and successfully published the CRL.
Publish my pretties, publish!!
The files were published, as per below:
Note the two files, one with a plus (the delta update) and one without (the full list). However everything was not yet still quite right! See my next blog for details!