Gmail only: Upload encryption keys for client-side encryption

to use google workspace client side encryption (cse) for gmail, you must enable the gmail api and give it access to your entire organization then, for each user, you need to use the gmail api to upload an s/mime (secure/multipurpose internet mail extensions) certificate (public key) and private key metadata to gmail if you use an encryption key service, you must also encrypt (or wrap) users' private key metadata by using your key service at any time, you can switch to a different key service by uploading a new s/mime certificate and private key metadata 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 set up the gmail api perform the following tasks to set up the gmail api enable the gmail api create a domain wide service account grant the gmail api domain wide access enable the gmail api perform the following steps to enable the gmail api create a new gcp project for details, go to creating and managing projects you use the project id to grant the api domain wide access go to the google api console and enable the gmail api for the new project for details, go to enabling an api in your google cloud project create a service account perform the following steps to create a domain wide service account in the google cloud console, go to the service accounts page and create a domain wide service account for details, go to create and manage service accounts create a service account private key, and save the key to a json file on to your local system, such as svc acct creds json this file contains the credentials you use when setting up gmail for users for details, go to create and manage service account keys grant the gmail api access this step uses the service account you created to give the gmail api domain wide 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 the preceding step 2 oauth scopes paste the following scopes into a separate field https //www googleapis com/auth/gmail settings basic https //www googleapis com/auth/gmail settings sharing https //www googleapis com/auth/gmail readonly turn on gmail cse for users turn on cse for gmail for the organizational units or groups for details, go to turn client side encryption on or off for organizational units, you can set all emails (compose, reply, and forward) to be encrypted by default users can still turn off encryption if needed requires having the assured controls add on set up cse s/mime certificates for users after you set up gmail api and turn on gmail cse for users in the admin console, you can set up cse s/mime certificates and private key metadata for your users after a new user is fully provisioned on the google workspace with the correct permissions for gcse, they should immediately be able to use the file encryption functionality of gcse with no further implementation required on the {{ch}} service when the gcse service automatically generates a user, if they have the correct licenses in the workspace, their encrypted email (s/mime) certificates should also automatically be created the following section details the manual process prepare s/mime certificates and private key metadata this section applies to users who uses gmail cse to either send or receive emails using a certificate authority (ca), generate an s/mime public/private key pair with a certificate chain the s/mime leaf/client certificate must include the user’s primary gmail address as a subject name or san extension subject you can use the following openssl command to generate the s/mime leaf certificate openssl req new newkey rsa 2048 nodes keyout mykey pem out mycsr csr the email should be the cn no other dn fields are needed next, you must retrieve the leaf/client csr you generated, signed by either of the following methods a ca root certificate trusted by google for a list of root certificates, go to ca certificates trusted by gmail for s/mime a ca not trusted by google for example, to use your own ca, you can add its root certificate in the admin console for details, go to manage trusted certificates for s/mime if you use a ca that google does not trust and users send client side encrypted emails outside your organization, the receiver must also trust the ca obtain the certificate perform the following step to obtain the certificate with cas in pkcs7 pem format on a computer that has openssl installed, run the following command in a terminal openssl crl2pkcs7 nocrl certfile cert 88231 ca bundle crt certfile cert 88231 crt out user p7pem get the private key perform the following step to get the private key in encrypted pkcs8 format with a password on a computer that has openssl installed, run the following command in a terminal openssl pkcs8 topk8 inform pem in user key outform pem out user p8 v2 aes 256 cbc wrap certificates and private key metadata use your key service (such as {{ch}} ) to encrypt or wrap the s/mime private key metadata perform the following steps to upload pkcs8 key through the {{ch}} web dashboard go to the {{ch}} web dashboard in a browser log into the {{ch}} by using the default admin identities ( admin1 and admin2 ) select the google workspace cse (client side encryption) service from the list of deployed services on the service management page go to the users view for the service and select the mail icon next to the user for whom you're wrapping the pkcs #8 private key in the wrap private key dialog, enter a password to wrap the pkcs #8 private key under, select \[ upload ] , and select the file to upload {{ch}} sends the wrapped pkcs #8 private key to your browser download the file when prompted open the wrapped pkcs #8 private key file in a text editor and copy (or preferably cut) the encrypted key blob to your clipboard open a new file in the text editor then, copy and paste the following json { "kacls url" "https //cryptohub demo com/v0/key encrypt/client", "wrapped private key" "" } first, change cryptohub demo com to the actual domain of your {{ch}} then, paste the encrypted key blob into the wrapped private key value and save the file with the name demo\@futurex com wrap upload the certificates and key metadata use the gmail api to upload each public key s/mime certificate chain and private key metadata for each user to gmail and set them as the preferred keys for the users by creating an identity to upload the user s/mime certificates and private key metadata to gmail, complete the following steps for each user use the private key file you downloaded when creating a domain wide service account for authentication and google's python script prepare the keys directory and copy the encrypted keys mkdir p keys cp user p7pem /keys/demo\@futurex com p7pem cp user wrap /keys/demo\@futurex com wrap upload the certificate chain and private key metadata by using the gmail api call keypairs create python cse cmd py insert keypair creds projectname 9a4ed8338919 json inkeydir /keys incertdir /keys enable the keypair for the user's primary email address by using the gmail api call identities create python cse cmd py insert identity creds projectname 9a4ed8338919 json userid demo\@ futurex com kpemail demo\@futurex com kpid ane1bmjz20byadwijbhbyuxss8bf82rxj1oa13cgxwt b0rpxmvhme8 the identities create call requires the key pair id returned in the response body of the keypairs create call enabling the key pair for a user email address creates a cse identity authorized to send email from the user account configures gmail to use the private key metadata to sign outgoing cse mail publishes the certificate to a shared domain wide repository so other cse users in your organization can encrypt messages sent to this user after you upload the certificates, it can take up to 24 hours for them to be available in gmail, although it usually happens much faster supporting email aliases with cse the integration now supports email aliases linked to a single gmail account this allows users to send and receive encrypted emails using any of their associated email addresses (primary or aliases) while maintaining proper encryption and decryption capabilities for example, if a user has a primary email address (such as tuser\@companyname com ) and one or more aliases (such as test user\@companyname com ), you should enroll the user in {{ch}} by using their primary email address configure authentication to the idp using the primary email username (such as tuser ) when uploading s/mime certificates, ensure they include both the primary email and all aliases in the subject name or san extension this configuration enables users to send encrypted emails from either their primary address or any alias recipients to properly decrypt emails regardless of which address (primary or alias) was used to send the message all encrypted emails to be accessible within the same gmail account when generating s/mime certificates for users with aliases, make sure to include all associated email addresses in the certificate's subject alternative name (san) field configure gmail perform the following steps to configure gmail for encrypted emails compose a new email in gmail when writing your email, you can click on the lock icon next to the recipient's name to choose the level of encryption green strong encryption, both parties have s/mime enabled gray the email will be encrypted, but the recipient's identity isn't verified red the recipient does not support encryption track provisioned users you can track which users have been provisioned s/mime for google cse in the {{ch}} using the users menu for the service go to deployed services > google workspace cse (client side encryption) in the management menu, select \[ users ] in the list of users, users who have been provisioned s/mime have an expiration date listed under s/mime expiration delete a pairing from google you can use the {{ch}} to delete the identity/user pairing, which you send to google by using curl rest calls to delete a user's s/mime identity/user pairing from google, follow these steps go to deployed services > google workspace cse (client side encryption) in the management menu, select \[ users ] for a user provisioned s/mime, select the x icon for g mail key remove for the user