Wie validiere ich SSL Zertifikate?

1. Einführung

Es darf kein Secorio Server-Authentifizierungszertifikat ausgestellt werden, bis wir die Kontrolle des Antragstellers über die Domain (s) bestätigt haben, die im Betreff des Zertifikats erscheint. Wir bezeichnen diesen Prozess als DCV (Domain Control Validation).
Cab Forum Reference :  https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf

Bis zur (und einschließlich) Version 1.09 dieses Dokuments konnte DCV mithilfe einer von drei Methoden ausgeführt werden:

• E-Mail-Challenge-Response
• Erstellung einer Datei auf dem HTTP-Server der Domäne
• Erstellung eines DNS-CNAME-Eintrags für diese Domäne

Die Details von Wie diese Methoden ausgeführt werden, wurde ab dieser Version 1.09 geändert. Diese Änderungen sind eine Reaktion auf die Überarbeitungen des Abschnitts «Validierung der Domain-Autorisierung oder -Kontrolle» im CA / B-Forum «Grundanforderungen», einschließlich der Änderungen, die sich im Abstimmungsverfahren befinden oder von denen erwartet wird, dass sie abgestimmt wurden, und zum Zeitpunkt des Abschlusses unserer Implementierung enthalten.

Dieses Dokument befasst sich mit den automatisierten Methoden zur Validierung der Kontrolle einer Domain. Es gibt andere Methoden, bei denen rechtliche Dokumente ausgetauscht werden, die rechtmäßig sind und im Rahmen unserer CPS- und CABF-Grundanforderungen zulässig sind, in diesem Dokument jedoch nicht weiter erwähnt werden.

2. Autorisierungsdomänenname

Wenn Sie ein Zertifikat von uns anfordern, teilen Sie uns einen oder mehrere vollqualifizierte Domänennamen (FQDNs) mit, die in Ihrem Zertifikat angezeigt werden sollen. Für jeden vollqualifizierten Domänennamen ist der «Autorisierungsdomänenname» der Domänenname, den Sie für die DCV verwenden.

Der Autorisierungsdomänenname kann mit dem zu validierenden FQDN identisch sein, oder der Autorisierungsdomänenname kann der FQDN sein, wobei einige Bezeichnungen von Anfang an entfernt wurden.

Beispiel: Wenn der im Zertifikat enthaltene vollqualifizierte Domänenname internal.example.com lautet, kann der Autorisierungsdomänenname internal.example.com oder example.com lauten

Wenn Sie ein Zertifikat für die beiden Domänen (www.example.com, example.com) anfordern, kann mit dem Autorisierungsdomänennamen von example.com eine einzige Überprüfung durchgeführt werden, mit der beide FQDNs überprüft werden Ein Autorisierungs-Domain-Name von www.example.com kann dies möglicherweise nicht.

Ein Autorisierungsdomänenname kann kein registrierungsgesteuerter Name und kein öffentliches Suffix sein. Das bedeutet, dass «co.uk» oder «com» keine Autorisierungsdomänennamen sein können und (z. B.) «pvt.k12.ma.us» kein Autorisierungsdomänenname sein kann, da es sich um ein öffentliches Suffix handelt.

Bei E-Mail-basiertem DCV (Abschnitt 3, unten) teilen Sie uns ausdrücklich mit, welche Domain Sie als Autorisierungsdomäne verwenden möchten.

Für DNS-basiertes DCV werden alle möglichen Autorisierungsdomänennamen überprüft.

Der Autorisierungsdomänenname enthält niemals ein Platzhalterzeichen (‹*›). Selbst wenn der FQDN ein Platzhalterzeichen enthält, ist dies beim Autorisierungsdomänennamen nicht der Fall. Beispiel: Wenn der im Zertifikat enthaltene vollqualifizierte Domänenname * .service.example.com lautet, kann der Name der Autorisierungsdomäne entweder example.com oder service.example.com lauten.

