☰

Probleme beim Herstellen einer sicheren Verbindung des Chrome-Browsers auf einem Mac über SSL/TLS zu Apache 2.4 auf Centos

tag-icon • tag-icon google-chrome security apache-http-server ssl certificate
Probleme beim Herstellen einer sicheren Verbindung des Chrome-Browsers auf einem Mac über SSL/TLS zu Apache 2.4 auf Centos

Wir betreiben mehrere Websites, auf denen die Leaf-Webanwendung läuft. Unsere Konfiguration läuft auf Centos 7.9 mit einer .NET-Web-API und Apache 2.4.

Das System wird nur von Mitarbeitern verwendet, die auf unser Intranet zugreifen. Es verwendet ein selbstsigniertes institutionelles Stammzertifikat, ein Zwischenzertifikat und ein vom Zwischenzertifikat signiertes (ausgestelltes) Serverzertifikat. opensslzeigt die Kette:

$ openssl s_client -connect leaf.ourdomain:443 -showcerts -CAfile path_to_root_cert/RootCert.cer 2> /dev/null | egrep "Certificate chain| s:| i:"
Certificate chain
 0 s:/CN=leaf.ourdomain
   i:/DC=org/DC=our_dc/CN=Our system CA
 1 s:/DC=org/DC=our_dc/CN=Our system CA
   i:/CN=Our System

Ich habe den Namen unserer Einrichtung verschleiert, aber alles andere gleich gelassen.

Chrome läuft auf einem Mac und ist so konfiguriert, dass das Stammzertifikat in der Schlüsselbundverwaltungs-App des Macs verwendet wird. Dadurch werden sichere, private Verbindungen für eine Produktionsbereitstellung von Leaf hergestellt.

Ich konfiguriere einen VM-Klon des Produktionssystems. Wir haben einen neuen privaten Schlüssel erstellt und ein Serverzertifikat, das vom Zwischenzertifikat signiert wurde, httpd.confwurde für den neuen Domänennamen geändert. Das Serverzertifikat, der private Schlüssel und das Zwischenzertifikat wurden auf dem Server gespeichert und diese httpd-Attribute verweisen jetzt darauf:

  SSLCertificateFile "/etc/pki/tls/certs/omop-leaf-temp_hpc_our_domain_ssl.cer"
  SSLCertificateKeyFile "/etc/pki/tls/private/omop-leaf-temp_hpc_our_domain_ssl.key"
  SSLCertificateChainFile "/etc/pki/tls/certs/Intermediate.cer"

Der Domänenname des Servers scheint zu funktionieren. Verschleiert ist er omop-leaf-temp.hpc.our_domain. Dieser Name wird für 1) die URL der https-Anforderung, 2) die von Chrome gemeldete Fehlermeldung und 3) die CNin der verwendet SSLCertificateFile. Dies wird bestätigt durch

$ openssl x509 -text -in ./omop-leaf-temp_xxxx.cer| grep CN= | grep omop
        Subject: C=US, ST=xxx, L=xxx, O=Our System, OU=xxx, CN=-hpc.our_domain/emailAddress=leaf-support@xxx

Aber die Chrome-Instanz, die sichere Verbindungen zum Produktionssystem herstellt, schafft dies im VM-Klon nicht: Chrome kann keine sichere Verbindung zum Server im VM-Klon herstellen

Die „PEM-codierte Kette“ identifiziert 3 Zertifikate. In der Reihenfolge sind dies SSLCertificateFile, SSLCertificateChainFile, und unser selbstsigniertes Stammzertifikat, das Chrome über den Schlüsselbundzugriff erhält (nehme ich an). Das scheint mir in Ordnung zu sein.

httpdmeldet keine Fehler in den Protokollen (einschließlich error_log, leaf_access_log, und leaf_ssl_error_log), wenn Chrome versucht, eine Verbindung herzustellen. LogLevelist warn.

Ich bin ratlos. Warum meldet Chrome Your connection is not private, NET::ERR_CERT_COMMON_NAME_INVALIDwann der CN richtig und die Zertifikatskette gut ist? Was kann ich tun, um dieses Problem weiter zu untersuchen und zu beheben?

Danke

Antwort1

Der allgemeine Name sieht falsch aus:

./omop-leaf-temp_xxxx.cer| grep CN= | grep omop Betreff: C=US, ST=xxx, L=xxx, O=Unser System, OU=xxx, CN= "

aber „-hpc.our_domain/emailAddress=leaf-support@x“ ist etwas anderes als „omop-leaf-temp.hpc.our_domain“

Antwort2

Das Zertifikat des Servers muss eine SubjectAlternativeName (SAN)-Erweiterung haben, die den Namen des Servers enthält, wie von @dave_thompson_085 angemerkt.

Dadurch können sowohl Chrome (Version 102.0.5005.115) als auch Safari (Version 15.0) sichere Verbindungen mit dem Server herstellen.

Das Zertifikat wurde erstellt mit

openssl req \
-newkey rsa:4096 \
-nodes \
-keyout omop-leaf-temp_redacted.key \
-out omop-leaf-temp_redacted.csr \
-config csr_with_san.conf \
-days 730 \
-batch \
-verbose

mit dieser Konfigurationsdatei

[ req ]
default_bits              = 2048
default_md              = sha256
distinguished_name    = req_distinguished_name
req_extensions     = req_ext
prompt = no

[ req_distinguished_name ]
countryName                 = US
stateOrProvinceName       = New York
localityName                  = New York City
organizationName          = redacted
organizationalUnitName  = redacted
commonName                  = omop-leaf-temp.redacted
emailAddress                  = redacted

[ req_ext ]
subjectAltName          = @alt_names

[alt_names]
DNS.1                   = omop-leaf-temp.redacted

Ich fordere die Entwickler des Codes, der auswertet, ob ein Client eine sichere Verbindung hergestellt hat, dringend auf, einen eindeutigen Fehler auszugeben, der darauf hinweist, dass das Zertifikat einen SAN enthalten muss, und nicht den falschen Fehler ERR_CERT_COMMON_NAME_INVALID.

verwandte Informationen