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
Please note: the following post describes a procedure which require Active Directory Certificate Services in an Active Directory environment, as well as Windows 2008R2 domain controller in order to work.
In order to configure the certificate template needed for SSL in RDP connections, we could create a new template based on the existing “Computer” one, via duplication (of course we could duplicate another one, but for the sake of this example we chose the Computer template). When the duplicated template settings appear we should change the following:
a) [optional] change the name and display name of the template to something descriptive of our deployment, for example “RemoteDesktopComputer” (the existence -or not- of spaces is irrelevant in ADCS)
b) [optional] change the validity of the certificate to something different than the default value
c) [required] In the “Extensions” tab, delete the “Server Authentication” and “Client authentication” Application Policies and add the “Remote Desktop Authentication” application policy.
d) [required] Configure Group Policy – we must choose whether to create a new group policy object or configure an existing one (example, default domain policy) with the following settings:
- On a domain controller, start the “Group Policy Management” administrative tool.
- Right-click the “Default Domain Policy” and click on “Edit…” in the menu that appears. The “Group Policy Management Editor” appears.
- Navigate to “Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security.”
- Double-click the “Server Authentication Certificate Template” policy.
- Enable the policy, type “RemoteDesktopComputer” (or whatever other name we gave to the template) in the “Certificate Template Name” box, and then click “OK.”
- As soon as this policy propagates to the computers that are affected by it, every server that has Remote Desktop connections enabled will automatically request a certificate based on the “RemoteDesktopComputer” template from the Certification Authority server and use it to authenticate to Remote Desktop clients. You can speed up the propagation to a specific machine by running the “gpupdate.exe” command line tool locally .
Manual Remote Desktop Connection check and configuration for Windows 2008/R2 Terminal Services servers
After the issuance of the certificates for Windows Server 2008/R2 servers, we may manually check each Windows Server 2008/R2 server as follows:
- Open Remote Desktop Session Host Configuration, in Administrative Tools, in the middle pane, we should right-click RDP-Tcp and select Properties.
- In the Select button, make sure that the certificate selected comes from the name of Issuing CA, for example ABC Bank Issuing CA. A previously issued certificate for an existing service on a server could conflict with the ones we have issued via the RDP method.
I was once contacted by one of our enterprise customers to troubleshoot a strange client-side PKI problem – an email encryption certificate could not be issued for some specific PCs.
One of the problematic clients was a Windows 7 PC. Upon starting my troubleshooting session, I saw the “One of the CA certificates is not trusted by the policy provider” event.
This usually indicates that the Issuing CA’s certificate is not published in the NTAuth container of the Active Directory. In that case, the solution would be easy and we would just need to run certutil -dspublish -f IssuingCAcert.cer NTAuthCA so as to populate the container with the missing certificate. However, this was not the case, since most clients would successfully autoenroll for an encryption certificate – the problem was present only in specific PCs.
After digging some more into the registry, it was evident that something to that effect was happening – but this time, in the client-side PKI structure. Windows PCs cache whatever certificates are found in the AD NTAuth container at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates]. This key would contain (cache) all NTAuth certificates which are propagated via group policy, which should also contain autoenrollment settings. What was found in the particular PC is that the client-side NTAuth cache was totally empty, which meant that either the NTAuth AD container
was empty (we rejected this based upon our previous observations) or the client could not successfully process its GPO(s). After running RSOP locally and opening the Group Policy Management console, we saw that the client was in an OU where the autoenrollment & encryption GPOs did not apply.
After we moved the PC to the expected OU and GPOs started “flowing”, the NTAuth client-side setting was populated and the autoenrolled encryption certificate was installed successfully.
During a recent smart card logon certificate deployment for a customer, we decided to enable the policy which disconnects a user who has logged in using a smart-card via an RDP connection if the smart card is physically removed (“Interactive logon: Smart card removal behavior” set to “Disconnect if a remote Remote Desktop Services session”). We tested it by starting the Smart Card Logon removal service (it was in manual startup state) in the Windows 2008R2 server and when we removed the smart card, the session was indeed disconnected. However, we noticed that at subsequent logons, when the smart card was re-inserted the user would login but would be immediately disconnected. After some troubleshooting, we tried disabling the Fast Logon Optimization feature (http://support.microsoft.com/kb/305293/en-us) via GPO, and after that the problem was solved. Thus, if you find yourself tackling with the same issue, it might be useful to add a custom smart-card GPO that will also force the Smart-card removal service to Automatic and disable the Fast-Logon feature and check if these actions solve your problem.
A new PKI-related hotfix has been released recently, that mitigates a problem which results in poor performance of Windows 2008R2 domain controllers and services that depend upon them (practically anything from slow user logons to Outlook timeouts).
Although there are several non-PKI parameters that might create such a problem, one more has been recently identified and a hotfix has been issued fir it – and that is slow CRL fetching. This is more likely to happen in environments were hundreds or thousands of domain controllers operate and/or CRLs have become excessively large (the article states refers to CRLs larger than than 20MB). You can find the related hotfix here.
During a session in TechEd 2013, Nelly Porter, Principal Lead Program Manager, Windows Security, announced that Windows 8.1 will natively support the SCEP protocol for mobile device certificate issuance. It is not immediately clear whether the RT version will also get the new feature; it is clear, however, that the RT version would benefit a lot from such an addition.
Microsoft’s SCEP server-side implementation (which goes by the name of NDES) has been introduced long ago by Microsoft in its PKI offering; first as an add-on to Windows Server 2003 and then included in Windows Server 2008/R2/2012. Of note is that several vulnerabilities that were found in the server-side component have now been patched.
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.]