3. E-Mail-Challenge-Response

Bei der Bestellung wird eine E-Mail-Adresse aus einer Auswahlliste akzeptabler Optionen ausgewählt. An diese Adresse wird eine E-Mail mit einem eindeutigen Validierungscode gesendet. Die E-Mail sollte von jemandem empfangen werden, der die Kontrolle über die Domain hat. Dort kann er einem in der E-Mail angegebenen Link folgen und den Validierungscode eingeben, um die Kontrolle über die Domain zu bestätigen.

Die Liste der zulässigen E-Mail-Adressen für eine bestimmte Domain lautet :

• admin @
• Administrator @
• hostmaster @
• postmaster @
• Webmaster @

• Jede E-Mail-Adresse eines Administrators, Registranten, Technikers oder Zonenkontakts, die im WHOIS-Eintrag der Domain enthalten und für unser CA-System sichtbar ist.

Bei der Bestellung eines Zertifikats über die Webschnittstelle von Comodo Bei der Zertifikatanforderung über die Webschnittstelle wird standardmäßig E-Mail-Abfrage-Antwort-DCV angeboten. Die Liste der akzeptablen E-Mail-Adressen wird zur Auswahl angezeigt, basierend auf dem aus der CSR extrahierten allgemeinen Namen.

Bei der Bestellung eines Zertifikats über die API von Comodo Sobald die CSR vom Kunden empfangen wurde, muss der FQDN des allgemeinen Namens (CN) aus der CSR extrahiert werden. Die DecodeCSR-API kann verwendet werden oder jede andere verfügbare Methode. Der vollqualifizierte Domänenname kann dann an die GetDCVEmailAddressList-API übergeben werden, die eine vollständige Liste der zulässigen E-Mail-Adressen für diesen vollqualifizierten Domänennamen zurückgibt. NUR von GetDCVEmailAddressList zurückgegebene E-Mail-Adressen sind zulässig. Wenn eine E-Mail-Adresse, von der angenommen wird, dass sie im WHOIS-Datensatz für die Domain enthalten ist, nicht zurückgegeben wird, bedeutet dies, dass unser System sie nicht aus einer WHOIS-Abfrage extrahieren konnte und die Adresse daher nicht verwendet werden kann.

Sobald eine Auswahl aus der Liste der zulässigen E-Mail-Adressen getroffen wurde, kann diese Adresse als Parameter dcvEmailAddress an die AutoApplySSL-API übergeben werden. Sobald mit diesem Parameter AutoApplySSL aufgerufen wird, wird die DCV-E-Mail gesendet.

Aufgrund der Zwischenspeicherung des WHOIS-Datensatzergebnisses sollte der API-Aufruf von AutoApplySSL innerhalb von 24 Stunden nach dem API-Aufruf von GetDCVEmailAddressList erfolgen. Ein Aufruf von GetDCVEmailAddressList ist nicht erforderlich, wenn die Auswahl dcvEmailAddress aus den 5 Standard-E-Mail-Adressen stammt (dh nicht aus dem WHOIS-Datensatz der Domain). Auch wenn die an dcvEmailAddress übergebene E-Mail-Adresse aus dem WHOIS-Datensatz der Domain stammen soll, müssen Sie GetDCVEmailAddressList nicht aufrufen. Unsere einzige Anforderung ist, dass die von Ihnen gewählte E-Mail-Adresse von GetDCVEmailAddressList zurückgegeben wird.

Informationen zu Multi-Domain-Zertifikaten finden Sie in Abschnitt 9.

Der eindeutige Validierungscode ist nur 30 Tage gültig. Das heißt, jeder Versuch, den eindeutigen Validierungscode mehr als 30 Tage nach seiner Erstellung zu verwenden, schlägt fehl.

4. HTTP-basierte DCV

