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.

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

 

 

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:

Huzahh!

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

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:

Better!

The final job is to confirm the new certificates contain the CDP. All done here!

Certificate Revocation Lists and Your Config Manager Client

I wrote quite a few posts this month, and made a mental promise to stop. Consequently I now have about a dozen drafts waiting to go up; it’s like a maelstrom of IT poop in my head at the moment. However I thought it would be better to stagger them rather than just dumping all out in one messy go.

Unfortunately I couldn’t resist this one!

I’ve been having a problem getting my internet based clients to talk to my internet facing Management Point (MP). So much so that I backed off and focussed on migrating the Reporting Point to HTTPS, Distribution Point to HTTPS, Management Point to HTTPS, creating an Application Catalogue and prepping for Out of Band Management. Pretty much anything which avoids the existing problem.

Well my boss asked me for an update to the internet facing stuff and we had a bit of a barny. Okay it’s a sore point for me… and we’re all overworked; these things happen. so I went back to my logs and found these wonderful errors:

CCMMESSAGING:
Post to https:///ccm_system/request failed with 0x87d00231

LOCATIONSERVICES:
Unable to retrieve AD site membership
Failed to send management point list Location Request Message to internetFQDN
LSUpdateInternetManagementPoints: Failed to retrieve internet MPs from MP internetFQDN with error 0x87d00231, retaining previous list.
There is no AMP for site code ‘XXX’. Nulling existing entry in WMI
LSUpdateInternetManagementPoints: Failed to retrieve internet MPs from MP internetFQDN with error 0x87d00231

INTERNETPROXY (although none is set?)
Failed to get proxy for url ‘https://internetFQDN/bgb/handler.ashx?RequestType=LogIn’. Error 0x87d00215
Failed to get proxy for url ‘https://internetFQDN/ccm_system/request’. Error 0x87d00215
Failed to get proxy for url ‘https://internetFQDN/SMS_MP/.sms_aut?SITESIGNCERT’. Error 0x87d00215
Failed to get proxy for url ‘https://internetFQDN/SMS_MP/.sms_aut?MPLIST2&EX2’. Error 0x87d00215

I tried disabling the requirement for a CRL on the Config Manager site, but this had no obvious effect. It’s not working externally. However everything works fine internally. I wasn’t sure if it was the IIS certificate, issues with the IIS certificate SANs I specified here, incorrectly setting the Trusted Root CA on the site…. or any combination thereof.

Unfortunately 0x87d00231 is yet another generic “oops something went wrong” error code and covers a variety of topics.

It turned out to be something I’d missed, although in my defence I did not setup the Certificate Authority. When it was first setup, a Certificate Revocation List was not configured. The CDP information was left at its defaults. This might also explain why workgroup clients/Linux/Macs were having a problem reading my signed email (lol suckers – it’s not that I don’t care… I just… don’t… er… worry about them?).

So I dived in and read the documentation about CDPs and CRLs. I did find it heavy going, but I did the following:

• Created a website on an internet facing server (created a new Virtual Directory (VD).
• Configured said website to allow directory transversal
• Configured said website to allow doublebackslashescaping
• Configured the physical folder/share to allow the CA computer account in with read and write access. Naturally I hid the share xD

Next, I configured the Certificate Authority. I did the following:

• Configured the HTTP location
• Configured the file share location

The screenshots show the changes I made:

HTTP location for the CDP

Note the two “include” options are also ticked, in the above screenshot. Make sure you tick ’em!

File share information for the CA to send the CRL

Note the two “publish” options are also ticked but the two includes are *not*, in the above screenshot.

The file share path is now set, for the CRL files to be transferred automatically. Note the string is prefixed with “file://\\”. Also note the two publish options are ticked.

In both instances I inserted <cCaName>, <CRLNameSUffix> and <DeltaCRLAllowed>. You must terminate the string with .CRL. If you don’t, IIS won’t know how to handle the file, as it will be an unknown MIME type, and generate a 404 error as per my post here.

Now for the really satisfying bit! I booted up a laptop at home the next day and the logs started behaving differently:

Name: ” HTTPS: ‘Y’ ForestTrust: ‘N’
LSUpdateInternetManagementPoints: Successfully refreshed internet MPs from MP .
There is no AMP for site code ”. Nulling existing entry in WMI
Persisted Default Management Point Locations locally
Unable to retrieve AD site membership
Calling back with the following WSUS locations
WSUS Path=’https://:8531&#8242;, Server=”, Version=’1386′

and:

>>> Client selected the PKI Certificate [Thumbprint *snip*] issued to ‘clientFQDN
Client’s current MP is https://<internetFQDN&gt; and is accessible
MP check succeeded

The PKI documentation states that you need to redeploy the certificate after adding in the CDP changes, and indeed the existing issued certificates make no reference to the HTTP location. Newly issued certificates do. However my home laptop has not received the updated certificate with the CDP information, yet it is now working. The screenshots below show the existing certificate:

No reference to a HTTP source.

…and a freshly issued certificate with the extra CDP information tagged on:

…and now the certificates are aware of the CDP!

I am torn between two lines of thought. It’s down to the “No CRL checking” option being set on the Config Manager site server; whilst this may bypass some CRL “stuff”, it’s needed for to get other things going. Or it’s another Timey Wimey Wibbly Wobbly effect. I’ll test it further by enabling CRL checking on the site server and blog back. In the mean time…

Yeah baby.