Notification

Duet AI is now Gemini for Google Workspace. Learn more

S/MIME certificate profiles

This article describes the requirements that each certificate in an X.509 chain must meet to be trusted for use with encrypted or S/MIME-signed email.

In addition to these requirements, the chain must anchor to a Certificate Authority (CA) certificate that is explicitly trusted by Google for this purpose. You can also choose to accept root certificates from CAs you trust. For more information, go to root certificate guidelines.

Notes:

  • Google provides and maintains a list of CA certificates trusted by Gmail for S/MIME. The list of CAs is trusted solely at Google's discretion. Google retains the right to remove root CAs at any time without notice.
  • Make sure installed extensions don't contradict other extensions in the same certificate. For example, if nsCertTypes are defined, they must cover the exact same uses as the key usage extension, extended key usage extension, and basic constraints extension.

Certificate chain rules

Root CA

Field Value

Issuer DN

Must identify the CA.

For example, the DN must not be a generic value such as "Certificate Authority."

Subject DN

The encoded form must be byte-for-byte identical with the Issuer DN.

Subject Public Key Info

rsaEncryption with an RSA modulus of 2048, 3072, or 4096. Or ecPublicKey using secp256r1 or secp384r1.

Intermediate CA certificates other than from issuing intermediate CA

Use this information if there's more than one intermediate CA between the root and end entity, directly or indirectly.

The issuing intermediate CA is the intermediate CA that issues the end entity certificate. This section is applicable to any intermediate CAs in the chain other than the issuing intermediate CA.

Field Value
Version Version 3
Serial Number     Must be greater than zero (0). When DER encoded as an INTEGER, must be less than or equal to 20 bytes.
Signature Algorithm     RSA with SHA‐256, SHA‐384, or SHA‐512. Or ECDSA with SHA‐256, SHA‐384, or SHA‐512
Issuer DN    

Must be byte-for-byte identical with the Subject DN of the issuing CA.

Validity Period     No stipulation
Subject DN     No stipulation
Subject Public Key Info    

rsaEncryption with an RSA modulus of 2048, 3072, or 4096.  Or ecPublicKey using secp256r1 or secp384r1

Extension Presence Critical Value
Key Usage Required Yes

Bit positions must be set for: keyCertSign
Any other bit positions may be set

Basic Constraints Required Yes cA field must be set true
pathLenConstraint field should be present
CRL Distribution Points Required No

At least one publicly accessible HTTP
uniformResourceIdentifier must be present

(note) Revocation servers must comply with the following sections of the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates, version 1.3.2 or greater:
  • 4.9.7. CRL Issuance Frequency
  • 4.9.9. On‐line Revocation/Status Checking Availability
  • 4.9.10. On‐line Revocation Checking Requirements
    4.10.2 Service Availability

Any other extensions May be present

Intermediate CA certificate that issues the end entity 

Important: At least one intermediate CA certificate must be present in the chain. That is, the root must not issue end-entity certificates directly.

Field Value
Version Version 3
Serial Number Must be greater than zero (0), and, when DER encoded as an INTEGER, be less than or equal to 20 bytes.
Signature Algorithm

RSA with SHA‐256, SHA‐384, or SHA‐512. Or ECDSA with SHA‐256, SHA‐384, or SHA‐512.

Issuer DN    

Must be byte-for-byte identical with the Subject DN of the issuing CA.

Validity Period    

Difference between notBefore and notAfter

Should not be longer than 10 years and must not be longer than 20 years.

Subject DN    

Should indicate the use of the CA.

Subject Public Key Info    

rsaEncryption with an RSA modulus of 2048, 3072, or 4096.  Or ecPublicKey using secp256r1 or secp384r1

Extension Presence Critical Value
Key Usage Required Yes

Bit positions must be set for:
    keyCertSign
Bit position may be set for:
    cRLSign
    digitalSignature
If directly used for signing OCSP responses, must be present:
    digitalSignature

Other bit positions must not be set

Extended Key Usage Required Either Must be present:
    emailProtection
Must not be present:
    serverAuth
    codeSigning
    timeStamping
​    anyExtendedKeyUsage

Basic Constraints

Required Yes