HTTP-basierte DCV muss ein HTTP-Server auf Port 80 oder ein HTTPS-Server auf Port 443 des Autorisierungsdomänennamens ausgeführt werden. Wir folgen CNAMEs, wenn wir HTTP-basiertes DCV vervollständigen. Wir suchen die Datei in jeder gültigen Autorisierungsdomäne, dh wir beginnen mit dem vollqualifizierten Domänennamen und entfernen dann ein oder mehrere Bezeichnungen von links nach rechts im vollqualifizierten Domänennamen und suchen die Datei in jeder Zwischendomäne.

Vor der Übermittlung an Comodo werden zwei Hashes der CSR generiert. Auf dem HTTP / S-Server des Autorisierungsdomänennamens wird eine Nur-Text-Datei mit einem Hash als Dateinamen und einem Hash in der Textdatei selbst erstellt. Wir nennen diese Textdatei das Request Token. Der Inhalt des Anforderungstokens wird in den folgenden Abschnitten 7 und 8 ausführlicher beschrieben.

Beispiel: Eine CSR wird mit CN = www.example.com generiert. Der Name der Autorisierungsdomäne lautet example.com. Die CSR wird sowohl mit dem MD5- als auch mit dem SHA-256-Hashing-Algorithmus gehasht.

Es wird eine Textdatei erstellt, die den SHA-256-Hash und die Domain ‹comodoca.com› in der nächsten Zeile enthält.

c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f comodoca.com

Die Datei wird dann im folgenden Format benannt: <MD5-Hash> .txt und im Verzeichnis /.well-known/pki-validation des HTTP-Servers abgelegt:

http://example.com/.well-known/ pki-validation / C7FBC2039E400C8EF74129EC7DB1842C.txt

Sobald die Bestellung bei Comodo eingeht und HTTP-basiertes DCV angegeben ist, prüft das Comodo CA-System, ob die Textdatei und ihr Inhalt vorhanden sind. Wenn die Datei gefunden wird und die Hashwerte übereinstimmen, wird die Domänensteuerung überprüft.

Bei der Bestellung eines Zertifikats über die Comodo-Weboberfläche Die Hash-Werte werden während des Bestellvorgangs über die Weboberfläche berechnet und angezeigt. Sie befinden sich auf derselben Seite wie die Optionen für die DCV-E-Mail-Adresse. Sowohl die MD5- als auch die SHA-256-Hashwerte der CSR werden angezeigt und müssen wie oben beschrieben in der von Ihrem HTTP-Server bereitgestellten Datei gespeichert werden, bevor Sie mit der Bestellung fortfahren.

Bei der Bestellung eines Zertifikats über die API von Comodo Generieren Sie die Hashes aus dem CSR, bevor die Bestellung an Comodo gesendet wird. Die Hashes MÜSSEN aus der DER-codierten (dh binären) Version der CSR generiert werden – nicht aus der base64-PEM-codierten Version. Variationen in der PEM-Codierung können unterschiedliche Hash-Werte verursachen, wohingegen die Hash-Werte der DER-codierten Version konstant bleiben. Die Datei muss mit der UPPERCASE-Formatierung des MD5-Hash erstellt werden, da bei den meisten HTTP-Servern die Groß- und Kleinschreibung beachtet wird. Das Comodo CA-System sucht nur nach dem UPPERCASE-Hash-Dateinamen. Die Datei muss mit der Erweiterung .txt erstellt werden. Der SHA-256-Hash in der Datei unterscheidet nicht zwischen Groß- und Kleinschreibung.

Wenn der AutoApplySSL-Aufruf erfolgt, muss ein zusätzlicher Parameter angegeben werden, um die Verwendung von HTTP / S-basiertem DCV anzuzeigen. Dieser Parameter heißt ‹dcvMethod› und muss auf den UPPERCASE-Wert gesetzt werden: HTTP_CSR_HASH für HTTP an Port 80 oder HTTPS_CSR_HASH für HTTPS an Port 443.

