Some networks and internal web resources require users to authenticate themselves using a digital certificate. Client certificates allow users on devices running Chrome OS to access these types of networks and resources.
To enhance the security of networks and internal resources, organizations authenticate users on employee and student devices using client-side digital certificates. For example, EAP-TLS (802.1x) authentication to allow access to LANs and mutual TLS/SSL authentication to allow access to internal web resources.
There are several steps to put a client certificate on a device, including:
- Generating a key pair securely on the device.
- Sending the public key as well as other identifying and authenticating information to a certificate authority (CA) to obtain a certificate.
- Importing the certificate to the device
Different CAs support different enrollment protocols, such as SCEP and EST, and organizations have specific workflows, checks, and rules that have to be checked before granting a certificate.
Manage and provision client certificates
Starting with Chrome version 37, partners, such as CAs, infrastructure management vendors, and customers, can write an extension using the chrome.enterprise.platformKeys API to provision client certificates on Chrome devices. By using an extension, a wide variety of CAs, enrollment protocols, and any form of web-based workflow can be supported. Customers using Windows Active Directory Certificate services can use Google's Enterprise Enrollment tool to request and install certificates for Chrome devices. For more information, see Let users request digital certificates. Using extensions is a flexible way to provision client certificates. It ensures that the private key never leaves the device and is backed by the Chrome Trusted Platform Module (TPM).
When the chrome.enterprise.platformKeys API user Token is used (id equals "user"), client certificates obtained using extensions are unique to a user and device. For example, a second user on the same device has a different certificate. When the user signs in to another device, a different certificate is issued by the CA. Because client certificates are backed by the TPM, the certificate can't be stolen and installed on another device or be hijacked by another user. When you remove a user from a device, the certificate is removed as well.
These certificates can also be used by extensions, such as VPN clients using the chrome.platformKeys API. Access to the certificates is granted in different ways depending on whether an account is managed or not. For more information, see Access model for extensions and client certificates.
To provision client certificates using an extension:
- Verify that you have a Chrome service. See Chrome service options.
Your Admin console makes it easy to deploy and control users, devices, and apps across all Chrome devices in your organization.
- Obtain an onboarding extension using the chrome.enterprise.platformKeys API that implements your onboarding workflow and integrates with your CA.
Go to the Chrome Web Store to find an extension for the CA you use. If an extension doesn’t already exist for the CA, you can build one yourself or hire a consultant or vendor to build one for you. For more information, see the Developer Guide.
- Force-install the extension for your users. The chrome.enterprise.platformKeys API is only available to extensions that are force-installed by policy. See Automatically install apps and extensions.
- Verify that the network is configured so users in the guest or onboarding network can connect to it, and so the guest or onboarding network can communicate with the CA.
In most cases, a guest or onboarding network does not have privileged access, so it can be used only to browse the extranet and to reach the CA for certificate onboarding. The certificate onboarding process can be initiated using this network. You can pre-configure the guest or onboarding network on all the Chrome devices that you manage. For more information, see Manage networks.
- Verify that each Chrome device is enrolled in the domain. Only users in the domain where the device is enrolled can use the device certificate. See Enroll Chrome devices.
As an administrator, you can configure the enrollment flow for user and device certificates.
User certificates are bound to a managed user’s session. They can be used for user-level authentication to websites, networks, and third-party applications.
Device certificates are bound to a managed device. They’re exposed in multiple places, such as:
- Affiliated user sessions for users who are managed by the same domain as the device.
- Chrome sign-in screens, where the certificates are surfaced to networks and as part of the third-party SAML sign-in flow.
Note: Device certificates are only surfaced in a third-party SAML sign-in flow if you configured the Single Sign-On Client Certificates policy.
- Devices in managed guest session and kiosk mode, where the certificates are surfaced to websites, networks, and third-party apps.
To configure an extension for user and device certificates, see the extension’s certificate enrollment documentation.
From a guest or onboarding network, the user attempts to connect to the EAP-TLS (802.1x) network for the first time. At this point, the extension that you force-installed guides the user through a set of steps (including authentication) before installing the certificate issued by the CA. When the certificate is installed, the user can select the EAP-TLS (802.1x) network and successfully connect.
When an internal webpage requires mutual TLS/SSL authentication, the internal web resource displays a message to the user that a certificate is required. At this point, the user can launch the extension that you force-installed, go through a similar set of steps as described for connecting to an EAP-TLS network, and refresh the browser to access the internal webpage.
The chrome.platformKeys API allows extensions and apps, such as VPN, to access client certificates managed by the platform. The permission model governing their use depends on whether the user account is managed or unmanaged. The following applies regardless of whether the device is enrolled or not.Unmanaged account
When the user signs in with an unmanaged account, such as their personal account, they own and are under full control of the certificates that have been manually imported onto the device. In this scenario, the user can grant a specific extension the permission to use chrome.platformKeys to access a particular certificate. There are no further restrictions.Managed account
When the user signs in with a managed account, such as their work account, the administrator is in charge of granting access to certificates that are meant for corporate usage. The administrator does that by specifying extensions that are allowed to use client certificates.
To specify extensions that can use client certificates:
From the Admin console Home page, go to DevicesChrome management.
If you don't see Devices on the Home page, click More controls at the bottom.
- Click Apps & extensions.
- To apply the setting to everyone, leave the top organizational unit selected. Otherwise, select a child organizational unit.
At the top, click the type of app or extension that you want to configure.
Find and click the app that you want to manage.
In the panel on the right, under Certificate management, turn on Allow access to keys.
Note: If you don’t see the setting, the app you selected does not support certificate management.
- Click Save.
The user isn't asked to grant permission to access certificates, and only certificates that have been imported using the chrome.enterprise.platformKeys API qualify for corporate usage. An extension can still ask the user to select a certificate if the extension has access to multiple certificates. Any certificate that is generated or imported by other means, such as manually, is not available for the API for managed accounts.