Ich versuche, ein selbst signiertes Wildcard-Zertifikat für die Verwendung durch Apache einzurichten. Normalerweise ist das ziemlich unkompliziert. Ich lege einfach einen alternativen Betreffnamen mit der Stammdomäne fest und gebe *.dcrdev.com im Feld „Allgemeiner Name“ an. Das scheint jedoch nicht zu funktionieren – wenn ich versuche, die Site in Chrome aufzurufen oder sie in SSLABs zu testen, werden URL-Fehlübereinstimmungen beim Zugriff auf eine Subdomäne wie www.dcrdev.com oder subdomain1.dcrdev.com gemeldet. Ich bin mir nicht sicher, warum, wenn ich die Zertifikatsinformationen in Chrome ansehe, wird der allgemeine Name als *.dcrdev.com angezeigt.
Mein CSR:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
lah blah
Mein Zertifikat:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1048577 (0x100001)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Root Authority, CN=*.dcrdev.com/[email protected]
Validity
Not Before: Oct 13 23:41:03 2015 GMT
Not After : Oct 10 23:41:03 2025 GMT
Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
Blah blah
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
83:2D:84:F1:E2:B0:72:30:E6:3B:6A:F6:8E:6A:68:8E:3F:D4:69:44
X509v3 Authority Key Identifier:
keyid:F5:A6:82:E2:DD:52:10:CE:FD:C5:C7:E1:E9:CF:C6:8C:30:26:D7:DC
X509v3 Subject Alternative Name:
DNS:dcrdev.com
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
Blah blah
Antwort1
Crossdupe vonhttps://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found.
Der allgemeine Betreffname ist für HTTPS-Zertifikate nicht mehr maßgeblich.
Soweit ich weiß, gibt es dafür kein Standardwort, aberSeit einigen Jahren ist es üblich, dass Browser usw. die Erweiterung „SubjectAlternativeName“ (SAN) verwenden, wenn sie vorhanden ist, und „CommonName“ (CN) im Betreff nur, wenn SAN fehlt. In Ihrem Zertifikat ist SAN vorhanden dcrdev.com, also stimmt nur das überein.
aktualisieren:gefunden inRFC2818 3.1:
Wenn eine „subjectAltName“-Erweiterung vom Typ „dNSName“ vorhanden ist, MUSS diese als Identität verwendet werden. Andernfalls MUSS das (spezifischste) Feld „Common Name“ im Feld „Subject“ des Zertifikats verwendet werden. Obwohl die Verwendung des „Common Name“ gängige Praxis ist, wird sie nicht mehr empfohlen. Zertifizierungsstellen werden dazu angehalten, stattdessen den „dNSName“ zu verwenden.
Dieser RFC stammte vom Mai 2000, aber soweit ich mich erinnere, wurde bei den Zertifikaten, die ich gefunden habe, SAN erst ab 2010 verwendet. Der neuere RFC vom März 2011RFC6125identifiziert von @JennyD (funktioniert es im Hauptteil der Antwort?) ist eine allgemeinere Behandlung, sagt aber ausdrücklich
Dieses Dokument ersetzt außerdem nicht die Regeln zur Überprüfung der Dienstidentität, die in Spezifikationen für bestehende Anwendungsprotokolle enthalten sind, die vor diesem Dokument veröffentlicht wurden, wie beispielsweise jene, die in Anhang B auszugsweise aufgeführt sind.
und Anhang B enthält RFC2818.
Die Grundanforderungen vonCA-Browser Forumsagen, dass die ZertifizierungsstellenAusgabeZertifikate mit SAN, während Subject.CN veraltet ist, obwohl dies keine direkte Anforderung für Browser/Clients ist.
Wenn Sie sowohl die Domäne als auch die Subdomänen (nur eine Ebene) verwenden möchten, fügen Sie zwei DNSName-Einträge in SAN ein, einen für dcrdev.comund einen für *.dcrdev.com.