Informationen zu Multidomänenzertifikaten finden Sie in Abschnitt 9 (Hinweise).

5. DNS-CNAME-basiertes DCV

DNS-CNAME-basiertes DCV erfordert die Erstellung eines eindeutigen CNAME-Datensatzes, der auf Comodo verweist. Wir suchen bei jeder gültigen Autorisierungsdomäne nach dem CNAME, dh wir beginnen mit dem vollqualifizierten Domänennamen und entfernen dann ein oder mehrere Bezeichnungen von links nach rechts im vollqualifizierten Domänennamen und suchen nach dem CNAME in jeder Zwischendomäne.

ZB für eine Zertifikatsanforderung für einen vollqualifizierten Domänennamen von * .mail.internal.example.com würden wir an diesen Stellen und in dieser Reihenfolge nach dem CNAME suchen: mail.internal.example.com internal.example.com example.com The Authorization Der Domain-Name ist derjenige, auf dem wir ihn finden.

Vor der Übermittlung an Comodo werden zwei Hashes der CSR generiert. Unter dem Autorisierungsdomänennamen wird ein CNAME-DNS-Eintrag erstellt. Wir nennen den Inhalt des CNAME das Request Token. Der Inhalt des Anforderungstokens wird in den folgenden Abschnitten 7 und 8 ausführlicher beschrieben.

Das Format des CNAME lautet: ‹_› <MD5-Hash> .Authorization Domain Name CNAME <SHA-256-Hash>. [<UniqueValue>.] Comodoca.com

Beachten Sie den führenden Unterstrich am Anfang des MD5-Hashs.

Beispiel: Eine CSR wird mit CN = www.example.com generiert. Die CSR wird sowohl mit dem MD5- als auch mit dem SHA-256-Hashing-Algorithmus gehasht.

MD5: c7fbc2039e400c8ef74129ec7db1842c SHA-256: c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

DNS CNAME basierend DCV auszuführen, der folgende DNS – CNAME – Eintrag vor dem Absenden die Bestellung erstellt werden kann:

_c7fbc2039e400c8ef74129ec7db1842c.example.com CNAME c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.comodoca.com

Dann wird die Anforderung an Comodo vorgelegt, die Das Vorhandensein dieses CNAME-DNS-Eintrags wird überprüft, und die Domänensteuerung wird nachgewiesen, wenn sie gefunden wird.

Bei der Bestellung eines Zertifikats über die Comodo-Weboberfläche Die Hash-Werte werden während des Bestellvorgangs über die Weboberfläche berechnet und angezeigt. Sie befinden sich auf demselben Bildschirm wie die Optionen für die DCV-E-Mail-Adresse. Sowohl die MD5- als auch die SHA-256-Hashwerte der CSR werden angezeigt und müssen, wie in den obigen Anweisungen angegeben, als CNAME-Eintrag zu DNS hinzugefügt werden, bevor Sie mit der Bestellung fortfahren.

Bei der Bestellung eines Zertifikats über die API von Comodo Die Hashes werden aus dem CSR generiert, bevor die Bestellung an Comodo gesendet wird. Die Hashes MÜSSEN aus der DER-codierten (dh binären) Version der CSR generiert werden – nicht aus der base64-PEM-codierten Version. Variationen in der PEM-Codierung können unterschiedliche Hash-Werte verursachen, wohingegen die Hash-Werte der DER-codierten Version konstant bleiben. Der DNS-CNAME-Eintrag wird dann im obigen Format erstellt.

Wenn der AutoApplySSL-Aufruf erfolgt, muss ein zusätzlicher Parameter angegeben werden, um die Verwendung von CNAME-basiertem DCV anzuzeigen. Dieser Parameter heißt ‹dcvMethod› und muss auf den UPPERCASE-Wert ‹CNAME_CSR_HASH› gesetzt werden.

