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.
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)!
Following on from the WSUS/SUP rebuild I blogged about here, I noticed that all SCUP updates in Config Manager were flagged up with a grey cross. All except the most recent Adobe reader/ acrobat/flash which were in the monthly test cycle.
I downloaded all the updates and everything seemed to be fine.
However reports started to float in for reader/acrobat/flash failing to install, with error code 0x80091007. The failures were only limited to the very latest updates, which were now live. The older SCUP updates installed fine.
Uh oh… too much of a coincidence here.
I tried removing the affected updates from the SUGs and deleting them from the package; I published and resigned the updates but this had no affect. I then deleted the updates from SCUP and removed the catalogue; next I imported the library from Adobe but interestingly the updates were now marked as expired. I duplicated them and tagged as MKII. and published into the WSUS catalogue.
This now worked… the affected updates, or rather the MKII versions, now installed without any errors. Strangely the original updates are flagged as not expired but if I attempted to publish them, it would error stating they are expired.
The root cause? I’m not sure but I am going to suggest that having them in multiple SUGs as part of the monthly testing and rollout ended up with them being stuck in our WSUS catalogue signed with the old self-signed certificate. It is very odd how it only affected these three… Maybe I missed the initial clear out but it’s strange that from the word go they had a green icon instead of the grey cross like other SCUP updates.
Anyway, prodigious use of duplicate and “MKII” saved the day 😛
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!