How do I validate SSL certificates?

1. Introduction

No Secorio Server authentication certificate may be issued until we have confirmed the applicant's control over the domain (s) that appears in the subject of the certificate. We call this process DCV (Domain Control Validation).
Cab Forum Reference: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf

Up to (and including) version 1.09 of this document, DCV could be run in one of three ways:

• Email Challenge Response
• Creation of a file on the HTTP server of the domain
• Creation of a DNS CNAME record for this domain

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.

This document deals with the automated methods for validating the control of a domain. There are other ways that legal documents are exchanged that are legal and permitted under our basic CPS and CABF requirements, but are not mentioned in this document.

2. Authorization domain name

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.

The authorization domain name can be the same as the FQDN to be validated, or the authorization domain name can be the FQDN, with some labels removed from the beginning.

For example, if the fully qualified domain name included in the certificate is internal.example.com, the authorization domain name can be internal.example.com or example.com

If you request a certificate for the two domains (www.example.com, example.com), the authorization domain name from example.com can be used to perform a single check that checks both FQDNs. An authorization domain name from www. example.com may not be able to do this.

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.

In the case of email-based DCV (Section 3, below), please let us know which domain you want to use as the authorization domain.

All possible authorization domain names are checked for DNS-based DCV.

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

When ordering, an email address is selected from a selection list of acceptable options. An email with a unique validation code will be sent to this address. The email should be received by someone who has control over the domain. There he can follow a link given in the email and enter the validation code to confirm the control over the domain.

The list of allowed email addresses for a specific domain is :

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

• Any email address of an administrator, registrant, technician or zone contact that is included in the WHOIS entry of the domain and is visible to our CA system.

When ordering a certificate via the Comodo web interface, by default, email request-response-DCV is offered when requesting a certificate via the web interface. The list of acceptable email addresses is displayed for selection based on the common name extracted from the CSR.

When ordering a certificate via the Comodo API Once the CSR has been received by the customer, the FQDN of the common name (CN) must be extracted from the CSR. The DecodeCSR API can be used or any other available method. The fully qualified domain name can then be passed to the GetDCVEmailAddressList API, which returns a full list of allowed email addresses for this fully qualified domain name. ONLY email addresses returned by GetDCVEmailAddressList are allowed. If an email address that is believed to be in the WHOIS record for the domain is not returned, it means that our system could not extract it from a WHOIS query and therefore did not use the address can be.

As soon as a selection from the list of permissible email addresses has been made, this address can be passed to the AutoApplySSL API as parameter dcvEmailAddress. As soon as AutoApplySSL is called with this parameter, the DCV email is sent.

Due to the temporary storage of the WHOIS data record result, the API call to AutoApplySSL should take place within 24 hours after the API call to GetDCVEmailAddressList. It is not necessary to call GetDCVEmailAddressList if the selection dcvEmailAddress comes from the 5 standard email addresses (ie not from the WHOIS record of the domain). Even if the email address passed to dcvEmailAddress should come from the domain's WHOIS record, you do not need to call GetDCVEmailAddressList. Our only requirement is that the email address you choose is returned by GetDCVEmailAddressList.

For information on multi-domain certificates, see section 9.

The unique validation code is only valid for 30 days. That is, any attempt to use the unique validation code more than 30 days after it was created will fail.

4. HTTP-based DCV

HTTP-based DCV must run an HTTP server on port 80 or an HTTPS server on port 443 of the authorization domain name. We follow CNAMEs when we complete HTTP based DCV. We search for the file in every valid authorization domain, ie we start with the fully qualified domain name and then remove one or more labels from left to right in the fully qualified domain name and search for the file in each intermediate domain.

Before the transmission to Comodo, two hashes of the CSR are generated. A plain text file with a hash as the file name and a hash in the text file itself is created on the HTTP / S server of the authorization domain name. We call this text file the request token. The content of the request token is described in more detail in sections 7 and 8 below.

Example: A CSR is generated with CN = www.example.com. The authorization domain name is example.com. The CSR is hashed using both the MD5 and SHA-256 hashing algorithms.

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

The file is then named in the following format: .txt and stored in the directory /.well-known/pki-validation of the HTTP server:

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

As soon as the order is received by Comodo and the HTTP-based DCV is specified, the Comodo CA system checks whether the text file and its content are available. If the file is found and the hash values match, the domain controller is checked.

When ordering a certificate via the Comodo web interface The hash values are calculated and displayed during the ordering process via the web interface. They are on the same page as the DCV email address options. Both the MD5 and SHA-256 hash values of the CSR are displayed and, as described above, must be saved in the file provided by your HTTP server before proceeding with the order.