Informationen zu Multi-Domain-Zertifikaten finden Sie in Abschnitt 9 (Anmerkungen).

6. Token anfordern

Ein Anfragetoken ist der Text, den Sie in eine Datei auf Ihrem Webserver oder in eine DNS-Antwort einfügen müssen, um uns mitzuteilen, dass dieser Server wirklich unter Ihrer Kontrolle steht. Es gibt 2 Informationen, die immer in einem Comodo-Validierungstoken enthalten sind. Wenn Sie ein Benutzer mit hohem Datenaufkommen sind oder öffentliche Schlüssel häufig wiederverwenden, wird es wahrscheinlich einen dritten geben. a) (erforderlich) Der SHA-256-Hash Ihres PKCS # 10-CSR. Der Hash MUSS aus der DER-codierten (dh binären) Version des CSR generiert werden – nicht aus der base64-PEM-codierten Version. Variationen in der PEM-Codierung können unterschiedliche Hash-Werte verursachen, wohingegen die Hash-Werte der DER-codierten Version konstant bleiben. Sie MÜSSEN eine hexadezimale Darstellung (Basis 16) des Hashs verwenden. b) (erforderlich) die Zeichenfolge ‹comodoca.com› Dies liegt nicht nur daran, dass wir unseren Namen gerne in Lichtern sehen. Dies stellt sicher, dass das Anforderungs-Token für die Validierung von Comodo generiert wurde, und hilft so, einen möglichen Wiederholungsangriff auf den Validierungsprozess zu verhindern. c) (optional) uniqueValue Dies ist ein alphanumerischer Wert, der bis zu 20 Zeichen lang sein kann. Es wird von Ihnen, dem Antragsteller, erstellt und Sie müssen uns denselben eindeutigen Wert mitteilen, wenn Sie den CSR einreichen.

Es ist nicht zulässig, dasselbe Anforderungstoken für mehr als ein Zertifikat erneut zu verwenden. Dies bedeutet, dass eine nachfolgende Bestellung, z. B. eine Erneuerung, für ein Zertifikat, das genau dieselbe CSR wie die ursprüngliche Bestellung verwendet, fehlschlägt.

Es gibt verschiedene Möglichkeiten, um sicherzustellen, dass jeder CSR (und damit jedes Anforderungstoken) eindeutig ist. a) Sie können für jede Anfrage ein neues Schlüsselpaar verwenden. b) Sie können eine andere Liste von Domainnamen im CSR anfordern. Beispiel: Eine CSR für (a.example.com, b.example.com) unterscheidet sich von einer CSR, die denselben Schlüssel verwendet, wobei jedoch die Reihenfolge der Domänen in (b.example.com, a.example.com) geändert wird. . c) Sie können andere Materialien in den CSR aufnehmen, die nicht Teil des Zertifikats sein sollen, deren Anwesenheit jedoch ausreicht, um die Eindeutigkeit des CSR sicherzustellen. Beispielsweise kann ein Abfragekennwort als Attribut in der CSR enthalten sein. Dies geschieht in einfacher Weise mit dem OpenSSL-Befehlszeilentool und unter Angabe eines Abfragekennworts, wenn Sie dazu aufgefordert werden. Es kann jedoch auch auf andere Weise implementiert werden, um ein Abfragekennwort (oder einen anderen Inhalt) als Attribut gemäß RFC2986 einzuschließen. Wenn keines dieser Elemente für Sie geeignet ist, können Sie das zusätzliche eindeutige Element für das Anforderungs-Token angeben, indem Sie einen eindeutigen Wert wie oben beschrieben in das Anforderungs-Token einfügen. Denken Sie daran, dass Sie dieses zusätzliche eindeutige Element nur hinzufügen müssen, wenn Sie dieselbe CSR mit mehreren Zertifikaten verwenden möchten.

7. Format der Anforderungstoken und Beispiele

