Recently I’ve been seeing a lot of customers moving to Windows 10, managed via Intune and Azure Active Directory Joined only.
Typically, those same customers will also already have an existing Internal Public Key Infrastructure (PKI); Windows domain joined clients in the old world will have root and issuing CA certificates present possibly configured to be used in wireless authentication, they may also have unique user or device certificates issued via permission on specific certificate templates and autoenrollment – used in VPN authentication for example. This leads to questions about deploying such certificates going forward – there is no on-premises domain connectivity and no group policy in the new world.
How do we obtain Certificates?
Certificates can be purchased from commercial Certificate Authorities for a cost and are suitable in certain circumstances where a certificate needs to be widely trusted by internal and external clients, e.g. protecting a public facing web site. Internal Windows Servers can be configured as an Internal PKI hierarchy, and certificates from an internal PKI are typically used in internal client /server authentication. Regardless of whether a certificate is from a 3rd party or an internal CA, it is important that if a certificate is issued it can be trusted as being legitimate, so root and issuing CA certificates are required alongside an issued certificate to provide a chain of trust.
The old world
How certificates were traditionally deployed?
In the Windows world, clients have a user personal and a computer personal certificate store, as well as stores for trusted root and trusted intermediate certificates which can be viewed from a Microsoft Management Console with the appropriate rights. Mobile Phone clients also have certificate stores, variable according to manufacturer.
If a company purchases 3rd party certificates and requires their clients to trust certificates from these authorities, the root and intermediate certs can be pushed to Windows clients via GPO.
If a company has an Internal CA, the root CA certificate from a hopefully offline, non-domain joined root would be published in AD, and the Enterprise issuing CAs certificates would automatically be published. Windows domain joined clients automatically get these certificates into their trusted root and trusted intermediate stores. This means if they receive a certificate from the internal CA, it is automatically trusted for use. If a server is in a workgroup, the root and issuing CA certificates can be exported and installed in the appropriate stores manually. For mobile devices, a device management solution would have been used to deploy root and intermediate certificates to the certificate stores, I’ve come across Airwatch for example being able to do this.
In the old world, how then would I get a User/Computer certificate?
Clients may need unique user certificates e.g. for user authentication to VPN, Client Computer Certificates if using Certificates with SCCM, some internal websites on internal servers may be protected with https.
These certificates are generated from a whole load of settings regarding OS compatibility, who can obtain it, how it is build and what purposes it can be used for. AD Certificate services has default templates which can be (and should be) duplicated and tweaked to match certificate requirements, for example User, Workstation Authentication, Web server. Certificate templates are held centrally in AD but made available – published – on Issuing CA servers.
The template security settings define who can enrol for a certificate and can be split in to enrol or Autoenroll. Enrol permission allows users/computers to enrol for a certificate manually (would have to also have to be re-enrolled for manually when it expired) Autoenroll allows certificates to be automatically enrolled for and renewed if the appropriate boxes are checked in the GPO.
If the following settings are configured at:
Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Service Client – Auto-Enrolment
User Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Service Client – Auto-Enrolment
These settings enable autoenrollment to happen and can be set either at the domain / specific OU level. If a computer or user falls under this GPO scope e.g. can Autoenroll and has autoenrollment permissions on a certificate template that is published, it will receive that certificate in to either the user or computer personal store.
Non domain joined computers e.g. those on a DMZ can still have user/computer certificates if required, however a certificate request would need to be generated (usually via an application e.g. IIS, Skype Admin Tool or certutil commands) resulting in the generation of the appropriate req file locally which can then be completed by various means such as Certificate Enrolment web pages or copying the req file and completing the request on the CA.
So in summary in the old world we rely heavily on AD and AD group membership for certificate deployment; for non-domain joined devices, getting the root and issuing certificates installed and deploying a user / computer certificate is perfectly possible, but a fairly manual process.
The new world
Increasingly we are seeing customers who have devices managed via Intune, only Azure AD joined. So no on premises domain, and no GPO settings to manage PCs. How do we get our internal PKI certificates that use in Wi-Fi and VPN on to these?
How do we deploy certificates?
Any Internal PKI should be fit for purpose – don’t want to get into a debate on recommended practice but it needs to be secure and resilient. We need the new world management product e.g. Intune to be able to deploy root and issuing CA certificates and enrol the user or device for user and device certificates if there is a requirement.
Trusted profile
Root and Intermediate certificates CA certs can be deployed via Trusted profiles, any subsequent user or device certificates issued by that CA will need to have a complete chain of trust present. This requires:
- An Internal Certificate authority.
- Configured Intune setup, and devices managed by Intune.
- Files of exported root and issuing CA certificates that you wish to deploy.
During the creation of the trusted profile, the exported certificate is uploaded to Intune and the store it is installed in to (e.g. Trusted root / Trusted Intermediate) can be specified.
Currently, the following clients support Trusted Profiles:
iOS 8.0 and later
macOS 10.11 and later
Android 4.0 and later
Android Enterprise
Windows 8.1 and later
Windows Phone 8.1 and later
Windows 10 and later
So a trusted profile can be used to deploy internal root and issuing CA certificates, and other CA certificates that need to be trusted by Intune managed clients.
Unique User or Device Certificate from Internal CA via Intune
Here is where it gets slightly more complicated. In order to get a unique certificate, be that user or computer from the Internal CA, Intune and the Internal CA need to be able to chat. This is where connectors come in to play; these can be downloaded from the Intune portal and there are different types depending on intended usage.
User
If a unique user certificate is required, a PKCS profile would typically be configured. Unless there is a requirement for MacOS or Windows phone devices to have user certs in which case a SCEP user profile is needed.
PKCS profiles require:
- An Internal Certificate authority.
- Configured Intune setup, users present in Azure AD and devices managed by Intune.
- A server or servers to install the Intune PKCS connector on (not the CAs).
- An appropriately configured certificate template on the Internal PKI for the PKCS user type published on the Issuing CAs.
With the infrastructure in place, a PKCS profile can be used to deploy user certificates to users via Intune.
Device
PKCS profiles do not support the deployment of unique device certificates. So, if there is a requirement for a unique device certificate on an Intune managed device this can be done via a SCEP profile. More infrastructure and configuration are required, so more complicated and time consuming than configuring a PKCS user profile.
SCEP Profiles require:
- An Internal Certificate authority
- Configured Intune setup, users present in Azure AD and devices managed by Intune.
- The Network Device Enrolment Service (NDES) a PKI component, installed on a separate server or server(s) to the Certificate Authority.
- Intune SCEP (NDES) connector installed and configured on the NDES server(s)
- A means of reverse publishing the NDES SCEP URL accessible to the internet (e.g. Azure app proxy)
- An appropriately configured certificate template published on the Internal PKI to allow Intune / NDES to enrol for device certificates.
With the infrastructure in place, a SCEP profile can be used to deploy user certificates to devices. A SCEP User profile can be used to deploy user certificates to MacOS and Windows Phone devices.
Additional guidance on how to configure these components and profiles can be found in the current Microsoft Intune documentation, but thought this was worthy of a summary of how the old world differs from the new, and the questions that seem to be coming up around Intune certificate deployment now.
