S/MIME-Zertifikatprofile

In diesem Artikel werden die Anforderungen beschrieben, die jedes Zertifikat in einer X.509-Kette erfüllen muss, damit es als vertrauenswürdig gilt und für die Verschlüsselung oder S/MIME-Signierung von E‑Mails verwendet werden kann.

Darüber hinaus muss die Kette in einem Zertifikat einer Zertifizierungsstelle (Certificate Authority, CA) verankert sein, das von Google ausdrücklich für diesen Zweck als vertrauenswürdig eingestuft wurde. Sie können auch festlegen, dass Stammzertifikate von CAs angenommen werden, denen Sie vertrauen. Weitere Informationen finden Sie im Hilfeartikel Gehostetes S/MIME für erhöhte E-Mail-Sicherheit aktivieren.

Hinweise:

  • Google verwaltet eine Liste vertrauenswürdiger CA-Zertifikate, denen in Gmail für S/MIME vertraut wird, und stellt sie Ihnen bereit. Welche CAs als vertrauenswürdig gelten, liegt im Ermessen von Google. Google behält sich das Recht vor, Root-CAs jederzeit ohne Vorankündigung zu entfernen.
  • Achten Sie darauf, dass installierte Erweiterungen nicht anderen Erweiterungen im selben Zertifikat widersprechen. Wenn z. B. „nsCertTypes“ definiert werden, müssen sie exakt dieselben Nutzungen abdecken wie die Erweiterungen für die Schlüsselverwendung, die erweiterte Schlüsselverwendung und die Basiseinschränkungen.

Regeln für Zertifikatsketten

Stamm-CA

Feld Wert

Aussteller-DN

Hierdurch muss die CA eindeutig identifiziert werden können.

Allgemeine Angaben wie „Zertifizierungsstelle“ sind nicht zulässig.

Subjekt-DN

Die codierte Form muss bytegenau identisch sein mit dem Aussteller-DN.

Subject Public Key Info

rsaEncryption mit einem RSA-Modulus von 2.048, 3.072 oder 4.096. Alternativ ecPublicKey mit secp256r1 oder secp384r1.

Zwischen-CA-Zertifikate, die nicht von der ausgebenden Zwischen-CA stammen

Nutzen Sie diese Information, wenn es zwischen Stamm- und Endentität direkt oder indirekt mehr als eine Zwischen-CA gibt.

Als ausgebende Zwischen-CA wird diejenige bezeichnet, die das Endentitätzertifikat ausgibt. Dieser Abschnitt gilt für alle Zwischen-CAs in der Kette mit Ausnahme der ausgebenden.

Feld Wert
Version Version 3
Seriennummer Muss größer als Null (0) sein. Muss bei DER-Codierung als GANZZAHL kleiner als oder gleich 20 Bytes sein
Signaturalgorithmus RSA mit SHA‐256, SHA‐384 oder SHA‐512 Alternativ ECDSA mit SHA‐256, SHA‐384 oder SHA‐512
Aussteller-DN

Muss bytegenau identisch sein mit dem Subjekt-DN der ausstellenden CA.
Gültigkeitszeitraum Keine bestimmten Anforderungen
Subjekt-DN Keine bestimmten Anforderungen
Subject Public Key Info

rsaEncryption mit einem RSA-Modulus von 2.048, 3.072 oder 4.096. Alternativ ecPublicKey mit secp256r1 oder secp384r1
Erweiterung Präsenz Kritisch Wert
Schlüsselverwendung Erforderlich Ja

Bit-Positionen müssen festgelegt sein für: keyCertSign
Alle anderen Bit-Positionen können optional festgelegt werden.
Basiseinschränkungen Erforderlich Ja Das Feld „cA“ muss auf „true“ gesetzt sein.
Das Feld „pathLenConstraint“ sollte vorhanden sein.
CRL-Verteilungspunkte Erforderlich Nein

Mindestens ein öffentlich abrufbarer
„HTTPuniformResourceIdentifier“ muss vorhanden sein
(Hinweis) Sperrserver müssen den folgenden Abschnitten der Richtlinie des CA/Browser-Forums bezüglich Mindestanforderungen für die Ausstellung und Verwaltung vertrauenswürdiger Zertifikate (CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates) in der Version 1.3.2 oder aktueller entsprechen:
  • 4.9.7. CRL Issuance Frequency (Häufigkeit der Sperrlistenausgabe)
  • 4.9.9. On‐line Revocation/Status Checking Availability (Verfügbarkeit von Onlinesperr- und Statusprüfung)

  • 4.9.10. On‐line Revocation Checking Requirements (Anforderungen für Onlinesperrprüfung)
    4.10.2 Service Availability (Dienstverfügbarkeit)
