A development server, a NAS, a router, a home automation controller or a company intranet often uses a certificate that no public authority issued. It might be self-signed, or signed by a private authority you or your company run. The connection is still encrypted, but the browser does not know who issued the certificate, so it shows Your connection is not private and NET::ERR_CERT_AUTHORITY_INVALID every time.
The fix is to install that certificate, or the authority that signed it, into the Windows Trusted Root Certification Authorities store. This article shows three ways to do it, how to check it worked, and how to take it out again.
Checked on Windows 10 Pro 22H2 and Windows 11 with Chrome, Edge and Firefox in November 2026.
| Extension | Contains | Use |
|---|---|---|
| .cer .crt .pem | The public certificate only | Install this on every PC that should trust the server |
| .pfx .p12 | The certificate and its private key | Only on the server itself. Never hand it out |
If the server was given a certificate signed by your own or your company's authority, install the authority's certificate, not the server's. Every certificate that authority signs is then trusted, with no further installs.
If you only have the server, you can save its certificate from the browser: click the warning or padlock icon, open the certificate viewer, go to Details and click Export. Save it as a .crt file.
A certificate in Trusted Root can vouch for any website, including your bank. Install only certificates you made yourself or got directly from someone you trust. If it came by email or download, open it, look at the Thumbprint on the Details tab, and compare it with the source before installing.
Do not leave the wizard on Automatically select the certificate store. For a self-signed certificate it often chooses Intermediate Certification Authorities or Personal, and the browser still warns.
The certificate now appears in the list, where you can open it, check it and delete it later.
Useful in a script, or to install on several PCs quickly. From an administrator Command Prompt:
certutil -addstore -f Root C:\Certs\my-server.cerOr in an administrator PowerShell:
Import-Certificate -FilePath C:\Certs\my-server.cer -CertStoreLocation Cert:\LocalMachine\RootFor the Current User store, without administrator rights, use certutil -user -addstore Root C:\Certs\my-server.cer or Cert:\CurrentUser\Root. Windows then asks you to confirm in a security warning.
If you were given a chain of a root and one or more intermediate certificates, the root goes into Root and each intermediate into CA, the Intermediate Certification Authorities store:
certutil -addstore -f CA C:\Certs\my-intermediate.cerOn a Windows domain, a Group Policy installs the certificate everywhere. In the Group Policy Management Editor go to Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies, right-click Trusted Root Certification Authorities and choose Import. Each PC picks it up at its next policy refresh.
List what is in the store, by part of the name:
Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*My Server*" |
Format-List Subject, Thumbprint, NotAfterThen close every browser window, including ones in the background, and open the site again. The warning should be gone. Click the padlock, open the certificate and look at the Certification Path tab: it should end with your certificate and say This certificate is OK.
| Error | Cause |
|---|---|
| NET::ERR_CERT_AUTHORITY_INVALID | Still not trusted. It went into Personal or Intermediate rather than Trusted Root, or the browser was not fully closed. For a service, it went into Current User instead of Local Machine. |
| NET::ERR_CERT_COMMON_NAME_INVALID | The certificate is trusted, but does not list the address you typed. Installing cannot fix this; the certificate has to be made again. See below. |
| NET::ERR_CERT_DATE_INVALID | Expired, or the PC's clock is wrong. |
| Fine in Chrome, warns in Firefox | Firefox is not reading the Windows store. See the Firefox note above. |
Browsers only match the address against the certificate's Subject Alternative Name (SAN) list, and have ignored the old Common Name field since 2017. In that list a host name is a DNS entry and an IP address must be an IP Address entry. A certificate with 192.168.1.20 written as a DNS entry is never matched, so https://192.168.1.20 fails however it is installed.
Open the certificate, go to Details, Subject Alternative Name. You should see lines such as DNS Name=devbox and IP Address=192.168.1.20. If the address is missing, or shows as a DNS Name, the certificate needs making again.
If the certificate is your own, PowerShell can make one with the right entries. Run it as administrator, listing every name and address you will type into the browser:
New-SelfSignedCertificate `
-Subject "CN=My Server" `
-TextExtension @("2.5.29.17={text}DNS=localhost&DNS=devbox&IPAddress=192.168.1.20") `
-NotAfter (Get-Date).AddYears(2) `
-CertStoreLocation Cert:\LocalMachine\MyAvoid the shorter -DnsName parameter for IP addresses: it adds them as DNS entries, which is the mistake above. The free mkcert tool is another way to make correct local certificates and install them in one step.
When you no longer need it, take it out so it cannot be misused. In certlm.msc open Trusted Root Certification Authorities, Certificates, right-click it and choose Delete. Or by thumbprint from an administrator Command Prompt:
certutil -delstore Root <thumbprint>
Please chip in if helpful
