Certificate Server Enterprise Edition and Smart Cards

The following article was kindly written by Adrian Beasley  

General
I have recently installed Certificate Services on a Windows Server 2003 R2 Enterprise Edition machine, in order to make available version 2 certificate templates, which are configurable, and I have been investigating these, and the capabilities of smart cards. The following describes my experiences, not structured to any particular plan; I hope it is of interest and helpful to fellow professionals.

I have expressed before my opinion that the standard of documentation in the PKI area is appalling, from the point of view of anyone trying to learn what it’s about. Once you have a decent understanding of the subject, then the various books and articles are reasonably intelligible, but a beginner has a hard time of it. The best general reference book that I know is ‘Microsoft Windows Server 2003 PKI and Certificate Security’ by Brian Komar with the Microsoft PKI Team (Microsoft Press ISBN 0-7356-2021-0). But I warn you that it’s not an easy read. I will refer to this book from time to time as ‘the PKI book’. Some of the stuff following may seem elementary or even trivial. But it’s almost entirely what I’ve found out for myself, by trial and error; most of it I have not seen documented anywhere.

It should be noted that I am dealing throughout with Enterprise Certification Authorities, not stand-alone ones. Enterprise CAs are integrated into Active Directory, and many very important benefits flow from this.

Availability of Smart Cards and Ancillary Equipment
I would have begun working with smart cards years ago (literally), had I been able to get hold of them. They just aren’t available from the usual suppliers. The manufacturers of the cards and of the readers (generally different organisations) do not sell them directly to the public, but have authorised resellers. These resellers seem to be prepared to sell the goods only if you are prepared to hire them (at a fancy price) to design and build you a PKI. They are not prepared to sell the goods alone, in small quantities, to an independent such as myself.

In other words, it’s a racket.

Only a few months ago, I finally located a company dealing in these goods, happy to sell to anybody. They are called Smartcard Focus and have their office in Richmond, Surrey. Their website is www.smartcardfocus.com. I heartily recommend them. There may be others (if you know of any such, please post a comment).

Administrative Tool
I have found the ideal administrative tool for dealing with certificates, templates and CAs to be a Microsoft Management Console configured with four snap-ins:
• Certificates (Current User)
• Certificates (Local Machine)
• Certificate Templates
• Certification Authority.
This has everything you need in one place. (You need Domain Admin privilege for all except the first snap-in.) It can be run from any machine, but do specify the particular CA machine, otherwise whenever you first open that section, an error is reported that Certificate Services are not running on the current machine, and you have to point it to the relevant one. (You can also point to the certificate store on another machine; the only place where you are restricted is that you can only see the local user certificates). You can of course have more than one machine certificates and CA snap-ins, if you find the added complication worth it.

Certificate Templates
Certificate templates allow certificate configurations to be defined, and certificates then to be issued based on those configurations. They are AD objects (and thus available only with Enterprise CAs). A set of standard templates is installed in AD as soon as certificate services are installed on any machine in the forest. (For an enterprise CA, they should be installed on a domain controller.) The PKI book lists the standard templates, and their intended purposes, at the beginning of chapter 8. (In fact there is a lot of redundancy in these templates – a pair of templates may have different names, reflecting their intended usages, but identical configurations.)

Certificates are issued by the Certificate Server(s). These are configured to offer a subset of the available templates. In an extensive enterprise network, different CAs could be configured to offer different selections of certificates (i.e. templates), reflecting local needs. The Certificate Templates snap-in shows all the available templates; the Certificate Templates section of the Certification Authority snap-in shows the selection of templates offered by that CA.

Version 1 templates are hard coded. The only change that can be made is to the security settings, i.e. who can enrol certificates based on them. Only the standard version 1 templates are available on a Windows Server 2003 Standard Edition or a Windows 2000 (any edition) Certificate Server. Version 2 templates allow almost anything to be configured (except insofar as certain inconsistent combinations of settings are prevented). Both version 1 and version 2 standard templates are available on Windows Server 2003 Enterprise (or Data Centre) Edition. A new template is created by duplicating an existing template (standard or user-defined) – choose the one nearest the intended use as the starting point. Duplicating a version 1 template creates a version 2 template of equivalent settings (as near as possible – some things are defined differently at v2). One of the few things that cannot be changed in a v2 template is the name – that is fixed at the time the template is created, and cannot be changed subsequently. Template names must be unique in the AD forest.

