A key principle of Chrome Enterprise Premium is that access to services is granted based on what we know about you and your device. The level of access given to a single user or a single device is dynamically inferred by interrogating multiple data sources. Chrome Enterprise Premium uses this level of trust as part of its decision process.
Access Context Manager is the zero trust policy engine of Chrome Enterprise Premium. Access Context Manager lets you define fine-grained, attribute-based access control for applications and Google Cloud resources.
Use access levels to permit access to resources based on contextual information about the request. By using access levels, you can start to organize tiers of trust. For example, you might create an access level called High_Level that permits requests from a small group of highly-privileged individuals. You might also identify a more general group to trust, such as an IP address range that you want to permit requests from. In that case, you might create an access level called Medium_Level to permit those requests.
One of the key requirements for zero trust access is to only allow access when the device is managed or owned by the company. There are several ways to determine whether a device is a corporate owned. One way is to determine whether a valid certificate, issued by the company, is on the device. An enterprise certificate on a device can indicate that it's corporate owned.
Enterprise certificates for Context-Aware Access is a feature of the overall Chrome Enterprise Premium certificate-based access solution. This feature uses device certificates as an alternative context-aware signal to determine whether a device is a corporate-owned asset. This feature is supported on Chrome browser version 110 or later.
Because a device can have more than one certificate, you can access enterprise certificates in the custom access level through the macros .exist(e,p):
device.certificates.exists(cert, predicate) In the example, cert is an identifier used in predicate, which binds to the device certificate. The exists() macro combines per-element predicate results with the "or" (||) operator, meaning that macros return true if at least one certificate satisfies the predicate expression.
The certificate has the following attributes that can be checked together. Note that string comparisons are case-sensitive.
| Attribute | Description | Example predicate expression (where cert is an identifier of macros) |
|---|---|---|
is_valid | True if the certificate is valid and not expired (boolean). You can't use this attribute with Endpoint Verification, because Endpoint Verification doesn't check certificate revocation. | cert.is_valid |
cert_fingerprint | Fingerprint of the certificate (base64 unpadded SHA256). The fingerprint is the unpadded base64 encoded SHA256 digest, in binary format, of the DER-encoded certificate. You can generate the string from the certificate in PEM format using the following procedure with OpenSSL:
| cert.cert_fingerprint == origin.clientCertFingerprint() |
root_ca_fingerprint | Fingerprint of the Root CA certificate used to sign the certificate (base64 unpadded SHA256). The fingerprint is the unpadded base64-encoded SHA256 digest, in binary format, of the DER-encoded certificate. You can generate the string from the certificate in PEM format using the following procedure with OpenSSL:
| cert.root_ca_fingerprint == "the_fingerprint" |
issuer | Issuer name (fully expanded names). To find the issuer name, you can use the following approach: Run the following command on the certificate: $ openssl x509 -in ca_1.crt -issuer issuer= /C=IN/ST=UP/L=NCR/O=BCEDemo/OU=BCEDemo_1/CN=inter_1/emailAddress=test_inter1@beyondcorp.in To get the issuer string for the access level, reverse the output and replace each forward slash (/) with a comma (,):
| cert.issuer == "EMAILADDRESS=test_inter1@beyondcorp.in, CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN" |
subject | Subject name of the certificate (fully expanded names). | cert.subject == "CA_SUB" |
serial_number | Serial number of the certificate (string). | cert.serial_number = "123456789" |
template_id | Template ID of the X.509 extension Certificate Template for the certificate (string). | cert.template_id = "1.3.6.1.4.1.311.21.8.15608621.11768144.5720724.16068415.6889630.81.2472537.7784047" |
The following table contains examples of policies that you can set:
| Example Policy | Expression |
|---|---|
| The device has a valid certificate signed by the company root certificate. | device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT") |
The device has a valid certificate issued by issuer CA_ABC. | device.certificates.exists(cert, cert.is_valid && cert.issuer == "EMAILADDRESS=test_inter1@beyondcorp.in, CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN") |
Configuring enterprise certificates
Before configuring enterprise certificates, make sure that you've configured custom access levels. For instructions, see Creating a custom access level.
You can use an Access Context Manager custom access level definition to set the appropriate policies. Custom access levels use boolean expressions written in a subset of Common Expression Language (CEL) to test the attributes of a client making a request.
Uploading trust anchors in the Admin console
For Chrome Enterprise Premium to collect and validate the device enterprise certificate, you must upload the trust anchors and any intermediary certificates that are used to issue the device certificate. The trust anchors are the self-signed root CA (Certification Authority) certificate and the relevant intermediate and subordinate certificates. Complete the following steps to upload the trust anchors:
- Go to the Admin console and navigate to Devices > Networks > Certificates.
- Select the appropriate organizational unit.
- Select Add Certificate.
- Enter the certificate name.
- Upload the certificate.
- Enable the Endpoint Verification checkbox.
- Click Add.
- Ensure that users belong to the organizational unit that the trust anchors are uploaded for.
Configure an AutoSelectCertificateForUrls policy
For Endpoint Verification to search the device certificate and collect it through Chrome, you must configure the AutoSelectCertificateForURLs policy by completing the following steps:
Ensure that the Chrome browser is managed by Chrome Browser Cloud Management.
- For Windows, macOS, and Linux, set up the cloud-managed Chrome browser using the Chrome Enterprise Code. For instructions, see Sign up Chrome Enterprise Core.
- Enroll your device to allow your organization to centrally manage that device. For instructions, see Enroll cloud-managed Chrome browsers.
In the Admin console, add the AutoSelectCertificateForUrls policy:
- Go to the Admin console and navigate to Devices > Chrome > Settings > User & Browser Settings > Client certificates.
- Select the appropriate organizational unit.
Add a policy AutoSelectCertificateForUrls, based on the following example:
{"pattern":"https://[*.]clients6.google.com","filter":{"ISSUER":{"CN":"CERTIFICATE_ISSUER_NAME"}}}Replace CERTIFICATE_ISSUER_NAME with the common name of the issuer CA. Do not modify the value of
pattern.
To verify the policy configuration, complete the following steps:
- Navigate to
chrome://policyin the browser. - Verify the configured value for AutoSelectCertificateForUrls.
- Ensure that the policy Applies to value is set to Machine. On the Chrome operating system, the value is applied to Current User.
- Ensure that the Status for the policy does not have a Conflict.
Troubleshooting your configuration
Review the certificate attributes on the device details page to ensure that they're listed correctly.
You can use the Endpoint Verification logs to help you troubleshoot any issues. To download the Endpoint Verification logs, complete the following steps:
- Right-click the Endpoint Verification extension and then go to Options.
- Select Log level > All > Download Logs.
- Open a support case with Cloud Customer Care and share the logs for further debugging.