Supported editions for this feature: Enterprise; Education Standard and Education Plus. Compare your edition
To use Google Workspace Client-side encryption (CSE) for Gmail, you need to to enable the Gmail API and give it access to your entire organization. Then, for each user, you need to use the API to upload an S/MIME (Secure/Multipurpose internet Mail Extensions) certificate and private key metadata encrypted by your key service.
Note: At any time, you can switch to a different key service by uploading new S/MIME certificates and private keys encrypted by your new service.
About S/MIME
S/MIME is a widely accepted, industry standard protocol for digitally signing and encrypting emails to ensure message integrity and security. Gmail CSE relies on the S/MIME 3.2 IETF standard to send and receive secure MIME data. S/MIME requires email senders and recipients to have their X.509 certificates trusted by Gmail.
Alternatively, you can use S/MIME without the additional layer of encryption and privacy that CSE provides. Use this alternative only if don't need to prevent Google servers from decrypting your data. For details, see Turn on hosted S/MIME for message encryption.
Before you begin
Make sure you've completed the following steps:
- Set up your external key service.
- Add your key service to your Admin console.
- Assign a key service to your top-level organizational unit, and any other key services you're using to the appropriate organizational units or configuration groups.
- Connect Google Workspace to your identity provider (IdP).
Set up the Gmail API
- Create a new GCP project. For details, see Creating and managing projects.
Note the project ID: You'll use it to grant the API domain-wide access.
- Go the Google API Console and enable the Gmail API for the new project. For details, see Enabling an API in your Google Cloud project.
- In the Google Cloud console, go to the Service accounts page and create a service account. For details, see Create and manage service accounts.
- Create a service account private key, and save the key file to your local system. For details, see Create and manage service account keys.
For this step, you'll use the service account you created to give the Gmail API edit access to all your users.
- Follow the instructions for Control API access with domain-wide delegation.
- Enter the following when prompted:
Client ID: Client ID of the service account created in Step 2 above.
OAuth scope:
gmail.settings.basic
Set up Gmail CSE for users
After you've set up Gmail API, you can set up Gmail CSE for your users.
- Using a certificate authority (CA), generate an S/MIME certificate for each user who will use Gmail CSE to either send or receive emails. You can do either of the following:
- Use a CA root certificate trusted by Google: For a list of root certificates, see CA certificates trusted by Gmail for S/MIME.
- Use a CA that's not trusted by Google: For example, to use your own CA, you can add its root certificate in the Admin console. For details, see Manage trusted certificates for S/MIME.
Note: If you use a CA that's not trusted by Google, and users will send client-side encrypted emails outside your organization, the receiver must also trust the CA.
- Encrypt, or "wrap," the S/MIME private keys' metadata using your key service. Follow the instructions in your service provider’s documentation.
You need to upload each user’s S/MIME certificate and wrapped private key metadata to Gmail using the Gmail API. For authentication, use the service account private key file you downloaded when setting up the Gmail API.
For each user:
It can take up to 24 hours for certificates to be available in Gmail, although it usually happens much faster.
To switch to another key service for Gmail CSE
If you want to switch to a different key service for Gmail CSE, repeat steps 2 and 3 under Set up Gmail CSE for users above, using your new key service to wrap the private keys.
Note: Uploading new certificates for users doesn't migrate content to the new key service. However, users can continue to access emails encrypted with the previous certificates and private key metadata wrapped by the old key service.