You could of course issue certificates based on v1 templates even from an Enterprise Edition Certificate Server (and indeed there are a few situations where you might want to do just that). But normally v2 templates are the ones to use (even if just a straight copy of a standard v1 template). The sort of things you would typically want to customise include:
• the extensions (application policies), i.e. the purposes for which the certificates issued to that template can be used
• the validity period of the certificates
• whether to publish the certificates in AD (so they are immediately accessible to all users)
• the specific naming convention for the certificates
• whether the private key can be exported along with the certificate
• the Cryptographic Service Provider
• and of course the security settings – who can get at the template.
It should be noted here that security setting are different between v1 and v2 templates. With v1 templates, a security principal – user or computer – needs just Enroll permission on the template, to be able to enrol certificates based thereon. But with v2 templates, both Read and Enroll permissions are required (and also Autoenroll, if it is required to enroll certificates without user intervention – this permission is not available with v1).

You will probably want to scrap the set of standard v2 templates selected by default to be available at the Certificate Server, and define your own selection. (In particular, if you have previously worked with the standard edition or Windows 2000, and thus with a set of v1 templates, you may well wish to start out with a set of v2 templates corresponding to the v1 ones you are used to.) But note two particular gotchas:
• Smartcard authentication works differently at Enterprise Edition, and requires that the certificate controlling authentication on the domain controller must also have the Smartcard Logon application policy extension. In fact there is a standard v2 template Domain Controller Authentication, which already has this (together with client and server authentication extensions, as required). You are strongly advised to use this template. If (like me!) you create your own Domain Controller v2 template by duplicating v1 Domain Controller, it will not by default have this extension, and smart card authentication just will not work – you get an error message containing the error number 0xC00000BB when trying to log on (which is somewhat less than helpful), and this problem is not published anywhere, (though it is known internally at Microsoft).
• RADIUS authentication also works differently at Enterprise Edition. The RAS and IAS Server template is provided explicitly for certificates supporting RADIUS authentication. A certificate based on the Domain Controller Authentication template does not work for this purpose. (Previously, a certificate based on the v1 Domain Controller or Computer certificate – according as the RADIUS server was or wasn’t a domain controller – served this purpose. Indeed the v1 Domain Controller still does! But the v2 standard Domain Controller Authentication template doesn’t.)

On a similar note, I would draw your attention to Knowledge Base article 903220. After Windows Server 2003 SP1, the standard Domain Controllers group needs to be added to the new security group CERTSVC_DCOM_ACCESS, in order for domain controllers to be able to enrol certificates. For some reason, this is not the case by default. It took me a little while to pin that one down, too, but at least it is documented.

Readers may note that I am careful to write of v1 and v2 templates, and of certificates enrolled against them. It is all too easy, especially in speech, to slip into the usage of v1 and v2 certificates. In fact, all certificates, whichever template version they are derived from, are themselves version 3 – of the X.509 standard, that is. I hope that’s clear! If a v2 template has exactly the same settings as a v1 template, then either would generate identically the same certificate. There is nothing inferior about v1 templates as regards the certificates they generate - they simply lack v2’s configurational capabilities. (That is how I now understand it - and it embarrasses me to reflect how long it took me to work it out – but of course it’s not stated explicitly anywhere in the documentation.)

Version 2 Templates – a Few Loose Ends
You can configure a v2 template pretty much how you like, and EE Certificate Services will issue certificates based on it, but whether they will then actually work in the way you expect (if at all) is a different matter entirely - because this is the responsibility of some quite other part of the OS. I note here a few quirks encountered, some documented, some not.

Certificates corresponding to most templates are enrolled in one of two ways, either by the Certificates MMC snap-in, or by the Certificate Server’s Web Interface. (It is also possible from the command line or by scripting, though I have yet to think of circumstances in which I would want to do it that way.) In certain circumstances, certificates can be autoenrolled, which requires no user action at all – this is controlled by the template’s security settings and by group policy.

But certificates to certain templates have their own individual enrolment mechanisms.

