I just went through the process of requesting a PKI certificate from one of the third-party certificate providers for my lab CMG, I used DigiCert, and the route I took was a little bit off-piste, as in not well-documented, so I thought I’d share.

CMG’s require a PKI “server authentication” certificate as an installation requirement:

This certificate can be issued internally using Enterprise PKI or issued by a Public provider. Simply put, the choices are a ‘third-party’ public provider versus an Enterprise server residing on your corporate network running Certificate services.

Notable key reasons why you’d use either:

  • Enterprise PKI – Complete management control over issuance and revocation for the entire lifetime of the certificate, requires an infrastructure footprint that can span both the Intranet and Internet (CRL publishing) with an attendant team with reasonable PKI skills. Fits well in a large organisation that needs PKI for more than ConfigMgr, but not so well in small environments. Requires a documented procedure and preservation of knowledge for 1 to 2 years to handle certificate expiration, which can be difficult for small teams who leave the PKI server (often a VM) alone until it is needed. I’ve seen a customer’s admin attempt to return to an Enterprise PKI VM only to find it is missing, make sure you read about what to back up up on your Enterprise PKI CA … and small shops be aware that once you implement Enterprise PKI you have both an ability and a liability in the environment. The trusted root certificate and any intermediate certificates need to be installed onto devices that are going to talk to a CMG.

  • Public PKI – No actual infrastructure is required, a one time cost until the certificate needs renewing (make a calendar reminder for at least 2 weeks before expiration). Renewal is a relatively straight-forward process but requires documentation or a decent guide. Windows 10 contains a DigiCert root certificate that will be in the CMG’s server authentication certificate certification path, that’s a tick in the box for one of the CMG’s security requirements and importantly means we do not have to install certificates on devices for them to talk to the CMG. This pathway opens up the minimal steps needed to install the ConfigMgr client on remote devices, which is CCMSETUP.EXE and a command line to point at the CMG, and I like it a lot, unlocks an age old problem around client install on workgroup devices residing anywhere in the world.

Before a client can talk to the CMG to do the actual authentication (Azure Identity, Token identity, Certificate identity) it has to have a root certificate installed that the CMG trusts, either your Enterprise PKI trusted root certificate if you are using an Enterprise PKI certificate, or if you are using a Public PKI certificate a Windows 10 built-in root certificate. Here’s a DigiCert certificate issued for my CMG showing the certificate certification path or “chain”, the certificate is linked or chained to an intermediate certificate which is linked or chained to the DigiCert root certificate:

I won’t cover the process for handling the CMG server authentication certificate request with DigiCert end-to-end, instead I’ll redirect you to a quite competent fellow EM MVP, Eswar Koneti, who wrote a good blog post on the entire procedure, from how to request the certificate to authorising it with DigiCert, to obtaining the certificate in readiness to hand it off to a CMG.

He has other posts, specifically one that talks about how to switch from Enterprise PKI to Public PKI which is definitely worth having a look at.

In Eswar’s guide he resorts to using Email as a means to prove control over the domain being used, which then leads to issuance of the Certificate.

DigiCert’s three options for doing this security-handshake before the certificate is issued currently are:

  1. Email
  2. File
  3. DNS

With Eswar taking the email route, I’ll show you how to take the File route.

The shot below shows a certificate that DigiCert are processing, I’ve provided the CSR and now need to prove that I own the domain:

The reason I went about using the file route is because I do not have email for ConfigMgr2012.com, and I couldn’t get the DNS method to work using a TXT record containing the CMG DNS name or a TXT record containing the TLD, like this:

Since configmgr2012cmg1.configmgr2012.com is just a CName alias to the cloudapp.net destination, there is no DNS zone in which to create a TXT file, has anyone else used DNS to prove control over the domain when ordering a certificate for a CMG? Or does DigitCert assume it is a sub-domain and isn’t checking the top level domain?

Without Email access and with the DNS changes not being recognised by DigiCert, that leaves the File method, which entails publishing a TXT extension file on a web server.

You might as well download the fileauth.txt file now and store it on your web server.

Before we dive in be aware that this change will take an already existing CMG service offline for several hours, as we will modify the public DNS CName record making it inaccessible to clients for a period of time. Therefore the Email and DNS routes are more desirable as a consequence outside of a lab.

Firstly go to your DNS admin portal and change your CMG CName alias, so that instead of pointing at your cloudapp.net destination it points at the IP address of your web server.

From:

To:

It will take an hour or two for the DNS record to expire and be refreshed, dependent on the TTL.

In the meantime visit your web server.

Create a folder somewhere so as to host the fileauth.txt file you downloaded from DigitCert:

C:\Website\well-known\pki-validation

The above example shows Website as the root folder, you can call this anything you want, however the following folder and its sub-folder must remain the same: well-known\pki-validation

Here’s a shot of Explorer:

Drop fileauth.txt into the pki-validation folder.

Visit IIS Manager.

One of your web sites will have your DNS name bound to it, mine is ConfigMgr2012.com, if you don’t have an existing website create a new one yourself (create a new folder for it, sort out its bindings, put a test landing-page in there, make sure it renders in a web browser) and follow on with these steps.

Open your websites bindings and add the FQDN that you use for your CMG CName, mine is configmgr2012cmg1.configmgr2012.com:

Once the DNS change for the CMG’s CName has taken place, punching it in to a web browser will take you to your website.

If you have a landing page for your website, mine is a WordPress blog, you should see it, if not check that the CName change we made has replaced the previous by visiting a website like mxtoolbox.com, if that is okay it’s most likely firewall rules if its a new website.

Next we create a virtual directory using our website as the target:

The Alias has to be called .well-known, and the physical path points to the new well-known folder that we created earlier. Worth noting that you can create the well-known folder and its subfolder within an existing websites folder, I kept them separate for no real reason.

You should have a new virtual directory shown hanging off your website:

Open a web browser, punch in the URL and see if the FileAuth.txt files contents are rendered.

In my case the URL would be: HTTP://ConfigMgr2012CMG1.ConfigMgr2012.com/.well-known/pki-validation/fileauth.txt

Here’s the file appearing in the web browser:

Once it is showing, return to DigitCert and complete the process for proving control over the domain for this certificates request, and go collect your certificate. Eswar’s guide explains what to do next, but before moving on revert your DNS CName change back to your cloudapp.net destination:

And also remove the website virtual directory and the folder structure, so as to tidy up.

An hour or two later DNS lookups will show the CName has changed back, at which point you are good to go with installing the CMG with your new PFX certificate.

Enjoy.