I mentioned in my last blog about Android Ice Cream Sandwich that it is now possible, (actually from Android 3.x Honeycomb), to enroll certificates directly from the /CertSrv web site onto your mobile device. (If you’re running a Microsoft CA of course.)
This is all nice and dandy, but it’s not like Android devices are the only devices you’re likely to be supporting. With the tablet varieties the split is something like 90/10 iPad vs “the rest”. However if you ever tried loading up /CertSrv on your iOS device or your Windows Phone you’ll have noticed that it’s not working.
I find this slightly annoying, and decided to look into this further. Those pesky ActiveX controls can’t be the only reason right?
There’s two things to sort out here really; is it anything with the web pages themselves and the server, or something on the browser side. Turns out there’s a bit of both involved actually.
Step one – tweak the web pages to accommodate mobile devices that aren’t domain-joined. How to do this?
- Open up your /CertSrv folder.
- Locate the files “default.asp” and “certrqtp.inc”. Change the ownership of these files, and then assign yourself “Modify” permissions. (These are by default system files you are not allowed to touch even if you happen to be über-admin.)
- Change the href in following line:
“<TD><LocID ID=locLblRequestCert><A Href=”certrqad.asp”><Font Face=”Arial”>Request a certificate</Font></A></LocID></TD>”
This makes sure you get redirected to a page where you can choose a “simple” template instead of ending up in the ActiveX control.
Now you might be happy with what you’ve got at this point, but let’s say I’ve followed best practices, and I have decided to offer a dedicated certificate type for mobile devices.
To make sure this is available you have to modify the “certrqtp.inc” file. (Not “certrqus.asp” as you might expect.)
- Find the following lines:
Const L_EmailProtectionCert_Text=”E-Mail Protection Certificate”
Const L_UserTemplateCert_Text=”User Certificate”
Const L_MobileDeviceTemplateCert_Text=”Mobile Device”
(You can call the Const whatever you like, and the text does not have to match the template name either.)
Find the following section (still in certrqtp.inc):
‘ Request types for enterprise
rgAvailReqTypes(0,FIELD_CSPLIST)=”Microsoft Enhanced Cryptographic Provider v1.0?Microsoft Base Cryptographic Provider v1.0″
rgAvailReqTypes(0,FIELD_CSPLIST2)=”Microsoft Base Cryptographic Provider v1.0?Microsoft Enhanced Cryptographic Provider v1.0″
Delete or comment out “nAvailReqTypes” and add the following:
rgAvailReqTypes(1,FIELD_CSPLIST)=”Microsoft Enhanced Cryptographic Provider v1.0?Microsoft Base Cryptographic Provider v1.0″
rgAvailReqTypes(1,FIELD_CSPLIST2)=”Microsoft Base Cryptographic Provider v1.0?Microsoft Enhanced Cryptographic Provider v1.0″
(EXPORTABLE can be set to either true or false – it doesn’t make a difference on a mobile device.)
Full disclosure: I did not figure out these files entirely on my own. I attended a couple of sessions with Brian Komar a couple of weeks back, and he showed the trick above as a way to get Mac computers to enroll certificates.
If you have an hour to spare I can recommend watching the recording:
It would have been great if this was the conclusion and we could call everyone happy at this point…But it doesn’t work out that way unfortunately. If you had an Android device it could look like this:
Oh, sure, you can click the “Submit” button but you will get an error. Now why is this?
Locate the “certrqbi.asp” file and open it in Notepad or something. (You don’t have to change permissions as we’re not going to edit it.)
You’ll find a section starting with the following:
<Form Name=SubmittedData Action=”certfnsh.asp” OnSubmit=”return goNext();” Method=Post>
The first part of the IF-clause is “<%If “IE”=sBrowser Then%>” meaning that Internet Explorer gets special treatment, also known as ActiveX, whereas all other browsers get a different version.
The interesting HTML markup to look out for is the following line:
<TD><KeyGen Name=CertRequest Challenge=”provePequalsNP”></TD>
Off topic: someone in Microsoft apparently likes using geeky references in the challenge above:
Checking out the HTML reference we learn that “KeyGen” is a standard tag:
And Mozilla has a decent explanation of it works:
This tag, if implemented, is responsible for instructing your device to create a certificate request, and it is assumed that you will also be able to complete the request after submitting if you support it. (Thus having support for on-device certificate enrollment.)
Here’s the not so funny part. Windows Phone does not support this tag. Internet Explorer on the desktop never has, and as such the mobile version of IE doesn’t either. I do not know if MSFT plans to include this in IE10 – I couldn’t find anything in the developer reference for the preview.
Safari on the Mac supports this tag, which is why Brian Komar’s demo worked in OSX, but the mobile version of Safari does not support it yet. But at least it is a possibility that Apple might implement it if they find the time for it.
Android as you saw last time has no problems supporting this tag now.
The solution to this? Did I say I had that in place? When I started out hacking the CertSrv files I thought this would be doable, but obviously it’s a little bit tricky getting around lack of standards support in the devices. How I might approach it could go like this:
- Build your own /CertSrv
- User agent detection
=> send Android to the current and working view.
=> send iOS to a view with either a SCEP enrollment profile, or an interface for building a pfx in the background. (Which could also be a profile file.)
=> for Windows Phone provide an interface for generating a pfx on the server to be downloaded through a URL.
There are other issues with /CertSrv in itself, so you might not want to rely on a modded version either in production, but for a PoC it could work.
The “proper” answer is to skip CertSrv altogether, and build your own web UI on top of the Certificate Enrollment Web Services included in Windows Server 2008 R2.
The conclusion in this post leaves me kind of disappointed, and possibly some of you guys as well, as I really would like to have provided a quick fix you can use in demo setups. The key to solving the problem does however lie in first understanding the scenario in detail, and I hope this answers the question “why isn’t it working”. You’d think it was primarily MSFT’s fault, (and while it’s not the same teams involved you could argue that MSFT is at fault for the lack of support in IE mobile), the reason it doesn’t work on iOS is not some proprietary Windows thing with the site.