Skip to main content

Error: Browser Extension No Longer Supports Self-Signed Certificates

Tobias Nessel
Updated

Problem

The Password Secure browser extension stops working correctly against any Password Secure Web App instance that uses a self-signed HTTPS certificate, regardless of which web server hosts it. The error occurs since Chromium-based browsers implemented Google's Manifest V3 update.

Cause

Manifest V3, the extension platform used by current Chromium-based browsers, enforces stricter certificate validation and no longer allows exceptions for self-signed certificates. Any deployment that terminates HTTPS with a self-signed certificate is affected, whether it runs on IIS, nginx, Apache, or another web server.

Resolution

Check whether your web server is using a self-signed certificate

Note: The steps below use IIS as an example, since it is the most common deployment for the Web App. Adapt them to the equivalent certificate-management steps if you use a different web server.

  1. Press Win + R, type inetmgr, and press Enter to open IIS Manager.
  2. In the Connections pane on the left, expand the server node to see the list of sites. The site is usually named WebApp or WebClient (legacy).
  3. Right-click the site and select Edit Bindings.
  4. In the Site Bindings window, select the binding with Type set to https, then click Edit.
  5. In the SSL certificate field, click View to open the certificate details.
  6. In the Certificate Information window, compare the Issuer and Subject fields. If they are identical, the certificate is self-signed.

If the certificate is self-signed, replace it using one of the following options.

Requirements for the new certificate

Regardless of the option you choose, the certificate for the Password Secure Application Server must meet these requirements:

  • DNS names only, no IP addresses: Do not include IP addresses in the certificate. Although technically possible, modern web browsers increasingly reject such certificates. IP addresses can also change, for example through DHCP, load balancers, or network reconfiguration. Certificates are designed to validate hostnames (DNS entries), which are consistent and resolvable identifiers.
  • Common Name (CN): The fully qualified hostname of the server, for example server-passwordsecure.myorg.intern.
  • Subject Alternative Name (SAN): The SAN extension must include at least the entry DNS: server-passwordsecure.myorg.intern. The first SAN entry must be identical to the CN. You can optionally add further entries, for example DNS: server-passwordsecure and DNS: passwordsecure.

Option 1: Switch to an internal CA certificate using an existing CA server

Replace the self-signed certificate on the site with a certificate signed by your internal CA. This is the recommended option for enterprise environments that already run an internal CA.

  1. Generate a Certificate Signing Request (CSR) using your web server's certificate tools (for example in IIS).
  2. Submit the CSR to your internal CA and retrieve the issued certificate.
  3. Install the CA certificate on your web server and bind it to the Web App site.

Option 2: Use Let's Encrypt for publicly available web endpoints

For public endpoints, Let's Encrypt offers free, automated, CA-signed certificates. Use one of the available Let's Encrypt clients and refer to its documentation for how to issue and install the certificate.

Option 3: Use PowerShell to create a CA-based certificate (fallback)

Note: Use this option only if you don't have access to an internal CA (Option 1) or a public endpoint eligible for Let's Encrypt (Option 2), for example in smaller environments without an existing CA. Run the commands in an elevated PowerShell session (Run as Administrator) and adjust the values to match your environment.

Step 1: Create the root CA certificate

# 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"

Step 2: Issue a certificate signed by the root CA

$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)

Step 3: Import the root CA certificate on a client machine

Import the root CA certificate on every client machine that needs to use the Password Secure browser extension, so that the client trusts certificates signed by your new root CA. For a larger-scale deployment, use a GPO or Intune instead of importing the certificate manually on each machine.

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

Related to

Related articles