Zum Hauptinhalt gehen

Fehler: Browser-Erweiterung unterstützt keine selbst signierten Zertifikate mehr

Tobias Nessel
Aktualisiert

Problem

Die Password Secure Browser-Erweiterung funktioniert nicht mehr korrekt, wenn die Password Secure Web App über ein selbst signiertes HTTPS-Zertifikat bereitgestellt wird – unabhängig davon, welcher Webserver sie hostet. Der Fehler tritt auf, seit Chromium-basierte Browser das Manifest-V3-Update von Google umsetzen.

Ursache

Manifest V3, die Erweiterungsplattform aktueller Chromium-basierter Browser, erzwingt eine strengere Zertifikatsprüfung und lässt keine Ausnahmen mehr für selbst signierte Zertifikate zu. Betroffen ist jede Bereitstellung, die HTTPS mit einem selbst signierten Zertifikat terminiert, egal ob IIS, nginx, Apache oder ein anderer Webserver.

Lösung

Prüfen, ob Ihr Webserver ein selbst signiertes Zertifikat verwendet

Hinweis: Die folgenden Schritte verwenden IIS als Beispiel, da dies die gängigste Bereitstellung für die Web App ist. Passen Sie sie bei einem anderen Webserver an die entsprechenden Schritte zur Zertifikatsverwaltung an.

  1. Drücken Sie Win + R, geben Sie inetmgr ein und drücken Sie die Eingabetaste, um den IIS-Manager zu öffnen.
  2. Erweitern Sie im linken Bereich Verbindungen den Server-Knoten, um die Liste der Websites anzuzeigen. Die Site heißt in der Regel WebApp oder WebClient (veraltet).
  3. Klicken Sie mit der rechten Maustaste auf die Site und wählen Sie Bindungen bearbeiten.
  4. Wählen Sie im Fenster Site-Bindungen die Bindung mit Typ https aus und klicken Sie auf Bearbeiten.
  5. Klicken Sie im Feld SSL-Zertifikat auf Anzeigen, um die Zertifikatsdetails zu öffnen.
  6. Vergleichen Sie im Fenster Zertifikatinformationen die Felder Aussteller und Betreff. Sind sie identisch, handelt es sich um ein selbst signiertes Zertifikat.

Ersetzen Sie ein selbst signiertes Zertifikat mit einer der folgenden Optionen.

Anforderungen an das neue Zertifikat

Unabhängig von der gewählten Option muss das Zertifikat für den Password Secure Application Server folgende Anforderungen erfüllen:

  • Nur DNS-Namen, keine IP-Adressen: Tragen Sie keine IP-Adressen in das Zertifikat ein. Technisch wäre das möglich, moderne Webbrowser lehnen solche Zertifikate jedoch zunehmend ab. IP-Adressen können sich außerdem ändern, zum Beispiel durch DHCP, Loadbalancer oder Netzwerkkonfigurationen. Zertifikate sind darauf ausgelegt, Hostnamen (DNS-Einträge) zu validieren, da diese konsistente und auflösbare Identifikatoren sind.
  • Common Name (CN): Der vollständige Hostname des Servers, zum Beispiel server-passwordsecure.myorg.intern.
  • Subject Alternative Name (SAN): Die SAN-Erweiterung muss mindestens den Eintrag DNS: server-passwordsecure.myorg.intern enthalten. Der erste SAN-Eintrag muss identisch mit dem CN sein. Optional können Sie weitere Einträge ergänzen, zum Beispiel DNS: server-passwordsecure und DNS: passwordsecure.

Option 1: Auf ein internes CA-Zertifikat über einen vorhandenen CA-Server umstellen

Ersetzen Sie das selbst signierte Zertifikat der Site durch ein Zertifikat, das von Ihrer internen CA signiert wurde. Dies ist die empfohlene Option für Unternehmensumgebungen, die bereits eine interne CA betreiben.

  1. Erstellen Sie mit den Zertifikatswerkzeugen Ihres Webservers (z. B. in IIS) eine Zertifikatsignierungsanforderung (CSR).
  2. Senden Sie die CSR an Ihre interne CA und rufen Sie das ausgestellte Zertifikat ab.
  3. Installieren Sie das CA-Zertifikat auf Ihrem Webserver und binden Sie es an die Web-App-Site.

Option 2: Let's Encrypt für öffentlich erreichbare Web-Endpunkte verwenden

Für öffentliche Endpunkte bietet Let's Encrypt kostenlose, automatisierte, CA-signierte Zertifikate. Verwenden Sie zum Ausstellen einen der verfügbaren Let's Encrypt-Clients und lesen Sie in dessen Dokumentation nach, wie Sie das Zertifikat ausstellen und installieren.

Option 3: PowerShell verwenden, um ein CA-basiertes Zertifikat zu erstellen (Fallback)

Hinweis: Verwenden Sie diese Option nur, wenn Ihnen weder eine interne CA (Option 1) noch ein für Let's Encrypt geeigneter öffentlicher Endpunkt (Option 2) zur Verfügung steht, etwa in kleineren Umgebungen ohne vorhandene CA. Führen Sie die Befehle in einer erhöhten PowerShell-Sitzung aus (als Administrator ausführen) und passen Sie die Werte an Ihre Umgebung an.

Schritt 1: Root-CA-Zertifikat erstellen

# Root CA certificate
$rootCert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My `
-Subject "CN=NpwsRootCA, O=MyOrganization, C=US" `
-KeyExportPolicy Exportable `
-KeyUsage CertSign, CRLSign, DigitalSignature `
-KeyLength 4096 `
-HashAlgorithm SHA256 `
-NotAfter (Get-Date).AddYears(10) `
-KeyUsageProperty All

# Export the root CA certificate to a file (for later distribution to your clients)
New-Item -ItemType Directory -Force -Path C:\CA
Export-Certificate -Cert $rootCert -FilePath "C:\CA\NpwsRootCA.cer"

Schritt 2: Ein von der Root-CA signiertes Zertifikat ausstellen

$hostname = "passwordsecure.internal.mydomain.com" # Replace with your actual hostname

# CA signed certificate
$issuedCert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My `
-Subject "CN=$hostname" `
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1") `
-DnsName $hostname `
-Signer $rootCert `
-KeyExportPolicy Exportable `
-KeyUsage DigitalSignature, KeyEncipherment `
-KeyLength 3072 `
-HashAlgorithm SHA256 `
-NotAfter (Get-Date).AddYears(2)

Schritt 3: Root-CA-Zertifikat auf einem Client-Rechner importieren

Importieren Sie das Root-CA-Zertifikat auf jedem Client-Rechner, der die Password Secure Browser-Erweiterung verwenden soll, damit der Client den von Ihrer neuen Root-CA signierten Zertifikaten vertraut. Für eine Bereitstellung in größerem Umfang eignen sich ein GPO oder Intune besser als der manuelle Import auf jedem Rechner.

$rootCertPath = "C:\CA\NpwsRootCA.cer" # Update this path as necessary
Import-Certificate -FilePath $rootCertPath -CertStoreLocation Cert:\LocalMachine\Root

Verknüpfung mit

Verwandte Beiträge