Web Server certificates, allowing secure access to the website using SSL security, are enrolled from the IIS Manager, invoking the Web Server Certificate Wizard. This will enrol a certificate directly, but only if using the v1 Web Server template (because that name is hard coded into the tool). It is possible to issue a web server certificate to a v2 template, but only indirectly, thus:
• the web server certificate wizard is used to prepare a certificate request; this writes the public key to a text file
• the certificate server web interface is used to submit the request, copying the public key by cut and paste from the text file to the certificate request form
• the certificate is enrolled and written to a base 64 – encoded file
• this file is then imported by the web server certificate wizard processing the pending request.
The process is describe in detail in the PKI book, chapter 17, p385 onwards. This is all rather laborious, compared to the 1-step process if using the v1 template (so this is a case where you might reasonably continue to use v1 templates with an EE certificate server). But is does work just fine (so all my internal websites are now protected by SSL security, even the ones which just say ‘under construction’).

You can use a web server certificate on an Exchange server, more specifically on the appropriate protocol’s virtual machine, to encrypt traffic between the server and the e-mail client. The PKI book describes this in chapter 18, p415 onwards. The enrolment here is from Exchange Administrator. If you are using a v2 template, then exactly the same indirect process as described above must be performed (though, oddly, the PKI book does not point this out). If the Exchange server is Internet-facing, then do not enforce SSL on SMTP traffic, otherwise you won’t get any messages coming in from the Net (although outgoing traffic is okay)!

VPNs and secure Wireless networks work much as expected, provided you remember to use a certificate based on the RAS and IAS Server template for the RADIUS server, as noted above. The PKI book devotes a chapter to each of these, and the coverage is extensive. My Wireless network uses PEAP/TLS authentication, and my VPNs either PPTP with EAP authentication, or L2TP/IPSec. I have noticed one quirk with wireless. Unless I have completely misunderstood the documentation, it should be possible to use smartcard authentication with wireless. In fact this doesn’t work. You can use a smart card to log on to the client machine, but the RADIUS authentication uses a user certificate stored on the client machine (and thus configured). But if the option to use a certificate on smart card, rather than locally stored, is chosen, then nothing works – the initial mutual authentication between the client machine and the RADIUS server does not take place, nor does the user logon authenticate to RADIUS (and in fact the client machine quickly locks up, and has to be closed down forcibly).

Encrypting File System
This has enough quirks to merit a section to itself.

For EFS to be available, it must be enabled by group policy. The setting is:
Computer Configuration/Windows Settings/Security Settings/Public Key Policies/
Encrypting File System. Right-click on this to get properties; there is only one setting – Allow users to encrypt files using EFS. This must be selected, as it is by default. If this setting is deselected anywhere, then EFS is disabled on all machines to which that GPO applies, irrespective of any GPOs applied later – i.e. once disabled, this cannot be overridden. EFS-disablement manifests itself as a registry setting:
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\EFS\
EfsConfiguration with a DWORD value of 0x01. A value of zero (or the key’s absence) enables EFS.

To be able to use EFS, a user needs a certificate with the Encrypting File System application policy. The v1 User template or a v2 template based thereon has this already. (You could use EFS without a PKI, whereby the client machine generates its own self-signed certificate, but this is strongly deprecated.)

For safe usage of EFS, one or more Data Recovery Agents is needed, to be able to recover encrypted files, if the user’s private key becomes lost or inaccessible. (Alternatively, it is possible to archive encryption keys on a Certificate Server; I much prefer the DRA approach.) A DRA is a user with a certificate which includes the File Recovery application policy. These must be set up before starting to use EFS, and how this is done is somewhat counter-intuitive.

