In my last post I provided a very high-level overview of some of the certificate related services in Windows Server 2008 R2, and said I would be digging further into the material. Looking through the archives it seems I have been able to produce at least one article pr month since I started this site and it almost looked like I wouldn’t deliver this month. Well, December and January are always busy months, but I did find some spare time to look into SCEP, (Simple Certificate Enrollment Protocol), and thought this was a good time to bring some more details.

The quick recap first; SCEP is a protocol defined by Cisco for enrolling machine certificates. SCEP is implemented in Windows Server as Network Device Enrollment Service (NDES). iPhone uses SCEP for secure bootstrapping/provisioning, and maybe it could be relevant for other devices too.

As far as installation of the NDES role I would recommend the following white paper by MSFT:
http://www.microsoft.com/downloads/details.aspx?familyid=E11780DE-819F-40D7-8B8E-10845BC8D446&displaylang=en

Let’s get down to actually using it. SCEP is implemented as a dll file called mscep.dll which you can interact with through HTTP GET commands. There are a couple of different operations you can specify as the desired action. The first one is called “GetCACaps” which is used to retrieve what operations and behavior the server supports, but this operation is optional and as far as I can tell it is not implemented by Microsoft.

The next, which is supported, and not optional, is “GetCACert”. An example URL of this would be:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(You’ll notice I’ve attached a message parameter as well, but the message part of the URL can be any random text at this point.)

If doing this in a browser you’ll see a response in the form of a file called “mscep”. Save this as a p7b file, and you will have the entire certificate chain of the CA relating to NDES. If you have a single Root CA, and do a “next-next” install of the NDES role you will have three certificates in the chain; one for the Root CA, and two for the certificate request agents.

Before moving on to the next step, let’s take a quick de-tour looking at how this setup works on a high level:
You have three URLs that work in your browser
http://CA/certsrv/mscep & http://CA/certsrv/mscep/mscep.dll which will both give you the same html output:

http://CA/certsrv/mscep_admin which gives some info for the admin who enrolls the device:

And following this these are the steps involved in an enrollment:
- Device generates a key pair (public and private).
- Admin logs on to the admin page in his browser, and retrieves the password.
- Device generates a certificate signing request (CSR), and sends off to the SCEP/NDES server.
- NDES sends the request to the CA. (This can be on the same server.)
- A response is received by the device containing the actual certificate.

It does sound easy doesn’t it. You generate a request, and if you have it in the form of a file it will be a long Base64-string like this (I left out most lines of the string to make the screenshot smaller):

And you submit it to the NDES service through the browser:
http://CA/certsrv/mscep/mscep.dll?operation=PKIMessage&Message=MIID9Q=
I’ve left out most of the string here too, but it’s really just copy & paste everything from the CSR file except the first and last lines. You’ll once again get a file called “mscep” back, but it’s not going to work saving it as pfx, cer, etc.

Checking out the Event Viewer on the CA we see something similar to this:

Ah, but thing is, when I said generate a CSR above I left out a couple of the finer details. You see, you’re not able to just go through the certificate request process in IIS or the Certificates MMC. As the error indicates you aren’t getting all the details embedded that you need for a SCEP request. I found a neat tool called “ASN.1 Editor” (ASN is the format for CSR files), and thought I would be able to handcraft the request with this utility. Then it occurred to me that generating a valid key pair in my head, using it for signing, and inputting it in the request probably is well above my mental capabilities Nonetheless it is a useful utility if you’re generating CSRs and want to “debug” these. (If you have a certificate you already have on file, you can look at that too.)
Hit the link for download: http://lipingshare.com/Asn1Editor

This leaves us to the programmatic approach, and I’d love to have given you all some finished C# code as the next step. I ran into a couple of challenges while testing this though – the first being that support for crypto stuff is so-so in C#, barely present in Compact Framework, and dependent on the OS on the desktop side. Realistically you need to run it on Windows Server 2008/Vista or Windows 7. While I certainly have access to those platforms, and it is workable with some dll imports, it gave me a couple of pointers to where this had to be taken for building a proper solution, but not the solution itself. I initially thought that a client on Windows Mobile was feasible, but maybe it’s more work than it’s worth. You’d also have to go through all the same obstacles implementing it for the Android if that became a feature request, and you’d still have to adapt in some way if using it on the iPhone. (The iPhone already has native support courtesy of Apple Inc. mind you – I’ll get back to that.)

I’ll also admit that learning the crypto APIs required for this was more than I could chew through in an hour. I’ve managed to create a CSR programmatically and getting the same error as above, and I’ve managed to put together a request that crashes the program entirely when running. Basically I have to learn it proper if I want to get it working, and that’s probably an exercise better left for later on when I see a greater need for it. At the moment it’s more of a nice-to-have than need-to-have for what I do. (Man, I felt stupid trying to guess my way to something that would work.)

If you want the “algorithm” it works roughly like this:
Create a PKCS#10 request, wrap it in a PKCS#7 request with a couple of extra attributes (senderNonce, TransactionID, MessageType). Sign this with the public key from the certificate of the RA and submit.

If you want the gory details there’s no way to avoid reading the RFC:
http://tools.ietf.org/html/draft-nourse-scep-20
And this paper is also of great help:
http://www.gamingstandards.com/…/appendix_d_scep_operations.htm

So, let’s say for the sake of discussion that we have solved the coding issues – what would we do next? I’d probably start by removing one more obstacle on the server side. The default install of the NDES role on the CA will require you to use one-time passwords (remember the admin web page?). While this is a good secure by default implementation I find it slightly impractical  for our purposes, so let’s disable it. Navigate to regedit on your CA, and flip the following registry key to 0 (if it doesn’t exist create a DWORD value):
HKLM\Software\Microsoft\Cryptography\MSCEP\EnforcePassword\EnforcePassword

So, the iPhone works you say…How did I solve that since I didn’t see the coding through to the bitter end? Well, I resorted to “cheating” actually I installed the latest Feature Pack for an Afaria Server I’ve got running, since this adds iPhone support. The funny thing is that the technical approach I was evaluating was/is very similar to what Sybase have done. I’m not going into the details of the Sybase implementation as some elements are only relevant for the iPhone, and not SCEP enrollment in general, but it basically starts with an SMS sent to the device to trigger the enrollment process. The device generates a request, sends this to a provisioning server, and the server signs this request before passing it onto the CA. The iPhone picks up the generated certificate by talking to the CA directly though, and doesn’t do everything through the provisioning server. (I’m not entirely sure as to when the communication end-points are switched.)

What I’m thinking is that it should be possible to channel everything through a proxy web service so you don’t have to expose the CA directly to the Internet. (Yes, I am aware of a reverse proxy like ISA Server, but not published at all is even better.) This web service could also handle requests from both clients able to generate the actual request themselves, and clients who has to make do with a “light” request and have the server do the rest.

Eventually you should end up with a certificate on your device, and your CA will have it on record if you get it right:

Notice how the common name does not easily identify the device.

So, great, another certificate on the device. What to do with it? The iPhone uses it for signing of the provisioning profiles you send to it. You can lock down the iPhone with security policies – like enforcing Power-on-Password, removing YouTube/Camera/AppStore, and the user will not be able to remove it.

While I haven’t investigated it further I believe it should be possible to enforce restrictions like only allowing devices with the proper device certificate to access ActiveSync – while still allowing ActiveSync without the need for VPN tunnels and the like. Like so many other things – the technology is there and it’s up to you to find a use for it