Andere Erweiterungen Können vorhanden sein

Zwischen-CA, die die Endentität ausgibt

Wichtig: In der Kette muss mindestens ein CA-Zwischenzertifikat vorhanden sein. Die Zertifikate der Endentität dürfen also nicht direkt von der Stamm-CA ausgegeben werden.

Feld Wert
Version Version 3
Seriennummer Muss größer als null (0) und bei DER-Codierung als GANZZAHL kleiner als oder gleich 20 Bytes sein
Signaturalgorithmus

RSA mit SHA‐256, SHA‐384 oder SHA‐512 Alternativ ECDSA mit SHA‐256, SHA‐384 oder SHA‐512.
Aussteller-DN

Muss bytegenau identisch sein mit dem Subjekt-DN der ausstellenden CA.
Gültigkeitszeitraum

Unterschied zwischen „notBefore“ und „notAfter“

Sollte nicht länger als 10 Jahre sein und darf nicht länger als 20 Jahre sein.
Subjekt-DN

Sollte die Verwendung der CA angeben
Subject Public Key Info

rsaEncryption mit einem RSA-Modulus von 2.048, 3.072 oder 4.096. Alternativ ecPublicKey mit secp256r1 oder secp384r1
Erweiterung Präsenz Kritisch Wert
Schlüsselverwendung Erforderlich Ja

Bit-Positionen müssen festgelegt sein für:
keyCertSign
Bit-Positionen können festgelegt sein für:
cRLSign
digitalSignature
Falls direkt für die Signierung von OCSP-Antworten verwendet, muss Folgendes vorhanden sein:
digitalSignature

Andere Bit-Positionen dürfen nicht festgelegt sein
Erweiterte Schlüsselverwendung Erforderlich Beides Muss vorhanden sein:
emailProtection
Darf nicht vorhanden sein:
serverAuth
codeSigning
timeStamping
anyExtendedKeyUsage

Basiseinschränkungen

 Erforderlich Ja

Das Feld „cA“ muss auf „true“ gesetzt sein.
Das Feld „pathLenConstraint“ SOLLTE vorhanden sein und SOLLTE 0 sein.
Zertifikatrichtlinien Optional Nein

Für „policyIdentifier“ SOLLTE ein Wert angegeben werden, der die Richtlinie kenntlich macht, gemäß der die CA arbeitet. Der Wert SOLLTE NICHT anyPolicy lauten.
Falls „cps“ vorhanden ist, muss ein gültiger HTTP- oder HTTPS-Link angegeben sein.
CRL-Verteilungspunkte Erforderlich Nein

Mindestens ein öffentlich abrufbarer
„HTTPuniformResourceIdentifier“ muss vorhanden sein.
(Hinweis)

Sperrserver müssen gemäß den folgenden Abschnitten der Richtlinie des CA/Browser-Forums bezüglich Mindestanforderungen für die Ausstellung und Verwaltung vertrauenswürdiger Zertifikate (CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates) in der Version 1.3.2 oder aktueller betrieben werden:

  • 4.9.7. CRL Issuance Frequency (Häufigkeit der Sperrlistenausgabe)
  • 4.9.9. On‐line Revocation/Status Checking Availability (Verfügbarkeit von Onlinesperr- und Statusprüfung)
  • 4.9.10. On‐line Revocation Checking Requirements (Anforderungen an die Onlinesperrprüfung)
  • 4.10.2. Verfügbarkeit des Dienstes
Andere Erweiterungen Optional Nein

Können vorhanden sein.

Zertifikat für Endentitäten

Feld Wert
Version Version 3
Seriennummer

Muss größer als null (0) sein und muss mindestens 64 unvorhersagbare Bits enthalten.

Hinweis:Wird aktualisiert und an die Anforderungen im Hinblick auf die Entropie für die Seriennummer der Endentität gemäß den Mindestanforderungen der Zertifikatrichtlinie des CA/Browser-Forums (CA/Browser Forum Baseline Requirements Certificate Policy) angepasst.
Signaturalgorithmus RSA mit SHA‐256, SHA‐384 oder SHA‐512 Alternativ ECDSA mit SHA‐256, SHA‐384 oder SHA‐512.
Aussteller-DN

Muss bytegenau identisch sein mit dem Subjekt-DN der ausstellenden CA.
Gültigkeitszeitraum

Der Unterschied zwischen „notBefore“ und „notAfter“ darf nicht größer als 27 Monate sein.

Die Zeit für „notBefore“ muss den Zeitpunkt der Signatur plus oder minus 48 Stunden darstellen.
Subjekt-DN

