Supported editions for this feature: Enterprise Plus; Education Fundamentals, Education Standard, Teaching and Learning Upgrade, and Education Plus. Compare your edition
Hosted S/MIME and Client-side encryption (CSE) are Google Workspace features that let your users send and receive S/MIME email messages.
Google provides certificate requirements and trusted CA certificates for S/MIME. If your certificates don't meet these requirements, you may notice that certain messages aren’t trusted. To fix this, you can accept other root certificates, from root certificate authorities (CAs) that you trust.
To accept an additional root certificate, add it in your Google Admin console. Then, specify at least one domain that the certificate applies to. You can also optionally adjust the certificate’s encryption level and validation profile.
For detailed steps to turn on S/MIME in Google Workspace, visit Enable hosted S/MIME for message encryption. To learn more about CSE, visit About client-side encryption.
- Root certificate guidelines
- Change the domain for a root certificate
- Delete a root certificate
- Exchange S/MIME messages between domains
- Use different certificates for signing and encrypting
- Allow certificate mismatch (not recommended)
- Allow SHA-1 (not recommended)
- Troubleshoot root certificate upload issues
Root certificate guidelines
Root certificates must meet these guidelines to be used with S/MIME in Google Workspace:
- The certificate must be in .pem format and contain only one root certificate.
- The certificate chain must include at least one intermediate certificate.
- Each certificate chain should have an end-user certifcate. If it’s not included, Google performs minimal verification.
- The end user certificate should not include the private key.
Important: At least one intermediate CA certificate must be present in the chain. That is, the root must not issue end-entity certificates directly.
Change the domain for a root certificate
You can’t edit a certificate’s expiration date or edit to replace a certificate. You must delete the certificate and upload a new one. Deleting a root certificate won't affect any end-user certificates that have already been uploaded.
To change the domain for a root certificate:
- In your Google Admin console, go the S/MIME setting on the User Settings tab.
- In the table of additional root certificates, select the certificate you want to change; then click Edit.
- Update the domain, then click Save.
Delete a root certificate
To delete a root certificate:
- In your Google Admin console, go the S/MIME setting on the User Settings tab.
- In the table of additional root certificates, select the certificate you want to remove and click Delete.
Use different certificates for signing and encrypting
This feature is available with CSE only. It's not available with hosted S/MIME.
Typically, organizations use a single certificate for both signing and encrypting messages. However, if your organization requires different certificates for signing and encrypting messages, use the Gmail CSE API to upload the encryption public certificate and the signature public certificate for each user.
Learn more about using the Gmail CSE API to manage user certificates.
Exchange S/MIME messages between domains
To let people in different domains exchange S/MIME messages, you might need to take a few extra steps in your Google Admin console. Follow the recommended steps here, based on how the user certificates are issued for the domain.
- Both domain’s user certificates issued by a trusted root CA: When all user certificates in both domains are issued by a root CA trusted by Google, you don’t need to take any extra steps. These root CA certificates are always trusted by Gmail.
- Both domain’s user certificates issued by the same, untrusted root CA: In this case, an untrusted root CA issued the user certificates for your domain and the domain you want to exchange S/MIME messages with.
Add the untrusted root CA to your Google Admin console, following the steps in Enable hosted S/MIME. In the Add root certificate box, enter the other domain in the Address list field.
- One domain's user certificates issues by an untrusted root CA: In this case, one domain’s user certificates are issued by an untrusted root CA. The other domain’s user certificates are issued by a different root CA.
Add the other domain’s root CA to your Google Admin console, following the steps in Turn on hosted S/MIME. In the Add root certificate box, enter the other domain in the Address list field.
Use only when necessary
Use the certificate options in this section only when necessary, and make sure you understand the possible impacts when using them. Allow certificate mismatch (not recommended)This feature is available with CSE only. It's not available with hosted S/MIME.
Important: For security reasons, we recommend allowing certificate mismatches only when this feature is required by your organization. When this option is on, users and admins won't get a warning when there’s a certificate mismatch, which could be caused by unauthorized or malicious user.
Sometimes, the email address associated with a user’s certificate might be different from the user's primary email address. For example, Brandon Pham’s certificate uses the email address b.pham@solarmora.com, but Brandon uses the address brandon.pham@solarmora.com for most of his work emails. This is called a certificate mismatch.
To set up CSE to allow certificate mismatch, select the certificate mismatch option when you add root certificates in the hosted S/MIME setting. Read detailed steps for adding root certificates.
When the Allow certificate mismatch option is selected, recipients can decrypt and read incoming messages with a certificate mismatch. However, the certificate isn’t automatically saved to their contacts.
Earlier messages (with a certificate mismatch) received before this setting option was on can be decrypted and read. If the option is on then turned off, past and new messages (with a certificate mismatch) that could be decrypted when the option was selected can no longer be decrypted.
Although some email clients allow SHA-1 hashed signatures, these signatures appear untrusted. This is because SHA-1 has been deprecated due to security issues.
When you add a new root certificate to the S/MIME setting, select the Allow SHA-1 globally option only if:
- Your organization communicates using the SHA-1 cryptographic hash function for S/MIME message security, and
- You want these communications to appear as trusted.
When this option is selected, Gmail trusts S/MIME certificates that attached to inbound mail with SHA-1.
Troubleshoot certificate upload issues
If you're having problems uploading certificates, review these possible causes and try the recommended solutions:
Certificate doesn't meet the minimum requirements to be trusted
Verify that the certificate isn’t self-signed, hasn’t been revoked, and that the key length is 1024 bits or more. Then try uploading again.
Edit the certificate to change the domains in the address list. For example, if you’ve uploaded custom certificates and messages are still treated as non-trusted, try editing the certificate's list of allowed domains.
Certificate's signature is invalid
Verify that the certificate has a valid signature, and try uploading again.
Expired certificate
Verify the date on the certificate is within the date range specified in the Not Before (Date) and Not After (Date) fields. Then try uploading again.
Certificate chain has at least one invalid certificate.
Verify that the certificate is formatted correctly, and try uploading again.
Certificate contains multiple root certificates
You can't upload a certificate that contains more than one root certificate. Verify the certificate has just one root certificate, and then try uploading again.
Certificate couldn't be parsed
Verify the certificate is formatted correctly, and then try uploading again.
Server returns an unknown response
Verify the certificate is formatted correctly, and then try uploading again.
Unable to upload certificate
There might have been a problem connecting to the server. This is typically a temporary issue. Wait a few minutes and try uploading again. If the upload continues to fail, verify the certificate is formatted properly.
