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 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:
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.
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!
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’. 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:
Note the two “include” options are also ticked, in the above screenshot. Make sure you tick ’em!
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′, Server=”, Version=’1386′
>>> Client selected the PKI Certificate [Thumbprint *snip*] issued to ‘clientFQDN
Client’s current MP is https://<internetFQDN> 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:
…and a freshly issued certificate with the extra CDP information tagged on:
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…
Part of the joy of flipping that HTTPS switch on the site is watching as your site’s clients gradually start communicating over HTTPS in ever greater numbers.
For information on generating the client side certificate via your internal PKI, check this TechNet article here. It might look overwhelming, but in all honesty once you’ve got your Certificate Authority (CA) up and running, it’s a cake walk.
It must be noted that whilst your Config Manager site will work with HTTPS or HTTP by default, you must tick the box to use the PKI certificate (where available), as per below. I ticked this box before I made any other changes and no ill effects were experienced.
My biggest headache was how to get the clients migrated over. I had seen many people talking about using the .EXE commands such as /USEPKICERT or /NOCRLCHECK, but I knew I couldn’t apply these via the site’s client installation properties tab as you can only specify MSI properties in here. So I did it like so:
I didn’t faff around with the certificate specification stuff. I just let it do its thing. The key extra is the inclusion of CCMHOSTNAME, which tells the client where to go for its internet facing Management Point.
You must remember that the value specified next to CCMHOSTNAME has to match the FQDN you registered on a public DNS and specified as a SAN on the web server certificate.
So what next? How do you tell your existing clients to use HTTPS? Will CCMHOSTNAME be enough for new client installs?
The answers were nice and easy. Assuming you’ve configured the certificate as per the TechNet guide above, it will have autoenroll set. Go into Group Policy, and configure autoenroll for your domain PCs.
That’s it. I’d recommend staggering the Group Policy Object (GPO) rollout to avoid overwhelming the CA, but in the space of a few weeks I watched with a nice warm feeling as I hit several thousand successful hits, both in the CA console and a very useful Config Manager report (mentioned at the end of this post!).
Interestingly the client seems almost born to do this. As soon as the autoenrolled certificate is, er, autoenrolled, the Config Manager client immediately seems to register this. I’m putting it down to a Timey Wimey, Wibbly Wobbly effect. It’s explained very effectively here:
If you’ve done it right, you’ll see the following in the ClientIDManagerStartup log:
Okay, this pleases me! Simply applying the certificate to the PC results in it automatically flipping over to PKI. Assuming you’ve set a Management Point for HTTPS and:
If you go into the Config Manager applet via the Control Panel, you’ll see it has now changed, Marvellous!
Whoop! You can use one of the Config Manager reports to show how many PCs are using HTTPS, with no additional configuration. The report is under Site – Client Information and is called Count of clients and protocol used for communication:
So in short, very little effort and for once everything went as planned.
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:
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”.
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.