After a long time of inactivity, we are back with the second part of this mini-series of the virtual smart card deployment guide.
Luckily (or, should we say, by careful design?) there are very few things to configure in the Outlook client. The certificate(s) that we are going to issue, either encryption or digital signature ones (or both), are going to be immediately recognized by Outlook. Subsequently, they are going to be placed in the correct containers, which can be seen by taking a look at File -> Options -> Trust Center -> Trust Center Settings -> Email Security -> Settings. There, we can find the relevant text box which will indicate the encryption and the signing certificates. If we create two different certificate templates for the relevant purposes, Outlook will automatically understand the purpose of each certificate and place each one in the correct container. If we create one certificate for both purposes, which is not recommended due to the sensitive nature of the signing operations, Outlook will use this one for both operations and you will see it both text fields in that window.
One more thing to note about Outlook is that the sign and encrypt buttons will appear in the Outlook’s “New Email” window only after the first encryption or signing takes place. This is a bit awkward for users. One way to circumvent this behavior, and thus “instruct” Outlook to always show the buttons, is to push a specific registry to Outlook clients. This key can be found at HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Preferences. The new entry should be SecurityAlwaysShowButtons (as a DWORD) with value 1. This example refers to an Outlook 2013 client, so for previous versions of Outlook, we need to replace 15.0 with the specific version (for example, 14.0 for Outlook 2010 etc.)
Creating the virtual smart card
We create a virtual smart card in the user’s PC by opening an administrative command prompt and running the following command: tpmvscmgr.exe create /name VSC /pin prompt /adminkey random /generate. Let’s explain what this command’s parameters mean (more information can be found in the Understanding and Evaluating Smart Cards document):
- name refers to the name that we give to the virtual smart card – it could be anything we choose.
- Pin is, of course, the PIN that protects the VSC – in this case, prompt prompts the user to enter one of his/her liking. It is highly advisable that, at this point, the PIN should be entered by the user and be known only to him/her. The documentation has small error at this point.
- Adminkey is the administrator key that can be used to administratively access the VSC and reset it, if locked
- Generate is needed if we are not using FIM CM for the creation of the VSC (which, by the way, is highly recommended for most demanding deployments)
The process of TPM virtual smart card creation will take some time (usually around 2-3 minutes, depending on the hardware). You have to wait until the final confirmation by the system is displayed. The Instance ID of the virtual smart card reader should appear as ROOT\SMARTCARDREADER000 by default. We can also verify the creation be checking the Device Manager, where we will find the newly created reader with the name that was entered at the creation command.
In the next post, we will share some final details on VSC creation and Outlook.
VSC in Device Manager
Process of virtual smart card creation
On August 13th, Microsoft released a security advisory update (2862973 – Update for Deprecation of MD5 Hashing Algorithm for Microsoft Root Certificate Program), applicable to Windows Vista/2008 and later client and server operating systems. According to the associated TechNet article (Protecting Against Weak Cryptographic Algorithms) the functionality is already built into Windows Server 2012R2 and Windows 8.1 preview editions and should be included when the final bits of 2012R2 and 8.1 ship. Essentially, this update gives administrators control on logging and/or blocking weak algorithm-based certificates that are known to be vulnerable to multiple attacks. More detailed information can be found on the link above.
A successful request for a certificate from a mobile device always depends on its operating system. Currently, all mobile devices (notebooks, tablets etc.) that rely on the Windows operating system can request certificates using the well-known MMC or web enrollment ways. Moreover, non-domain-joined clients can also request certificates using the CEP/CES services of Windows 2008R2 and above CAs.
Windows RT tablets, based on version 8.1, can also request certificates as we have already mentioned the inclusion of a SCEP client in Windows 81. at a previous blog post. However, certificate issuance for devices that depend on other, mobile-only operating systems such as iOS and Android, depend on the vendor. In this blog post, we will limit our scope to iOS 5.x devices. These devices support the SCEP protocol, which allows for certificate requests directly from the mobile OS. Microsoft supports SCEP via the NDES service of the Certificate Services role.
For this reason, we need to install the NDES feature of Windows CAs. We will also create a specific service account which will run NDES. The service itself will be installed on the existing Enterprise Issuing CA. Moreover, we will need to:
- run the following command for IIS:
%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/requestFiltering /requestLimits.maxQueryString:”3072″ /commit:apphost
- install post-Windows 2008R2 hotfix KB2483564 that is needed for correct parsing of iOS HTTP SCEP requests.
- install, in a test machine, the software needed to create profiles for iOS to request certificates (iPhone configuration utility)
- test certificate issuance using an iPhone
This is how we request certificates for SCEP-compliant devices (in this example, iOS devices):
First, we visit the URL http://issuingca/CertSrv/MSCEP_Admin/ where we receive the password (challenge) needed to complete the certificate issuance
Retrieving the challenge string from the NDES server
After we receive the challenge string, we start the iOS configuration software, move to the configuration profiles section and create the profile needed for the certificate request. We finally select SCEP and fill in all the required values of the form. A sample request form has been captured in the following screenshot as a reference.
SCEP selection from the iPhone configuration utility
The completed form of the iPhone configuration utility
Hello World! This is a blog that will try to uncover all the hidden gems (and problems, nonetheless) of the wonderful world of PKI. Stay tuned for frequent updates!
This blog is written and maintained by Dimitris Papitsis, Senior Premier Field Engineer for Microsoft Hellas with a specialty in PKI and Exchange Server [edit: now a Sr. IT Engineer in Microsoft corp.]