DojoCert – Certificate Enroller

I promised a few days ago that I’d tidy up some code and release the certificate enroller utility. So here it is; in a cab file and ready for consumption.

Since I covered most aspects in my previous article I’ll keep this short.

I am aware that my naming convention for my small utilities is rather dull. They all start with “Dojo”-something, and while it is easy to relate to the site name it still leaves something to be desired. But I haven’t figured out any other grand naming scheme yet, so we’ll have to live with it in the meantime 🙂

By default the “User” template will be used in the request. If you want to use another template you can change this by setting it in the following registry key:
No guarantee that other templates will work, but that’s better left as an exercise to the reader. (See no reason it wouldn’t work unless you require features not supported by Windows Mobile.)

I have tested this application against a W2K3 Enterprise CA. I was going to test it against W2K8 Enterprise as well, but ran into some other snags there, and I’ll probably have to reinstall that CA before I can test again.

This application does not require your device to be enrolled to SCMDM or an MDM solution. It can be used on “plain” devices. But keep in mind that the root certificate needs to be trusted before it will work. And the certificate will be validated so the host name needs to match the subject name of the certificate on the CA. I probably could have overridden this in the utility, but I feel that sort of defies the purpose of an application like this.

Hit the download link here:

Enrolling Personal Certificates with SCMDM

User certificates has been sort of an illusion when it comes to Windows Mobile. It’s been around for a while, but there’s been a few obstacles implementing this. Granted it’s part due to the fact that not everyone’s comfortable setting up a CA, and possibly not require one either. The general understanding of how Windows Mobile works. (Maybe there is a PKI guru in the company, but he doesn’t know what provisioning xml means, and the Windows Mobile guru doesn’t know how the CA works, and you’ve got things going.) Maybe I’m painting a dark picture, but I’m just saying it’s a possible obstacle. And there are of course many companies who are using certificates with success too for that matter.

But the primary obstacle in my mind has been the requirement to tether your device to your computer, and performing the enrollment process through ActiveSync. This bugs me for two reasons; if you’re deploying to 400 users who doesn’t have much of a concept what a Windows Mobile device is, and then you get the added bonus of helping them with ActiveSync in addition. Good luck to that. Not to mention that there are companies out there with policies requiring devices not to be connected to a computer. And do you really feel mobile when you’re killing a few moments in an airport hard resetting your device, and you need to bring out your laptop, and pull up VPN to get things going?

With SCMDM and Mobile VPN we have finally have the tools to say “haha” to those who tether their devices. I thought I’d step through a couple of options you have in the certificate enrollment department.

But first things first. What do we need these certificates for? Well, the typical need would probably be authenticating your ActiveSync account with a client certificate, or against a line-of-business application, maybe WiFi authentication. No need to type in passwords on a daily basis, and with a good setup server side we’re talking decent security as well. Hey, if you’re reading this you’ve probably had some ideas about this already without me telling you 🙂

Nice, but doesn’t the SCMDM enrollment process place a certificate on your device? Yes, but this certificate is issued to the device and is a computer certificate. Sure, the AD object of the device is tied to a specific user, but it’s purpose is authenticating the device itself, not the user pushing the buttons on it.

While SCMDM creates a couple of certificate templates, it does not create one intended for users. So we could either make our own certificate template, or go for one of the other predefined templates on your CA. I’m probably going to create my own template, not necessarily anything being wrong with the existing ones but to highlight one as specific for usage on a mobile device. Let’s call it “Mobile User”. More about that later, it’s not needed for your garden variety enrollment scenario.

There are a couple of different options as far as to how you actually enroll this certificate.

  • Using the “CertSrv” web site on the CA.
  • XML Provisioning.
  • Program with a user interface prompting the user to perform an action.
  • Program without a user interface (aka unattended enrollment).

I know that there’s an option to connect to ActiveSync/Windows Mobile Device Center and “Get Certificate”, but one of the main points here is how to avoid that 🙂

Let’s look a little closer into these options.

