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).
CodePudding user response:
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.