DRAs are defined by group policy. Right click the GP setting Encrypting File System mentioned above, and (inter alia) two relevant settings are offered: Add Data Recovery Agent and Create Data Recovery Agent. It is possible to enrol an EFS Recovery Agent certificate directly by the relevant user, using the Certificates MMC snap-in or the Certificate Server Web Interface. It might reasonably be expected that these could then be added to the EFS Recovery Policy. Not so. Trying to add an agent in this way, by selecting the appropriate user, merely reports that that user has no suitable certificate available (but see immediately below). The certificate has to be created explicitly by the group policy configuration tool, typically the Group Policy Management Console, using the Create Data Recovery Agent option. Since this operation is performed by the DRA user concerned, this user must be a Domain Admin just to be able to edit the group policy (if for no other reason). The PKI book does mention this method, almost in passing (chapter 16, p363/4), but completely omits to highlight its incongruity. This applies to the v1 EFS Recovery Agent template, and to a v2 template derived from it. So what’s the Add Data Recovery Agent option for? Two things. It’s possible to import a certificate enrolled in the usual way, by specifying a *.cer file – i.e. an export of the certificate not including the private key. Alternatively a DRA user can be selected provided the certificate is based on a v2 template which has been edited to publish the certificate in AD, which is not the case by default. If you squint at the tiny descriptive text on the Select Recovery Agents screen of the Add Recovery Agent wizard, (but nowhere else that I’ve found,) you can see that this is in fact explained.

A final quirk. If you are creating a DRA from GPMC, a selection of available templates is offered (with v1 EFS Recovery Agent selected by default, if available). But there is nothing to stop you selecting an entirely inappropriate template; GPMC reports an error but it does actually create the agent with a certificate of that type. (It doesn’t seem to work for EFS recovery, however!)

Secure E-Mail
It gives me pleasure to report that this works pretty much as it should. But still, some points are worth noting.

Secure e-mail is controlled from the e-mail client. In Outlook (2003), it is configured from Tools/Options/Security. The first two options – Encrypt contents and attachments for outgoing messages and Add digital signature to outgoing messages are self-explanatory. The third option – Send clear text signed message when sending signed messages apparently means that recipients whose e-mail client does not support S/MIME signatures are allowed to read the message without verification of the digital signature – I have to take this on trust; it is presumably relevant only for non-encrypted e-mails. The fourth option – Request S/MIME receipt for all S/MIME signed messages means that the recipient returns a digitally-signed S/MIME receipt when the message is first opened. ‘Request’ is something of a misnomer – it happens automatically, without the recipient knowing anything about it. Note, however, that it happens only if the recipient actually is able to send signed messages, if not, no receipt will be sent. (This is reasonable: how can you trust a receipt if it isn’t signed?)

In order actually to be able to perform the desired actions, the user must have the appropriate certificate(s). Note that encryption and signing are entirely independent processes; either could be present alone, or both. They would normally rely on the same certificate, but this is not necessarily so. In fact (anticipating the next section) certificates on smart card are available only for digital signing; they will not enable encryption. The same application policy extension, Secure Email, is used in smartcard templates as in non-smartcard templates; this is misleading as with smart cards it only does half the job.

The actual certificate settings are defined in the Change Security Settings screen, invoked by the Settings button. A default configuration My S/MIME Settings (<username>) is set up automatically. (It is possible to create alternative settings, but only one is in use at one time, and switching between them is rather tedious.) The important settings in the present context are the Signing Certificate and Encryption Certificate. These allow a selection from the relevant certificates owned by the user (smart card certificates do not appear in the Encryption Certificate selection). Note that the encryption certificate is the one that other users should use to send encrypted mail to the current user (of course). The Hash Algorithm and Encryption Algorithm fields automatically default to the most secure options available. An interesting option is Send these certificates with signed messages. This means that the signing certificate gets sent along with the message, so the recipient, wherever they are, can check the signature, and thus be sure of the message’s integrity (provided of course that their e-mail client supports digital signing, and that they trust the user’s Root Certification Authority). It would also seem to imply that the encryption certificate, if different, gets sent along too (so the recipient can send encrypted messages back), but I haven’t checked this out, yet, and I haven’t found any documentation about it.

Any user with an appropriate certificate can send signed e-mails. But to send encrypted e-mails, the encryption certificate of the recipient is necessary. (If the user does not have this, it doesn’t cause an error – a warning is displayed and they are given the option to send the e-mail unencrypted.) If the recipient is internal to the organisation, then this would normally be obtained from Active Directory – the relevant certificate template(s) have the Publish Certificate in Active Directory option – the v1 User template, and a v2 template derived from it, have this by default. If the recipient is external to the organisation, their certificate would be held with the relevant entry in the user’s Contacts list. It can be imported there from an electronic copy, or, I imagine (and hope) from an e-mail where it had been automatically included, as noted above.