On your ordinary computer using the web site on the CA ( is a plausible option for enrolling for certificates. You’d think this was a viable option on your Windows Mobile device too. Well… On my W2K8 SP2 Beta CA the index page said that it was not viewable in a text-based browser. On my W2K3 CA I managed to get as far as the “Submit” button. But it still didn’t work. Got some cryptic errors and no go. According to Microsoft there is a patch to make things work. Tried it on my W2K8 box. Apparently it was not intended for the SP2 Beta since it said it did not apply to my system. At this point I realized that this option wasn’t really all that workable in the bigger picture, and moved on…

XML Provisioning
This is a good alternative for testing. Using the following xml you can trigger an enrollment from the device with a minimum of fuss.

    <characteristic type="CertificateEnroller">
        <characteristic type="Configuration">
        //A unique template name on the device.
        <characteristic type="UserCertificate">
            <parm name="ServerName" value="" />
            //This is the name of the template on the CA.
            <parm name="Template" value="user"/>
            <parm name="NoSSL" value="1" datatype="boolean"/>
        <characteristic type="Operation">
        <characteristic type="Enroll">
        //This a guid that must be unique on the device.
        <characteristic type="1234567890">
            <parm name="CertificateTypeFriendlyName" value="UserCertificate"/>
            <parm name="Username" value="username" />
            <parm name="Password" value="password" />

For all the details on the characteristics in this xml MSDN is your friend:

You can either package it in a cab/cpf file and copy to device, or you can provision it via RapiConfig.exe. I used RapiConfig as this is quite easy when in “debug” mode, and allows for an output from the provisioning as well. It does require the device to be connected to a host computer through ActiveSync, but that’s ok as long as it’s still work in progress at this stage. When pressing the “Enter” key on the computer I’m triggered for the credentials on the device, and notified when the certificate is ready to install itself. If you include the password in the xml, (which for obvious reasons is discouraged mind you), you’ll get a silent install with no prompts.

If we are able to perform an enrollment through this method we know everything is good on the CA side, and our chosen template works on our device as well. Still not very user-friendly though, and you don’t want to generate individual cab files that you send out to the users. So we need to step up things a notch before we can actually present something to your generic/average user.

Program with GUI

On some devices this option is already included. For instance on iPaqs HP has included a utility called “CertEnroll” where you input username, password and server address and the rest is done for you. (It uses the “User” template, and you don’t get to change this.) So by no means am I doing anything new here, but for completeness I’ve created a small utility that basically does the same as the xml code above. The server address you don’t have to enter as the device already knows this as a result of the device enrollment process in SCMDM. That is, at the moment I can make a qualified guess as to what the address to your CA is, but in case I got it wrong you may change the address to the correct one. I can only guess the address if your device has been enrolled in SCMDM. (If you want to get technical I query the contents of the MY/System certificate store, and look into the details of the first certficiate in the store. If you haven’t performed any other enrollments there is only one certificate here; which would be the device certificate.)

Just fill in the details, and press “Enroll”. Hopefully you’ll get a status telling you everything went ok. Be aware that the server address must match the subject name for the SSL certificate on the CA server.


That should cover the basics shouldn’t it? At this time you might be asking a few questions however:

This seems fair enough – where do I find the download link?

Hey, you mentioned an application without any user interaction – where is it?

Great – I’ve got a personal certificate on my device. Now what?

I’ll provide some input in the order listed 🙂

I have a few things to sort out in the certificate enroller above. I’ll just wrap it up in a nice little cab, and release in a couple of days. Not sure if I’ll make a WM Standard version as well (not much demand for Standard apps with the current devices).

As for the silent enroller. I’m working on it. I thought this article would be rather short and sweet, but it turned out to become more verbose than expected. So I realized it would probably be better to break it up in a two-parter. So why didn’t I call this “Part 1”? Well, you see… While I normally have most technical details ready when making a multi-parter I’m still working on this one. Since unattended enrollment still requires some authentication and security mechanisms I need to think things through and do some experiments. And I can’t actually promise what I’m able to deliver. (Yes, I am probably able to do a “hack”, but I want to make something that could actually be considered usable.) If something good comes out of it, I’ll be sure to keep you updated.

Just having a certificate on the device does nothing magic by itself I agree. I’ll be playing around doing some things here as well, and hope to return with something interesting at a later point in time. I get the feeling all the time that I’m not pushing out new content at a fast enough rate, but I guess it’s more important that I feel I have more things to be opining about 🙂

Implementing a dedicated CA/PKI for SCMDM

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

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.

Empty = true
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.


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.

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:

Signature = "$Windows NT$"

Empty = true

Empty = true

OID = ;SCMDMMobileDevice
OID = ; Client Authentication
OID = ; Server Authentication
OID = ;Private Key Archival

pathlength = 0

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

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.