Bitte beachten Sie, dass der Inhalt des Anforderungstokens im vorherigen Abschnitt dieses Dokuments, Abschnitt 7 „Anforderungstoken“, definiert ist. Bitte beachten Sie, dass in den folgenden Beispielen der MD5-Hashwert immer hexadezimal codiert ist und immer in Großbuchstaben geschrieben werden muss.

a) HTTP-basiertes DCV Bei Verwendung von HTTP-basiertem DCV sollte das Anforderungstoken als aufeinanderfolgende Zeilen in einer Textdatei angezeigt werden. Die Datei sollte vollständig aus Zeichen im US-amerikanischen 7-Bit-ASCII-Satz bestehen. Am Anfang der Datei sollte keine Stückliste (Byte Order Mark) stehen. Aufeinanderfolgende Zeilen in der Textdatei können entweder durch einzelne Zeilenumbrüche (LF, ‹\\ n›, 0x0A) oder durch Zeilenumbrüche + Zeilenumbrüche (CRLF, ‹\\ r \\ n›, 0x0D 0x0A) getrennt werden.

Die zu überprüfende URL wird folgendermaßen gebildet: http [s]: // <Autorisierungsdomänenname> /. Well-known / pki-validation / <MD5-Hash> .txt

ZB. http://example.com/.well-known/pki-validation/C7FBC2039E400C8EF74129EC7DB1842C.txt könnte enthalten: c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f comodoca.com 10af9db9tu

Beachten Sie, dass dritte Leitung (10af9db9tu), die optionale uniqueValue. Wenn Sie keinen uniqueValue angeben, lassen Sie diese dritte Zeile weg.

b) DNS CNAME-basiertes DCV Wenn Sie DNS CNAME-basiertes DCV verwenden, sollte das Anforderungs-Token in der CNAME RDATA (dh auf der rechten Seite Ihrer DNS CNAME-Definition) als aufeinanderfolgende Bezeichnungen angezeigt werden. Das Format hat immer die Form: ‹_› <MD5-Hash>. <Autorisierungsdomänenname> CNAME <SHA-256-Hash>. [<EindeutigerWert>.] Comodoca.com.

Beachten Sie, dass ein hexadezimal (Base-16) codierter SHA-256-Hash nicht in ein einzelnes DNS-Label passt, da er zu lang ist. Der SHA-256-Hash sollte daher in zwei Labels mit jeweils 32 Zeichen Länge aufgeteilt werden. Beispiel: # 1, verwendet Hexadezimalcodierung (Basis 16) und teilt den SHA-256-Hash in zwei Bezeichnungen (dh Einfügen eines ‹.› In der Mitte des SHA256-Hash-Werts). Ein DNS-Eintrag kann wie folgt eingerichtet werden: _c7fbc2039e400c8ef74129ec7db1842c. example.com. CNAME c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.comodoca.com.

Zum Beispiel # 2 mit Hexadezimalcodierung (Basis 16) und Aufteilen des SHA-256-Hash in zwei Bezeichnungen (dh Einfügen eines ‹.› In der Mitte des SHA256-Hash-Werts) und Einschließen eines eindeutigen Werts kann ein DNS-Eintrag sein Setup als: _c7fbc2039e400c8ef74129ec7db1842c.example.com. CNAME c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.10af9db9tu.comodoca.com.

8. Hinweise

Alle Zertifikatstypen (Single, Wildcard, MDC / UCC) können mit jedem der verfügbaren DCV-Mechanismen validiert werden. Zertifikate mit mehreren Domänen können für jeden vollqualifizierten Domänennamen in der Anforderung unterschiedliche Mechanismen verwenden.

Neuausstellung Neuausstellungen der Zertifikate erfordern eine erneute Validierung.

