Configuring enterprise certificate conditions

A key principle of Chrome Enterprise Premium is "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 Chrome Enterprise Premium's zero-trust policy engine. Access Context Manager allows administrators to 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 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 many ways to determine whether a device is corporate-owned, and one way is to determine if a valid certificate, issued by the company, exists on the device. The existence of an enterprise certificate on a device can be used to indicate that the device is corporate-owned.

Enterprise certificates for context-aware access is a feature of the overall Chrome Enterprise Premium certificate-based access solution. This feature leverages device certificates as an alternative context-aware signal to determine if a device is a corporate-owned asset. This feature is supported on Chrome browser 110 or later.

Because a device can have more than one certificate, enterprise certificates can be accessed in the custom access level through macros .exist(e,p):

device.certificates.exists(cert, predicate)

In the example, cert is an identifier to be used in predicator which binds to the device certificate. The exist() 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 of predicate expression (where `cert` is an identifier of macros)
`is_valid`	True if the certificate is valid and not expired (boolean).	`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: `$ openssl x509 -in cert.pem -out cert.der -outform DER $ openssl dgst -sha256 -binary cert.der > digest.sha $ openssl base64 -in digest.sha`	`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: `$ openssl x509 -in cert.pem -out cert.der -outform DER $ openssl dgst -sha256 -binary cert.der > digest.sha $ openssl base64 -in digest.sha`	`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/[email protected]` The issuer string used in the access level is the reverse of the output and the / replaced by a comma. Example: `[email protected], CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN`	`cert.issuer == "[email protected], 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
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")`
Device has a valid certificate issued by issuer `CA_ABC.`	`device.certificates.exists(cert, cert.is_valid && cert.issuer == "[email protected], CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN")`

Configuring enterprise certificates

Before configuring enterprise certificates, ensure you have 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

In order 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 here refer to 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 users belong to the organizational unit for which the trust anchors are uploaded.

Configure an AutoSelectCertificateForUrls policy

For Endpoint Verification to search the device certificate and collect it through Chrome, you must configure the AutoSelectCertificateForURLs chrome policy by completing the following steps:

Ensure that the Chrome browser is managed by Chrome Browser Cloud Management.
- [Win/OSX/Linux] Setup for managed chrome browser using CBCM https://support.google.com/chrome/a/answer/9301891.
- [Chrome] Enroll the device to the enterprise.
In the Admin console, add the AutoSelectCertificateForUrls policy:
1. Go to the Admin console and navigate to Devices > Chrome > Settings > User & Browser Settings > Client certificates.
2. Select the appropriate organizational unit.
3. Add a policy AutoSelectCertificateForUrls, as demonstrated in the following example:
```
{"pattern":"https://[*.]clients6.google.com","filter":{"ISSUER":{"CN":"CERTIFICATE_ISSUER_NAME"}}}
```
  Replace CERTIFICATE_ISSUER_NAME with the common name of the root CA. Do not modify the value of pattern.

To verify the policy configuration, complete the following steps:

Navigate to chrome://policy in 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 certificate attributes are 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 on 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.