cA field must be set true
pathLenConstraint field SHOULD be present and SHOULD be 0

Certificate Policies Optional No

A policyIdentifier SHOULD be provided that identifies the policy under which the CA operates, and SHOULD NOT be anyPolicy.
cps, if present, must contain a valid HTTP or HTTPS link.

CRL Distribution Points Required No

At least one publicly accessible HTTP
uniformResourceIdentifier must be present.

(note)    

Revocation servers must operated in accordance with the following sections of the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates, version 1.3.2 or greater:

  •   4.9.7. CRL Issuance Frequency
  •   4.9.9. On‐line Revocation/Status Checking Availability
  •   4.9.10. On‐line Revocation Checking Requirements
  •   4.10.2. Service Availability
Any other extensions Optional No 

May be present.

End-entity certificate

Field Value
Version Version 3
Serial Number

Must be greater than zero (0) and must contain at least 64 unpredictable bits.

Note: Will be updated to reflect CA/Browser Forum Baseline Requirements Certificate Policy end entity serial number entropy requirements.

Signature Algorithm RSA with SHA‐256, SHA‐384, or SHA‐512. Or ECDSA with SHA‐256, SHA‐384, or SHA‐512.
Issuer DN

Must be byte-for-byte identical with the Subject DN of the issuing CA.

Validity Period

Difference between notBefore and notAfter must not be longer than 27 months.

notBefore time must represent time of signature plus or minus 48 hours.

Subject DN    

Any Subject Relative Distinguished Names other than email address must be rigorously validated before issuance, using a publicly documented and audited procedure.  Refer to Section 3.2.3 “Authentication of Individual Identity” of the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates, version 1.3.2 or greater for an acceptable procedure.

Any email addresses (for example, in commonName or emailAddress fields) must also be present in the Subject Alternate Name extension as an rfc822Name.

Subject Public Key Info    

rsaEncryption with an RSA modulus of 2048, 3072, or 4096. Or ecPublicKey using secp256r1 or secp384r1

Extension Presence Critical Value
Key Usage (RSA) Required Yes

Bit positions must be set for either:
    digitalSignature
 and/or
    nonRepudiation/contentCommitment
Bit positions may be set for:
    dataEncipherment
    keyEncipherment

Other bit positions must not be set.

Key Usage (ECDH)  Required  

Bit positions must be set for:
    digitalSignature
Bit positions may be set for:
    nonRepudiation/contentCommitment
    keyAgreement
    encipherOnly (if keyAgreement is set)
    decipherOnly (if keyAgreement is set)

Other bit positions must not be set.

Extended Key Usage Required Either

Must be present:
   emailProtection
Must not be present:
   serverAuth
   codeSigning
   timeStamping
   anyExtendedKeyUsage

Basic Constraints

Optional Either

If present, cA field must not be set true
pathLenConstraint field must not be present

Certificate Policies Required No

Must be present: A policyIdentifier must be provided that identifies the policy under which the certificate was issued, and must not be anyPolicy

May be present: cps, if present, must contain a valid HTTP or HTTPS link to the CPS under which the certificate was issued.

Authority Information Access

Optional No

caIssuers and, if present, ocsp, must contain at least one publicly accessible HTTP uniformResourceIdentifier.

AccessDescription must not contain any labels or parameters that are specific to an individual certificate.

CRL Distribution Points Required No

At least one publicly accessible
HTTPuniformResourceIdentifier must be present

(note)

   

Revocation servers must operate in accordance with the following sections of the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates, version 1.3.2 or greater:

  •    4.9.7. CRL Issuance Frequency
  •    4.9.9. On‐line Revocation/Status Checking Availability
  •    4.9.10. On‐line Revocation Checking Requirements
  •    4.10.2. Service Availability

Subject Alternative Name

Required No

Must contain at least one item of type rfc822Name.
Must not contain items of type:
   dNSName
   iPAddress
   uniformResourceIdentifier
Each rfc822Name must be verified with publicly documented and audited measures to ensure the entity submitting the request controls the email account associated with the email address or has been authorized by the email account holder to act on the account holder’s behalf.

Any other extensions

Optional No May be present.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
7851091420785473892
true
Search Help Center
true
true
true
true
true
73010
false
false