Enrolling chromeOS Devices against EJBCA

 Introduction

chromeOS is an operating system based on Chromium (with Google Chrome as its primary UI) which is the default operating system on devices such as ChromeBooks, ChromeBoxes, ChromeBases and similar devices. In order to allow these devices to access the network, ensure internal network security and other PKI use cases, chromeOS can be easily set up to automatically enroll for certificates from EJBCA over the SCEP protocol. 

This scenario requires three parties: 

The Google Cloud Certificate Connector is a service installed on a third device which acts as an enrollment and administration portal for the enrolling chromeOS devices. 

EJBCA Configuration

As a part of this tutorial, it's assumed that you've already installed EJBCA and configured a CA you would like to enroll against. 

Certificate Profile

The pertinent fields in the Certificate Profile to set are as follows:

• Authority Key Id: Use
• Subject Key Id: Use
• Key Usages: Digital Signature
• Extended Key Usages: Client Authentication

End Entity Profile

The following values are expected to be available in the end entity profile:

Subject DN Fields

• Common Name (CN)
• Organizational Unit (OU)
• Organization (O)
• Country (C)

Subject Alt Names 

• RFC 822 Name
• DNS Name
• IP Adress
• MS User Principal Name

SCEP Alias

Lastly, the SCEP alias has been set up as follows:

Google Cloud Certificate Connector

Installation

The Google Cloud Certificate Connector is downloaded when first setting up your Google Cloud account, as documented here. The Connector needs to be installed on a Microsoft Windows Server.

To do so, perform the following steps:

1. Create an Active Directory service account user which will run the Google Cloud certificate connector. This account must have a static password.
2. Connect to the Google Admin Console with an administrator account
3. Under Devices → Networks, select Secure SCEP connector
4. The download connector page will give you access to:
1. The Connector Executable
2. The connector configuration JSON file (config.json)
3. The service account credentials JSON file (key.json)
   
   
   
   
   
5. Copy all the files downloaded to the server hosting the Google Cloud certificate connector
6. Run the installer as an Administrator
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
7. Provide the AD service account user
   
   Note: The connector cannot be installed with a non domain account
   
   
   
8. Install the connector
   
   
   
   
   

Configuration

1. Put the connector configuration JSON file (config.json) and the service account credentials JSON file (key.json) in the Google Cloud certificate connector folder (Default location is: C:\Program Files\Google Cloud Certificate Connector).
2. For the SSL handshake between the Google Cloud Certificate Connector and EJBCA to properly work, EJBCA's Management CA certificate needs to be added to the CA store of the Google Cloud certificate connector:
1. Locate the CA store of the Google Cloud certificate connector (default location is: C:\Program Files\Google Cloud Certificate Connector\rt\lib\security\cacerts)
2. Either install a Java SDK on the Google Cloud certificate connector server or copy the cacerts file to a computer where a Java SDK is installed
3. Add the Management CA certificate using keytool:
   
   

   keytool.exe -import -keystore ./cacerts -trustcacerts -file <ManagementCA.pem> -storepass changeit

   
   
   
   
   
   
4. Copy the cacerts file back to the Google Cloud certificate connector server (default location: C:\Program Files\Google Cloud Certificate Connector\rt\lib\security) if keytool wasn’t run on the server itself.
3. Start the Google Cloud Certificate Connector service.
4. Check that everything is properly started in the event viewer:
1. The Google Cloud Certificate Connector should be able to parse its configuration:
   
   
   
   
   
2. Initialize the service
   
   
   
   
   
3. Every 30 second the service will check against the Google backend if there are any requests to process
   
   
   
   
   

Adding your own CA to Google Cloud

1. Connect to the Google admin console with an administrator account
2. Under Devices → Networks → Certificates, select Add certificate. This should be done the root of the Google domain or for Chromebooks root OU
   
   
   
   
   
3. Provide a name for the CA, or otherwise the common name of the issuer will be used), then upload the CA certificate in PEM format and choose to deploy on Chromebooks
   
   
   
   
   

SCEP Profile Configuration

1. Connect to the Google admin console with an administrator account.
2. Under Devices → Networks → Secure SCEP connector, select Add secure SCEP profile. This can be done at the root domain level, at Chromebooks root OU in case of device certificates or Users root OU in case of user certificates.
   
   
   
   
   
3. Set a profile name, subject and the key size. The following example is focused on issuing device certificates, but can easily be adapted for user certificates:
   
   CSR subject fields are defined in the SCEP profile. Placeholder variables can be used in order to customize the CSR to the need. Available placeholder variables are defined in this article.
   
   
   
4. If needed, Subject Alternative Names (SANs) can also be added:
   
   
   
   
   
5. Configure:
1. The SCEP server URL, which should look something like https://<hostname>:<port>/ejbca/publicweb/apply/scep/<alias>/pkiclient.exe
   