One final point about certificates published to A-D: once published, they just stay there, even if the original certificate gets revoked (or simply expires?) The only direct way to get rid of them seems to be by Active Directory Users and Computers, in the Published Certificates tab of the user’s properties. There should only ever be one certificate per user, for a particular purpose, in AD, otherwise confusion can (will!) occur. In carrying out my various tests, all sorts of crap built up in AD, and I found, when testing secure e-mail, that certain users could read encrypted e-mail and others couldn’t – the error reported was: ‘Can’t open the item. Your Digital ID name can not be found by the underlying security system.’ What had happened was that the sender had picked up an old, redundant certificate from AD that the user no longer had. (The error message did indeed say what it meant, but the implication wasn’t immediately obvious.) Clearing out the rubbish from AD cleared the problem.

Smart Cards
Smart cards are a serious disappointment. It seems that, with one exception, you can do nothing more with v2 templates than was possible with v1 – i.e. just the basic provision of smartcard logon and client authentication and, optionally, secure e-mail (signing only).

Smart cards need to be enrolled on behalf of users, by a security principal authorised to do so by an enrollment agent certificate. (The security principal can be either a user or a computer.) This enrolment is performed using the Web interface to the Certificate server. But this is evidently hard coded to offer only the two standard v1 templates, Smartcard Logon and Smartcard User – even if there are v2 templates on offer, this utility doesn’t recognise them. (This could well be another example where you would continue to use v1 templates with an EE Certificate Server.) You can indeed define v2 templates for smart cards, but certificates based on them have to be enrolled by the individual user, which is very undesirable. Given the above restrictions, enrolment by agent does work. The enrolment agent certificate can be based on a v2 template, and in fact it can even be on a smart card! (This is the one exception, mentioned above.) The PKI book mentions this in passing, but makes the important point that the CSP of the enrolment agent certificate on smart card must be different to that of the smart card certificates being enrolled (which is not a requirement if the enrolment agent certificate is not on smart card). It also – chapter 15, p.342-345 - details the settings which must be made to Internet Explorer to allow this Active-X control to run. I find that the user performing the enrolment on behalf of other users must be a Domain Administrator, otherwise that feature of the Web interface is not available; I have not seen this documented.

I have checked out enrolment agent certificates on smart card, and find, rather to my surprise, that it does in fact work! (My second CSP was not one of those included as standard in Cryptographic Services, and getting it installed was a rather fraught process. This will be the subject of a later article.)

One reason you would definitely want to use v2 smartcard templates is to configure the Cryptographic Service Provider. Most organisations would probably choose to standardise on a particular type of card, and it would thus make good sense to configure templates specifying that particular CSP, otherwise you would have to specify the CSP explicitly for each card issued (unless your CSP happened to be Gemplus – first on the list and the default; I mostly use Schlumberger – last on the list).

As mentioned previously, you can configure templates however you want, and Certificate Services will issue certificates based thereon. This applies equally to smartcard certificates. But whatever you want, all you can actually do with smart cards is log on, and sign secure e-mail (and, surprisingly, enroll further smart cards). The following important things you cannot do with smart cards, no matter how much you might want to:
• Encryption, so you cannot use EFS nor send (*) encrypted e-mail. This is a published restriction, but no less frustrating because of that. This means that the relevant private key must in general be stored in filestore on the same machine as the encrypted files, severely compromising their security. Presumably recovery agent certificates can’t be on smart card either.
• Code signing. To my surprise, I found I could not use a smart card to sign PowerShell scripts. This is a new product, and I thoroughly approve of its requirement that scripts be signed (unless you deliberately configure it to be insecure), so I was surprised to encounter this restriction. I have to admit this is a less crippling deficiency, in that code signing is most likely to be done on a secure machine, rather than a laptop.
(* I should rather say receive encrypted e-mail, i.e. you cannot use the private key on the smart card to decrypt e-mail sent to you encrypted using the certificate on the smart card – which like all certificates, i.e. public keys, is publicly available – indeed the sender cannot use that certificate for that purpose. I deliberately leave the original formulation as it is a good example of an aspect of PKI that I have encountered several times in writing about it: the natural way to say or write something is often not strictly correct – it can indeed be the precise reverse of the truth, as here – but that stating the case with strict accuracy often sounds long-winded and pedantic.)

