Tag Archives: PKI certificate

IIS 8.5 – Certificate Rebind

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.

Continue reading


Extended Validation – Part Deux

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!

Continue reading

SCUP and a PKI Certificate – SCUP Headache NUmber 2!

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 πŸ˜›

Creating the Certificate Revocation List – Part 3.

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.

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.

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



Creating the Certificate Revocation List – Part 2.

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:

*deep sigh*

*deep sigh*

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!

Creating the Certificate Revocation List

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

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

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!