2. the certificate characteristics
3. the static challenge (pass-phrase) used to authenticate the request coming from the Google Cloud certificate connector on the SCEP server and the corresponding certificate authority.
   
   
   
   
   
6. Configure how this template should be applied on ChromeBooks, per user or per device:
   
   
   
   
   

Testing

1. Connect to a user session on the ChromeBook.
2. Ensure that the device/user gets the policies to create the certificate request in chrome://policy (RequiredClientCertificateForDevice for a device certificate and RequiredClientCertificateForUser for a user certificate)
3. Under chrome://certificate-manager, follow the certificate creation process.
4. On the Google Cloud certificate connector event viewer, look for the following events:
1. Processed Requests
   
   
   
   
   
2. Google Cloud Certificate Connector submitting the SCEP request to EJBCA and receiving a certificate
   
   
   
   
   
3. ACK message between the Connector and the Google backend, pushing certificate to the Chromebook
   
   
   
   
   
5. Check that the certificate has been properly added to the Chromebook under chrome://certificate-manager
6. In the case of a device certificate, this process is also triggered just after a device enrollment

Performance! How to use EJBCA as a Massive PKI!

Are  your CRLs are scaling out of proportion, clients are complaining about timeouts and your VA is on its knees? Are your certificates counted not by thousands but by the millions? Never to fear, EJBCA is designed to handle some of the world's biggest PKI, so read on to find out how!

What can you do about your Architecture?

A large part of scaling up is adapting the architecture of your PKI to meet the requirements. Before we move on, here are two basic design choices that are the key to every large scale PKI.

Clustering and Load Balancing

The first step to being able to handle more issuances and traffic is by clustering: splitting the load between several instances of EJBCA working in concert. This has the added bonus of adding a layer of reliability to your PKI, a cluster can always survive one or more of its nodes failing. EJBCA has been designed to allow for hot-upgrading, meaning that your PKI is still active and running while the nodes in your cluster are running different versions of EJBCA, with zero downtime as a result. 

Likewise, clustering can be performed on VAs or RAs to easen to load on your PKI, depending on where your PKI is having performance issues:

• If you're experiencing long response times or timeouts in your VA infrastructure, then either the VA's HSM or the database are overloaded by queries - this can simply be solved by adding more VAs, but also by clustering the VA instances. 
• If you're issuing/revoking certificates in large volumes, clustering the CAs will allow more nodes to do the work of revoking and publishing. Each revocation sent out to the VA's is just a single write per cluster.

Essential if your have multiple VAs/VA clusters is to place them behind a Load Balancer in order to balance the load on each VA. 

Database Sharding

For databases of extreme volumes, it may be desirable to shard the database over several database instances in order to save space.  By setting the following value to true in database.properties:

database.useSeparateCertificateTable = true

the certificate body will be stored in the table Base64CertificateData instead of CertificateData. 

Base64CertificateData can then be sharded and placed on a different database volume. 

CRL Partitioning

If your population of unexpired certificates is large and you rely on CRLs, you might start finding that CRL generation times are beginning to spin out of control, and that CRL sizes becomes unmanageable. EJBCA supports CRL partitioning in accordance with RFC 5280, allowing certificates to be assigned to a specific CRL shard. 

CRL partitioning means that instead of a single CRL, the CRL is split into several shards. As the shards grow themselves in size, EJBCA allows you to suspend shards, automatically creating new ones. 

Service Pinning

In a clustered EJBCA instance, service execution happens at semi-random, the service being run by the first node to activate within the granted service interval. If some services - for example generating CRLs - are taking an inordinate amount of time, you may be experiencing latency in the cluster node executing the service, leading to intermittent delays being experienced while the service is running. The easiest solution is to pin the service to a single node and remove that node from the load balancer's roster, meaning that all service executions will happen on that node only, while enrollment, issuance and revocation operations are processed on the remaining node. 

Ephemeral Certificates

EJBCA can be configured to function as an Ephemeral Certificate CA. In this mode EJBCA simply functions as a high speed certificate factory, issuing certificates but not storing any trace of them in the local database.

While the mode still allows for revocation of certificates, it does not allow for certificates to be searched for in the database or for any constraints based on existing certificates to be enforced.

Precompiled OCSP Responses

Each OCSP reply requires an individual signature by the crypto token on the VA. While generated responses are cached by the EJBCA VA,  validity times of OCSP replies are commonly short (< one day) and caches are not shared between nodes in a cluster, thus responses still need to be generated anew frequently. The traditional solution to this has been OCSP Stapling, caching the first reply encountered in the http proxy. While this may solve the problem to some extent, it moves the burden of administration of caching the replies over to you.

Instead, EJBCA offers Precompiled OCSP Responses. Colloquially known as Canned OCSP, this functionality allows a VA to generate the full set of expected OCSP responses on a regular schedule within a set timeframe, when there are expected lulls in traffic. For any PKI, this will dramatically decrease the latency of the VA infrastructure.