Problem
Starting with Google's Manifest V3 update, browser extensions no longer support self-signed certificates. Therefore, you need to ensure certificates meet updated security requirements to maintain the Password Secure browser extension functionality.
Verify if a Self-Signed Certificate is used on IIS
To determine if your IIS (Internet Information Services) is using a self-signed certificate, follow these steps:
-
Open IIS Manager:
- Press
Win + R
, typeinetmgr
, and pressEnter
.
- Press
-
Select the Website:
- Expand the server node to see a list of sites in the connections' pane on the left.
- The name of the site should either be "WebApp" or "WebClient" (legacy).
-
View Site Bindings:
- Right-click the site and select Edit Bindings.
-
Locate the HTTPS Binding:
- In the Site Bindings window, look for the entry with Type set to
https
. This is the binding that specifies the SSL certificate for the site. - Select the https binding and click Edit.
- In the Site Bindings window, look for the entry with Type set to
-
Verify if Itβs Self-Signed:
- In the SSL certificate field, you will see the name of the certificate currently assigned to this binding.
- Click View next to the SSL certificate field. This opens the certificate details.
- In the Certificate Information window, check the Issuer and Subject fields: If the Issuer and Subject are the same, this typically indicates a self-signed certificate.
Solution
Option 1: Using Let's Encrypt for Publicly Available Web Endpoints
For public endpoints, Let's Encrypt offers free, automated, and CA-signed certificates.
To issue a certificate, you need to use one of the available Let's Encrypt clients.
Note: Please refer to the corresponding client documentation, on how to issue and use a Let's Encrypt certificate.
Option 2: Switching to a CA Certificate for internal use, using an existing CA Server
For internal sites, replace the self-signed certificate with a CA-signed certificate to ensure compatibility with the newest Password Secure Browser Extension.
- Generate a Certificate Signing Request (CSR) in IIS.
- Submit the CSR to your Internal CA and retrieve the issued certificate.
- Install and bind the CA certificate in IIS to the WebApp.
Option 3: Using PowerShell to create a valid ca-based certificate
Note: To execute the following commands, you need to use PowerShell in a privileged session (run as Administrator).
Note: You need to modify the highlighted values to match your requirements.
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
To import the root CA certificate on a single client machine, follow these steps to ensure that the client trusts the certificates signed by your newly created root CA:
$rootCertPath = "C:\CA\NpwsRootCA.cer" # Update this path as necessary
Import-Certificate -FilePath $rootCertPath -CertStoreLocation Cert:\LocalMachine\Root
Comments