Jeder Subjekt-DN (Subject Relative Distinguished Name) mit Ausnahme der E-Mail-Adresse muss vor der Ausstellung anhand eines öffentlich dokumentierten und geprüften Verfahrens validiert werden. Informationen zu einem akzeptablen Verfahren finden Sie im Abschnitt 3.2.3 „Authentication of Individual Identity“ (Authentifizierung einer natürlichen Person) der Basisrichtlinie des CA/Browser-Forums bezüglich Mindestanforderungen für die Ausstellung und Verwaltung vertrauenswürdiger Zertifikate (CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates) in der Version 1.3.2 oder aktueller.

E-Mail-Adressen, z. B. in den Feldern „commonName“ oder „emailAddress“, müssen ebenfalls in der Erweiterung „Subject Alternate Name“ als rfc822Name-Eintrag vorhanden sein.
Subject Public Key Info

rsaEncryption mit einem RSA-Modulus von 2.048, 3.072 oder 4.096. Alternativ ecPublicKey mit secp256r1 oder secp384r1
Erweiterung Präsenz Kritisch Wert
Schlüsselverwendung (RSA) Erforderlich Ja

Bit-Positionen müssen festgelegt sein für entweder:
digitalSignature
und/oder
nonRepudiation/contentCommitment
Bit-Positionen können festgelegt sein für:
dataEncipherment
keyEncipherment

Andere Bit-Positionen dürfen nicht festgelegt sein.
Schlüsselverwendung (ECDH) Erforderlich

Bit-Positionen müssen festgelegt sein für:
digitalSignature
Bit-Positionen können festgelegt sein für:
nonRepudiation/contentCommitment
keyAgreement
encipherOnly (wenn keyAgreement festgelegt ist)
decipherOnly (wenn keyAgreement festgelegt ist)

Andere Bit-Positionen dürfen nicht festgelegt sein.
Erweiterte Schlüsselverwendung Erforderlich Beides

Muss vorhanden sein:
emailProtection
Darf nicht vorhanden sein:
serverAuth
codeSigning
timeStamping
anyExtendedKeyUsage

Basiseinschränkungen

 Optional Beides

Das Feld „cA“ darf, wenn vorhanden, nicht auf „true“ gesetzt sein.
Das Feld „pathLenConstraint“ darf nicht vorhanden sein.
Zertifikatrichtlinien Erforderlich Nein

Muss vorhanden sein: Ein „policyIdentifier“ muss angegeben werden, durch den die Richtlinie kenntlich gemacht wird, gemäß der das Zertifikat ausgestellt wurde. Der Wert darf nicht anyPolicy lauten.

Kann vorhanden sein: Das Feld cps, wenn vorhanden, muss einen gültigen HTTP- oder HTTPS-Link zur CPS enthalten, gemäß der das Zertifikat ausgestellt wurde.

Zugriff auf Zertifizierungsstelleninfos

 Optional Nein

caIssuers und, falls vorhanden, ocsp müssen mindestens einen öffentlich zugänglichen „HTTPuniformResourceIdentifier“ enthalten.

„AccessDescription“ darf keine Labels oder Parameter enthalten, die sich auf ein einzelnes Zertifikat beziehen.
CRL-Verteilungspunkte Erforderlich Nein

Mindestens ein öffentlich abrufbarer
„HTTPuniformResourceIdentifier“ muss vorhanden sein

(Hinweis)

Sperrserver müssen gemäß den folgenden Abschnitten der Richtlinie des CA/Browser-Forums bezüglich Mindestanforderungen für die Ausstellung und Verwaltung vertrauenswürdiger Zertifikate (CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates) in der Version 1.3.2 oder aktueller betrieben werden:

  • 4.9.7. CRL Issuance Frequency (Häufigkeit der Sperrlistenausgabe)
  • 4.9.9. On‐line Revocation/Status Checking Availability (Verfügbarkeit von Onlinesperr- und Statusprüfung)
  • 4.9.10. On‐line Revocation Checking Requirements (Anforderungen an die Onlinesperrprüfung)
  • 4.10.2. Verfügbarkeit des Dienstes

Alternativer Antragstellername

 Erforderlich Nein

Muss mindestens einen Eintrag des Typs „rfc822Name“ enthalten.
Darf keine Elemente des Typs
dNSName
iPAddress
uniformResourceIdentifier
enthalten.
Jeder rfc822Name-Eintrag muss mit öffentlich dokumentierten und geprüften Maßnahmen bestätigt werden, um sicherzustellen, dass die Organisation, die den Antrag einreicht, das mit der E-Mail-Adresse verknüpfte E-Mail-Konto kontrolliert oder vom Inhaber des E-Mail-Kontos autorisiert wurde, in seinem Namen zu handeln.

Andere Erweiterungen

 Optional Nein Können vorhanden sein.