When ordering a certificate via the Comodo API, generate the hashes from the CSR before the order is sent to Comodo. The hashes MUST be generated from the DER encoded (ie binary) version of the CSR - not from the base64 PEM encoded version. Variations in the PEM coding can cause different hash values, whereas the hash values of the DER-coded version remain constant. The file must be created with the UPPERCASE formatting of the MD5 hash, since most HTTP servers are case-sensitive. The Comodo CA system only searches for the UPPERCASE hash file name. The file must be created with the extension .txt. The SHA-256 hash in the file is not case-sensitive.

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.

For information on multi-domain certificates, please see Section 9 (Notices).

5. DNS-CNAME-based DCV

DNS-CNAME-based DCV requires the creation of a unique CNAME record that points to Comodo. We search for the CNAME at every valid authorization domain, ie we start with the fully qualified domain name and then remove one or more labels from left to right in the fully qualified domain name and search for the CNAME in each intermediate domain.

For example, for a certificate request for a fully qualified domain name from * .mail.internal.example.com, we would search for the CNAME in these places and in this order: mail.internal.example.com internal.example.com example.com The Authorization Der Domain name is the one we find it on.

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

Note the leading underscore at the beginning of the MD5 hash.

Example: A CSR is generated with CN = www.example.com. The CSR is hashed using both the MD5 and SHA-256 hashing algorithms.

MD5: c7fbc2039e400c8ef74129ec7db1842c SHA-256: c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

To run DNS CNAME based on DCV, the following DNS CNAME record can be created before submitting the order:

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

Then the request is submitted to Comodo, which checks for the presence of this CNAME DNS record, and proves domain control if it is found.

When ordering a certificate via the Comodo web interface The hash values are calculated and displayed during the ordering process via the web interface. They are on the same screen as the DCV email address options. Both the MD5 and SHA-256 hash values of the CSR are displayed and, as indicated in the instructions above, must be added to DNS as a CNAME record before proceeding with the order.

When ordering a certificate via the Comodo API The hashes are generated from the CSR before the order is sent to Comodo. The hashes MUST be generated from the DER encoded (ie binary) version of the CSR - not from the base64 PEM encoded version. Variations in the PEM coding can cause different hash values, whereas the hash values of the DER-coded version remain constant. The DNS CNAME record is then created in the above format.

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.

For information on multi-domain certificates, see Section 9 (Notes).

6. Request token

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.

It is not allowed to reuse the same request token for more than one certificate. This means that a subsequent order, e.g. For example, a renewal for a certificate that uses the exact same CSR as the original order fails.

There are several ways to ensure that every CSR (and therefore every request token) is unique. a) You can use a new key pair for each request. b) You can request a different list of domain names in the CSR. Example: A CSR for (a.example.com, b.example.com) differs from a CSR that uses the same key, but changes the order of the domains in (b.example.com, a.example.com) becomes. , c) You can include other materials in the CSR that should not be part of the certificate, but the presence of which is sufficient to ensure the uniqueness of the CSR. For example, a query password can be included as an attribute in the CSR. This is easily done using the OpenSSL command line tool and specifying a query password when prompted. However, it can be implemented in other ways to include a query password (or other content) as an attribute according to RFC2986. If none of these elements are suitable for you, you can specify the additional unique element for the request token by inserting a unique value into the request token as described above. Keep in mind that you only need to add this additional unique element if you want to use the same CSR with multiple certificates.

7. Format of request tokens and examples

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.

The URL to be checked is formed as follows: http [s]: // authorization domain name /. Well-known / pki-validation / MD5-Hash .txt

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

Note that third line (10af9db9tu), the optional uniqueValue. If you do not specify a uniqueValue, omit this third line.

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. Notes

All types of certificates (single, wildcard, MDC / UCC) can be validated using any of the available DCV mechanisms. Multi-domain certificates can use different mechanisms for each fully qualified domain name in the request.

Reissue Certificates reissue require revalidation.

Reissue does not require revalidation of already validated FQDNs if the same private key is used to generate the CSR for the reissue. If a new private key is used to generate the CSR, DCV must be rerun for all fully qualified domain names in the request for one of the available methods for ordering before the certificate can be issued. This also applies to renewed problems that make adding or removing domains easier for certificates with multiple domains.

Resend DCV emails

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.

If a non-email DCV method has been selected for a domain (as described in sections 4 and 5), the ResendDCVEmail API can be used to reset the frequency with which the practical control is tested.

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.

It remains the case that the validation of the control of example.com is sufficient for the validation of a certificate to include both example.com and www.example.com.

Multi-Domain Certificates

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.

You can remove some FQDNs from the certificate if they cannot be validated and only issue the certificate with the domains validated up to that point.

Multi-Domain Certificate API Details The API can be used to request and validate multi-domain certificates using email-based DCV. The changes to the existing API and the processes for the order are:

• 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:

• A DCV email address as described in this document.

• 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 This should be the only value passed for the parameter, and an attempt is made to check all domains using the same mechanism.

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.