Die erneute Ausgabe erfordert keine erneute Validierung bereits validierter FQDNs, wenn derselbe private Schlüssel zum Generieren der CSR für die erneute Ausstellung verwendet wird. Wenn ein neuer privater Schlüssel zum Generieren der CSR verwendet wird, muss DCV für alle vollqualifizierten Domänennamen in der Anforderung nach einer der verfügbaren Methoden für die Bestellung erneut ausgeführt werden, bevor das Zertifikat ausgestellt werden kann. Dies gilt auch für erneute Probleme, die das Hinzufügen oder Entfernen von Domänen für Zertifikate mit mehreren Domänen erleichtern.

DCV-E-Mails erneut senden

DCV-E-Mails können über das Webinterface oder über die API ‹ResendDCVEmail› erneut gesendet werden. Dadurch wird die DCV-E-Mail bei Einzelzertifikatsbestellungen erneut gesendet, und bei Mehrdomänenzertifikatsbestellungen werden alle ausstehenden (dh nicht validierten) FQDNs erneut gesendet.

Wenn für eine Domain eine Nicht-E-Mail-DCV-Methode ausgewählt wurde (wie in den Abschnitten 4 und 5 beschrieben), kann die ResendDCVEmail-API verwendet werden, um die Häufigkeit zurückzusetzen, mit der die praktische Steuerung getestet wird.

www. Subdomains

Wir betrachten den Nachweis der Kontrolle über «www.DOMAIN» nicht länger als Nachweis der Kontrolle über «DOMAIN». Wenn Sie zuvor bei uns ein Zertifikat für die 2 vollqualifizierten Domänennamen (www.example.com und example.com) bestellt und beispielsweise mit HTTP_CSR_HASH auf www.example.com validiert haben, haben wir dies verwendet, um auch die Steuerung von example.com zu demonstrieren. Das ist heute nicht mehr der Fall.

Es bleibt der Fall, dass die Validierung der Kontrolle von example.com ausreicht, damit die Validierung eines Zertifikats sowohl example.com als auch www.example.com enthält.

Multi-Domain-Zertifikate

Für Multi-Domain-Zertifikate (MDCs, UCCs) ist DCV für alle Domainnamen in allen Bestellungen erforderlich. Alle verfügbaren Mechanismen (E-Mail, HTTP und DNS CNAME) können verwendet werden. Die webbasierte Oberfläche hierfür wird bei Auftragserteilung zur Verfügung gestellt. Melden Sie sich einfach in Ihrem Konto an und suchen Sie die Bestellung. Es wird ein Bildschirm angezeigt, in dem Sie eine gültige E-Mail-Adresse auswählen können, um jeden FQDN im Zertifikat zu validieren. Unser System führt WHOIS-Suchvorgänge für alle Domänen durch, um die E-Mail-Adressen bereitzustellen, die nach Möglichkeit aus diesen Datensätzen stammen. Mit der Schaltfläche «Aktualisieren» können Sie die Daten auf dem Bildschirm aktualisieren. Das Lesen einer großen Anzahl von FQDNs in einem einzelnen Zertifikat dauert einige Zeit, bis alle WHOIS-Einträge gelesen sind. Über die Webschnittstelle können auch die HTTP-, HTTPS- oder DNS-CNAME-Mechanismen für jeden FQDN ausgewählt werden.

Sie können einige FQDNs aus dem Zertifikat entfernen, wenn sie nicht validiert werden können, und das Zertifikat nur mit den bis zu diesem Zeitpunkt validierten Domänen ausstellen.

API für Multidomänenzertifikate Details Die API kann verwendet werden, um Multidomänenzertifikate über E-Mail-basiertes DCV anzufordern und zu validieren. Die Änderungen an der vorhandenen API und den Prozessen für die Bestellung sind:

• Anstelle des Parameters ‹dcvEmailAddress›, den wir für Einzeldomänenzertifikate verwenden, gibt es den Parameter ‹dcvEmailAddresses› (beachten Sie den Plural).

