S/MIME certificate profiles

This document lists the requirements each certificate in an X.509 chain must meet before it can be trusted for use in the context of S/MIME signed or encrypted email. In addition to meeting these requirements, the chain must anchor to a Certificate Authority (CA) certificate that has explicitly been trusted by Google for this purpose. (You can also choose to accept root certificates from CAs you trust. For more information see root certificate guidelines.)

Note: Google provides and maintains a list of trusted CA certificates trusted by Gmail for S/MIME. The list of CAs are trusted solely at Google's discretion and Google retains the right to remove root CAs at will, with or without reason.

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

Relevant if there is more than one intermediate CA between the root and end entity, either 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), 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			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 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 extension(s)			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 extension(s)	Optional	No	MAY be present.

End-entity certificate

Field			Value
Version			Version 3
Serial Number			MUST be greater than zero (0) and MUST contains 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. See §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 (e.g. 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 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
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 extension(s)	Optional	No	MAY be present.

Was this helpful?

How can we improve it?