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 und Änderungen sind jederzeit und ohne Angabe von Gründen möglich.
Achten Sie darauf, dass installierte Erweiterungen nicht anderen Erweiterungen im selben Zertifikat widersprechen. Wenn z. B. „nsCertTypes“ definert 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.
Informationen zum öffentlichen Schlüssel des Subjekts	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ültigkeitsdauer			Keine bestimmten Anforderungen
Subjekt-DN			Keine bestimmten Anforderungen
Informationen zum öffentlichen Schlüssel des Subjekts			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.
Sperrlisten-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ültigkeitsdauer			Unterschied zwischen „notBefore“ und „notAfter“ Sollte nicht größer als 10 Jahre sein und darf nicht größer als 20 Jahre sein
Subjekt-DN			Sollte die Verwendung der CA angeben
Informationen zum öffentlichen Schlüssel des Subjekts			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.
Sperrlisten-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. Service Availability (Dienstverfügbarkeit)
Andere Erweiterungen	Optional	Nein	Können vorhanden sein

Zertifikate 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ültigkeitsdauer			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.
Informationen zum öffentlichen Schlüssel des Subjekts			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, wenn vorhanden, ocsp müssen mindestens einen öffentlich zugänglichen „HTTPuniformResourceIdentifier“ haben. „AccessDescription“ darf keine Labels oder Parameter enthalten, die sich auf ein einzelnes Zertifikat beziehen.
Sperrlisten-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. Service Availability (Dienstverfügbarkeit)
Alternativer Antragstellername	Erforderlich	Nein	Muss mindestens einen Eintrag des Typs „rfc822Name“ enthalten Darf keine Element des folgenden Typs enthalten: dNSName iPAddress uniformResourceIdentifier Jeder „rfc822Name“ muss über öffentlich dokumentierte und geprüfte Maßnahmen bestätigt werden, damit sichergestellt wird, dass die Entität, die die Anfragen einreicht, das E-Mail-Konto kontrolliert, das mit der E-Mail-Adresse verknüpft ist oder durch den E-Mail-Kontoinhaber autorisiert wurde, in dessen Namen zu handeln.
Andere Erweiterungen	Optional	Nein	Können vorhanden sein

Wählen Sie den Abschnitt aus, zu dem Sie Feedback geben möchten

War das hilfreich?

Wie können wir die Seite verbessern?

S/MIME-Zertifikatprofile

Regeln für Zertifikatsketten

Stamm-CA

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

Zwischen-CA, die die Endentität ausgibt

Zertifikate für Endentitäten

War das hilfreich?

Benötigen Sie weitere Hilfe?

Mögliche weitere Schritte:

Was ist das Problem an dieser Auswahl?

Zusätzliche Informationen oder Vorschläge freigeben