What happens when a smart card is removed from the reader is determined by group policy. The setting is Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Interactive Logon: Smart card removal behaviour, and the options available are:
• No Action
• Lock Workstation
• Force Logoff
The standard security templates Secure Workstation and Secure Domain Controller set Lock Workstation and Force Logoff respectively. I recommend these settings for every level of security. The policy setting Computer Configuration/…/Interactive Logon: Require smart card enables the use of smart cards to be enforced – i.e. username/password interactive logon is not available. I certainly recommend this setting for laptops and probably all client machines. It’s an open question for servers; you will definitely need at least one machine where smart cards are not enforced, in case of problems with your PKI.

A Note on Autoenrollment
Autoenrollment of certificates might sound a good idea, and to a degree it is, but there are potential dangers that have to be considered.

It is available with v2 templates in general. It is enabled by allowing the Autoenroll permission (together with Read and Enroll, of course,) in the template’s security settings, to the relevant security principals (users or computers). It must also be enabled by group policy – the setting is:
Computer Configuration/Windows Settings/Security Settings/Public Key Policies
(right click)/Properties. If Enroll Certificates Automatically is selected (as it is by default), then certificates will be enrolled automatically for all templates configured to allow this. There are two subsidiary options:
• Renew expired certificates, update pending certificates, and remove revoked certificates – which is self-explanatory, and
• Update certificates that use certificate templates – apparently (the associated help text is less than helpful) this enables autoenrollment of new certificates, to replace existing certificates generated to a superseded v1 template. (When creating a v2 template by duplicating a v1 template, you normally configure it to supersede the associated v1 template, though this setting is not automatic. So, if there are existing certificates whose validity is not yet expired, they are nonetheless replaced by certificates to the new template. I believe that, as a corollary, if a v2 template is subsequently changed, any certificates autoenrolled to that template are replaced by certificates autoenrolled to the new template.)
Both these options seem advisable, but I recommend against changing a template once it’s gone into service – instead, duplicate it if necessary, to create a new one, which doesn’t supersede the original.

Again, to the best of my understanding, when a certificate is expired, and renewed automatically, the same key pair is used for the new certificate. (If this were not the case, all sorts of problems would arise with applications dependent on the original key pair no longer working.)

Autoenrollment is also available to a limited degree with v1 templates, but only selected ones (specifically Computer, Domain Controller, Enrollment Agent (Computer) and IPSEC), and is controlled by group policy, specifically the
Computer Configuration/Windows Settings/Security Settings/Public Key Policies/
Automatic Certificate Request Setings(right click)/New/Automatic Certificate Request Settings. I can think of no good reason still to be using these templates if v2 templates are available.

I recommend autoenrollment for certain computer certificates only, specifically for the v2 templates Domain Controller Authentication, Computer v2 and IPSec v2, the latter two being created directly from the corresponding v1 templates. All computers need these (as relevant); and it’s a great help to have them obtain and renew them by themselves; computers are unique and there is no possibility of ambiguity. I recommend against autoenrollment for any user certificates. Unless roving profiles were in use, whenever the user logged on to another machine, another set of certificates would be autoenrolled. If these were published in AD (as is very desirable for certain applications such as secure e-mail) then the scope for ambiguity and confusion can be imagined. Evidently autoenrollment is also available for smart card certificates. The user would be prompted to insert a card, and to supply various information to set up the PIN, for example. I find this prospect profoundly worrying. All in all, in my opinion autoenrollment for user certificates has potential dangers which negate any convenience advantage it offers.

Note that autoenrollment is available only with Windows XP or later.

Conclusions
A mixed bag. Some very useful enhancements are available with Enterprise Edition Certificate Servers, but there are many quirks, and a few serious disappointments too.

It is now my opinion that private keys should never be held in filestore, but that all user private keys should be on smart card, and all computer private keys should be on a Hardware Security Module / Trusted Platform Module. This offers the highest probability of preventing them from being accessed illegitimately. (It also, unless I have completely misunderstood the situation, means that the private key cannot be duplicated elsewhere – it exists on the card and nowhere else.) This ideal is not achievable with the current software.

However, I understand that the provision in Vista/Longhorn is significantly enhanced, and I believe that the restriction on smartcards being used for encryption will be lifted. If this is the case, then my ideal configuration should soon be available.