Tag Archives: Internet facing

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


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!

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:

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

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&#8217;. Error 0x87d00215
Failed to get proxy for url ‘https://internetFQDN/ccm_system/request&#8217;. Error 0x87d00215
Failed to get proxy for url ‘https://internetFQDN/SMS_MP/.sms_aut?SITESIGNCERT&#8217;. Error 0x87d00215
Failed to get proxy for url ‘https://internetFQDN/SMS_MP/.sms_aut?MPLIST2&EX2&#8217;. 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

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

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′


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

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!

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

Yeah baby.


Internet Facing Management Point

I’ve already covered the certificate creation, and use for the intranet web servers. This post is about setting up the Management Point on an existing server and configuring the Site System for internet access.

I have already requested the internet FQDN to be registered on a public DNS, and had port 443 opened on the firewall.

I requested the certificate and configured the SANs for both DNS internet and intranet FQDNs, like so:

Herping your certificate derp.

Herping your certificate derp.

I bound this to the IIS default website as HTTPS port 443. Easy!

Next up, I installed the Management Point (MP) role. Whilst i was on, I set the internet FQDN and configured it for both internet and intranet traffic; it is absolutely imperative that the specified internet FQN matches:

  • Publicly registered DNS name
  • The SAN specified on the certificate

Now I configured the MP for HTTPS and let it install. The server already acts as a Distribution Point (DP), so I didn’t need to adjust anything else in IIS in terms of features or roles.

However the SMS_MP_CONTROL MANAGER component started reporting errors. I drilled into the logs and found the following error “MP Control Manager detected management point is not responding to HTTP requests”.

Why must you taunt me?

Why must you taunt me?

I did some googling, but I couldn’t anything specific. It’s seemingly one of those generic codes… For some reason, I hit on the idea of adding the certificate I created for Config Manager clients, as the error in the logs did reference authentication. I gave the SMS_Executive a kick, and voilá:



…and now the MP is happy and running with SSL enabled. It’s communicating on port 443 with code 200.