Why is my localhost self-signed SSL certificate suddenly invalid in Chrome?

Question

I just started working on a .NET project again that I hadn't touched in about a month, and suddenly in my localhost environment I'm getting ERR_CERT_AUTHORITY_INVALID errors when I try starting my application. I used dotnet dev-certs commands to regenerate the localhost certificate, but what's weird is it looks like Chrome is sourcing this localhost certificate from elsewhere. In the Developer Tools pane, I see this (notice the Validity Period):

I don't know why it shows that invalid Validity Period because I just generated a new localhost cert tonight, and I've blown away Chrome's SSL cache numerous times tonight. The following certificate appears in both the Personal > Certificates and Trusted Root Certification Authorities sections of certmgr.

Could someone please help me understand why Chrome thinks my localhost cert is from an invalid authority and how I can correct this issue? The last valid version came from the exact same place (although I think something else might have generated it because I don't recall using dotnet dev-certs CLI commands to create the original cert).

Answer 1

I just spent about six hours over the past 2 days with this same issue affecting only one application hosted on localhost. None of the suggestions here or from ChatGPT worked for me. I was trying to debug an application that was using an ASP.NET Core backend with a React front-end. I was using VITE to build and debug the application.

In my vite.config file on the react app, I had the following lines:

const baseFolder =
    env.APPDATA !== undefined && env.APPDATA !== ''
    ? `${env.APPDATA}/ASP.NET/https`
    : `${env.HOME}/.aspnet/https`;

const certificateName = "myappname";
const certFilePath = path.join(baseFolder, `${certificateName}.pem`);
const keyFilePath = path.join(baseFolder, `${certificateName}.key`);

This led me to look in my "%AppData%\ASP.NET\https" folder, and sure enough, there was a certificate and key in there called "myappname.key" and "myappname.pem." I removed these files, then cleaned and rebuilt the application and ran the debugger. Visual Studio regenerated the files and now they are trusted by the browser.

I can't believe I just wasted so much time on this, but at least it's working now!

Answer 2

I had a similar issue using IIS to serve my ASP.NET Core site. The binding in IIS didn't match the cert generated by .NET. I cobbled together this PowerShell script to synchronize them:

 # Remove the .NET core localhost development certificate, re-create it, and trust it:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

# Export the cert from dotnet:
$sPassword = "!Password^"
$ssPassword = ConvertTo-SecureString -String $sPassword -Force -AsPlainText
dotnet dev-certs https -ep localhost.pfx --trust --format PFX -p $sPassword

# Import the cert into the local machine store:
$oX509Cert = Import-PfxCertificate -CertStoreLocation "Cert:\LocalMachine\My" -FilePath "localhost.pfx" -Exportable -Password $ssPassword

# Also import the certificate as a trusted root (since it is self-signed):
Import-PfxCertificate -CertStoreLocation "Cert:\LocalMachine\Root" -FilePath "localhost.pfx" -Exportable -Password $ssPassword

# IIS reset just in case
iisreset

# Load in the admin scripts for doing stuff with IIS:
Import-Module Webadministration

# Fetch the Default Web Site in IIS and get the first HTTPS (port 443) binding:
$oIISWebSite = Get-ChildItem -Path "IIS:\Sites" | where {( $_.Name -eq "Default Web Site" )}
$oIISBinding  = $oIISWebSite.Bindings.Collection | where {( $_.protocol -eq 'https' -and $_.bindingInformation -eq '*:443:')}

# Add the cert to the HTTPS binding in IIS:
# Note: the poorly-documented AddSsslCertificate() method replaces the existing cert binding. (Thank you https://lachlanbarclay.net/2022/01/updating-iis-certificates-with-powershell).
$oIISBinding.AddSslCertificate($oX509Cert.Thumbprint, "my")

# IIS reset just in case
iisreset

Answer 3

I just had this one today, and it didn't go away when I cleaned out my dev certificates and trusted a new one, per David Aleu's answer.

Then I tried my localhost site in Edge and there was no problem.

Turned out Chrome needed an update. When I clicked the button to get the latest Chrome things started working normally again.

Answer 4

This is what I did and it worked for me. At Powershell for VS 2022 command prompt run:

>dotnet dev-certs https --clean
>dotnet dev-certs https --trust

Then click Yes to the prompt.

Answer 5

For me the certificate issue was happening ONLY for one project. After different permutation and combination, I found the issue was due to one value in project secret. The following value was found additionally inserted in the project secret.json

{
  "Kestrel:Certificates:Development:Password": "d24802d4-8528-4599-8086-9895359360f8"
}

Remove the above entry from project secret

Issue is not in the password value rather the entry itself is the culprit. Hope this save someone's day.

Answer 6

After I have spent lot of times of searching the solutions, finally I am able to solve it by following the steps below. Hopefully, this will save your days.

1. open dev tools in chrome, go to Security tab and click on the View certificate.
2. go to Details tab and click Copy to File...
3. then Certificate Export Wizard windows will pop up and click the Next button to continue.
4. remain DER encoding options, click Next and choose Browse, save it and name the certificate as localhost.cer. You should see your saved certificate on your saved path chosen just now.
5. open chrome://settings/ by copy this in the browser url box.
6. choose Privacy and security in the side menu > Security > Advanced > Managed Certificates
7. Certificates window will pop up as below. Choose Trusted Root Certificate Authorities tab and click Import...
8. import the localhost certificate which saved to chosen path just now at steps 4.
9. click browse to import the locahost.cer and click Yes to finish the import certificate process.
10. Close everything and restart your chrome browser. Remember to rebuild and rerun your project if you running the project using dotnet run command prompt for the changes to take effect in the browser. Now you should be able to access any localhost website urls with secure tag.

Answer 7

Well this is incredibly stupid. After wasting hours last night and an hour or two tonight of trying fixes I found in blogs and whatnot, an answer on a similar StackOverflow question stated I should attempt repairing my Visual Studio install. Sure enough, doing that resolved the issue.

After I repaired my Visual Studio install and loading up my project I was having HTTPS issues with, I got a dialog box from VS2022 like the one below (snipped from bing.com/images since I dismissed my dialog while trying to fix this) and I selected "Yes".

This added a new certificate but strangely it only added it to the Trusted Root Certification Authorities in certmgr and not to Personal, whereas the one I generated from dotnet dev-certs CLI commands created two; one in Trusted Root Certification Authorities and the other in Personal. The below screenshot shows both certificates; "IIS Express Development Certificate" is the one that resolved the issue and the one that was created by repairing VS2022.

I don't know why VS2022 didn't prompt me to renew the certificate after it was expired. On the bright side, assuming this never gets addressed in a future iteration of Visual Studio, after going through this experience I'm sure that by 10/3/2027 that I'll remember everything that transpired here today and that I must repair my installation of VS20XX if I want to avoid wasting hours of my time due to a localhost SSL certificate expiration.