Dieser Parameter akzeptiert eine Liste von E-Mail-Adressen, die für DCV verwendet werden sollen. Es muss eine E-Mail-Adresse pro FQDN im Parameter ‹domainNames› geben, und sie müssen in genau derselben Reihenfolge vorliegen. Im Gegensatz zu einzelnen Zertifikatsbestellungen über die API lehnt unser System Bestellungen aufgrund falscher DCV-E-Mail-Adressen nicht ab. Sie werden akzeptiert, aber es wird keine E-Mail gesendet. Sie können dann über das Webinterface bearbeitet werden. Es ist wichtig, für jeden Domainnamen nur gültige E-Mail-Adressen für die DCV-E-Mail-Adresse zu übergeben. Gültige E-Mail-Adressen können entweder über eine der Standard-Adressen 5 (weiter oben in diesem Dokument aufgeführt) oder durch Aufrufen der GetDCVEmailAddressList-API für diese Domäne abgerufen werden. Sie können auch eine unabhängige WHOIS-Suche durchführen und eine E-Mail senden, die Sie aus der Ausgabe an unsere API extrahieren können. Jedoch, Bitte beachten Sie, dass unser System E-Mail-Adressen nur in einer WHOIS-Suche über die Befehlszeile «sehen» kann. E-Mail-Adressen, die in webbasierten WHOIS-Abfragen oder in anderen Systemen, die menschliche Challenge-Response-Systeme erfordern (z. B. CAPTCHAS), sichtbar sind, können von unserem System nicht verwendet werden. Die Bestellung wartet auf die Bestätigung, bis Sie sich anmelden und die DCV-E-Mail-Adresse über das Web aktualisieren -Schnittstelle.

Unser System wird versuchen, so wenig E-Mails wie möglich zu versenden. Wenn innerhalb eines registrierten Domainnamens mehrere FQDNs existieren, wird eine E-Mail gesendet. Die API kann auch zum Überprüfen von Domänen mithilfe der HTTP- und DNS-CNAME-Mechanismen verwendet werden. Wie oben sollte der Parameter ‹dcvEmailAddresses› verwendet werden.

Für jede Domain im Parameter ‹domainNames› können Sie nacheinander eine der folgenden Angaben machen:

• Eine DCV-E-Mail-Adresse, wie in diesem Dokument beschrieben.

• Der Wert ‹HTTPCSRHASH› – und für diesen ‹Domänennamen› wird der HTTP-DCV-Mechanismus verwendet.

• Der Wert ‹HTTPSCSRHASH› – und für diesen ‹Domänennamen› wird der HTTPS-DCV-Mechanismus verwendet. Der Wert ‹CNAMECSRHASH› – und für diesen ‹domainName› wird der DNS CNAME DCV-Mechanismus verwendet.

 

Wenn Sie möchten, dass alle Domänen durch einen der alternativen Mechanismen (HTTP oder HTTPS oder DNS CNAME) überprüft werden, übergeben Sie einfach einen einzelnen Wert für den Parameter ‹dcvEmailAddresses› von:

• ALLHTTPCSRHASH oder

• ALLHTTPSCSRHASH oder

• ALLCNAMECSRHASH Dies sollte der einzige für den Parameter übergebene Wert sein, und es wird versucht, alle Domänen über denselben Mechanismus zu überprüfen.

Erweiterter Multidomänenstatus Die ‹CollectSSL›-API bietet einen erweiterten Status für Multidomänenzertifikate, in dem alle angeforderten FQDNs einer Bestellung sowie der aktuelle DCV-Status der einzelnen Zertifikate angezeigt werden. Durch Aufrufen der ‹CollectSSL›-API mit den korrekten Authentifizierungsdetails, der Bestell-ID und einem zusätzlichen Parameter:› showMDCDomainDetails ‹mit dem Wert› Y ‹werden diese Informationen als Antwort auf eine Statusabfrage bereitgestellt.