System Center Mobile Device Manager 2008 is a demanding product to install in your infrastructure. You need to be able to work out firewalls, routing, and the usual things, but in addition you need a CA to issue certificates. There are a couple of possible responses from customers and system integrators to this requirement;
- “No biggie. I’ll just install a new CA, and hit next-next-next in the wizard.”
- “How do we integrate it with our current PKI infrastructure?”
- “Sounds complicated. Do I have to install a bunch of servers just to get certificates for some mobile devices?”

People are at difficult comfort levels when it comes to the concept of certificates. Now I’m certainly not an authority figure on this topic either, but reading the books of one Mr. Brian Komar on setting up a Microsoft-based PKI helped increasing my understanding of how it works.

Some of the items that require work when it comes to establishing a full-blown PKI range from deciding how long a given certificate should be valid, how the private key of the CA is protected, to who are responsible for managing the different roles in a PKI infrastructure, and more. And a lot of these challenges aren’t technical issues either, so you might not be able to work it out just by “throwing” hardware and software at the problem.

But for the sake of a “simple” SCMDM deployment you don’t need to concern yourself with all these details, if you only care about making something work for the mobile devices and related servers. I’m not suggesting you just install a new server and hit next in the CA wizard without any planning, but rather sit back in your chair for a moment and say to yourself that this is not a problem before you go trigger happy

Previously I have referred to the requirements of having an Enterprise CA when showing how to install SCMDM, but I haven’t gone into any details regarding the setup of this CA. In this post I will be trying to build a CA dedicated for usage in an SCMDM scenario, and restricting it to only work for this purpose. So you don’t need to concern yourself with setting up offline and online CAs, integrating with existing CAs, etc. The CA is not designed to work for issuing other certificates, so it’s a simplified setup that might work for you. (This is also a question of scale – if you plan on deploying 10000 devices you might want to go for a “proper” PKI dedicated to devices. Up to you of course, but there might still be some points to pick up here and reuse in your specific scenario.)

Let’s start off with some servers. I’ve installed a Domain Controller, and a separate server for the CA. Both are running Windows Server 2008 x64 Enterprise Edition. The Enterprise Edition is needed to get all the available features in the Enterprise CA. (Custom Templates for instance.) You could have used Windows Server 2003 instead, but there are differences as to how to perform these steps, as well as functional differences between the 2003 CA and the 2008 CA so I’ll be going for the most recent and relevant release of Windows Server. I believe however that most of the steps below should be valid on 2003 as well.

You might be thinking that it’s easy to follow the wizard and as long as you click the correct boxes it will work, but some of the options we want to configure are not available in the “Add Role”-wizard. We’ll create a settings file first to get around this. This file is called CAPolicy.inf, and should be stored in the %Windir%-folder (C:\Windows would be the default.) When you install the CA role this file will be processed in the background, and applied to your installation.

The contents of this file follows the “old-school” standard present in Win 3.11 .ini-files:
[SomeSection]
Somevalue = 123

I’ll explain some of the relevant settings (and proposed values for this scenario) below. For more details look up this article on TechNet:
http://technet.microsoft.com/en-us/library/cc737264.aspx

[basicconstraintsextension]
pathlength = 0
Since we are setting up a dedicated CA for our mobile devices we don’t want any sub-CAs below this CA. By setting pathlength to 0 this CA will be the only one in the chain, and you are not able to add a sub-CA.

[CRLDistributionPoint]
Empty = true
[AuthorityInformationAccess]
Empty = true
Some certificates expose internal details like addresses, which you may not want everyone to see. This is the default for Windows Server 2003, but for Windows Server 2008 this has changed, and CDP and AIA are no longer included by default. So this parameter is not strictly necessary for our lab, but we will include it anyways.
CDP and AIA in a certificate.

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.4.1.x.y.z
We have no need to accommodate every certificate need in the enterprise, so we’ll restrict the available certificate types through specifying the allowed EKUs. This means the CA will only issue the certificates we list in this section. If you wanted the CA to allow all certificates you would omit this section from you CAPolicy.inf file.

[certsrv_server]
LoadDefaultTemplates = 0
A CA comes preloaded with a number of certificate templates, but since we will only be using this CA for custom templates (created for SCMDM) we do not need the default templates.

Rolling it all into a complete file, we get the following:

[Version]
Signature = "$Windows NT$"

[AuthorityInformationAccess]
Empty = true

[CRLDistributionPoint]
Empty = true

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.4.1.311.65.2.1 ;SCMDMMobileDevice
OID = 1.3.6.1.4.1.311.65.1.1 ;SCMDMGCM
OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
OID = 1.3.6.1.4.1.311.21.5 ;Private Key Archival

[basicconstraintsextension]
pathlength = 0

[certsrv_server]
LoadDefaultTemplates = 0

As you can see I have included the specific certificate types that are necessary for SCMDM to work. Client & Server Authentication are included as they are needed for the SSL certificates on your SCMDM servers, but you will also be able to issue generic SSL certificates with these enabled. I have not included the Code Signing template which arguably is used if you distribute software from SCMDM. You don’t actually need a CA to do your code signing, but if you want to use this certificate type the OID is 1.3.6.1.5.5.7.3.3.

With this preparation in mind we are ready to install the CA. This being Windows Server 2008 we click “Add Role” in Server Manager to get started. I’ve only pasted partial screenshots, but I think you’ll be able to follow along nonetheless.

We then proceed to mount the SCMDM iso, and run ADConfig. (For more details regarding ADConfig see previous posts.) This is the results in the Certificate MMC after running ADConfig with the /createTemplates and /enableTemplates parameters. I do not know what the “Unknown” template is. It’s probably related to me locking down things with CAPolicy.inf, but I haven’t seen it causing any errors.

This view shows the enabled templates. The standard templates are still available, and you may also enable these without any warnings. If you try to actually issue a non-approved certificate type you will not succeed though.

This is the message I receive when I try to request a code signing certificate through the Certificate Services web site.

This concludes today’s session, and you are now ready to roll certificates to devices and SCMDM servers without anyone bothering you to implement S/MIME on your Exchange Server as well since you’re doing the whole CA thing already

As I already mentioned, this is a basic setup and I recommend you read more about setting up a CA if this was interesting. Make sure to check out more settings for the CAPolicy.inf file, and how to script further configuration with certutil.exe.

Certificates and CAs are complicated matters, so I hope my advisory in this post is fairly bug free But if you have suggestions for a better setup, or corrections do let me know. Please note that I have tested this with SCMDM 2008 SP1, and have not tested it on the RTM release. There is also no guarantee that it will work without modifications on future releases of SCMDM.