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.
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!
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!