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).
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.
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.
open dev tools in chrome, go to Security tab and click on the View certificate.
go to Details tab and click Copy to File...
then Certificate Export Wizard windows will pop up and click the Next button to continue.
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.
open chrome://settings/ by copy this in the browser url box.
choose Privacy and security in the side menu > Security > Advanced > Managed Certificates
Certificates window will pop up as below. Choose Trusted Root Certificate Authorities tab and click Import...
import the localhost certificate which saved to chosen path just now at steps 4.
click browse to import the locahost.cer and click Yes to finish the import certificate process.
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.
Related
We suddenly started seeing this "Could not create SSL/TLS secure channel" error.
Our website does a simple POST to another server to a HTTPS URL
This suddenly stopped working
Nothing has changed (Windows Updates, our updates, server settings) to cause suspicion. That we know of, or can remember.
We can navigate to the posted URL just fine.
We have other websites that also do this same POST to that same server and they continue to work. Everything is using TLS 1.0 and the target server has not changed anything recently. Nobody has turned off TLS 1.0 on either side.
This issue is discussed in many other stackoverflow postings, so to research systematically we made a clone of the website on the same server. Just copied its code (compiled code folders) and set up another virtual host in the same IIS.
The POST operation from the clone works! Same server, same code, same IIS. So we can't even reproduce it on the exact same setup. The copy is working but the original is throwing this error.
So finally the question:
Does the fact that the copied website can POST successfully give anybody any insight into what may have happened?
Could some IIS settings on the original site been changed? The only thing different is they are two virtual hosts on the same server.
Windows Server 2012R2, IIS 8.5, ASP.NET/C#.
I found the solution here:
https://social.technet.microsoft.com/Forums/en-US/9dfb4d09-8096-40c9-ac75-1e23f75417c9/frequent-event-id-36888-windows-schannel-errors-in-the-event-viewer?forum=W8ITProPreRel
The causes can be many, apparently, even Windows updates. Still seems odd that it would happen (consistently) on one website and not on its clone (also consistently).
The specific steps to fix were:
In Group Policy Editor (run: gpedit.msc), went to Computer Configuration > Administrative Templates > System > Distributed COM > Application Compatibility and enabled "allow local activation security check exemptions"
Last week I was able to build and run a locally-hosted .NET website without any problems. However, for the past couple of days I haven't been able to get around this error:
ERR_CERT_COMMON_NAME_INVALID
This error message appears in both Chrome and Firefox. Edge and IE will load the page but block all AJAX requests without explanation.
The website is configured as an application in IIS and uses a self-signed certificate (created in IIS).
I encounter the same problem with running a completely separate .NET website so I doubt it has anything to do with each website's individual configurations.
My colleagues are able to browse their locally-hosted versions of the same website using a self-signed certificate in the same browser versions as I have installed.
Please, can someone tell me what might have happened to my setup, why are browsers no longer accepting my certificate, and how to get back to a running localhost website?
I'm a PHP developer and to be able to work on my development environment with a certificate, I was able to do the same by finding the real SSL HTTPS/HTTP Certificate and deleting it.
The steps are :
In the address bar, type "chrome://net-internals/#hsts".
Type the domain name in the text field below "Delete domain".
Click the "Delete" button.
Type the domain name in the text field below "Query domain".
Click the "Query" button.
Your response should be "Not found".
You can find more information at : http://classically.me/blogs/how-clear-hsts-settings-major-browsers
Although this solution is not the best, Chrome currently does not have any good solution for the moment. I have escalated this situation with their support team to help improve user/developer experience.
You should redo these steps every time you go on the server that contains the main HTTPS Certificate with HSTS clause.
When trying to deploy a .net core web app I get this error below. My hosting company told me they downloaded VS 2017 and successfully deployed using the same publishing profile. The only difference I could determine was that they saw a certificate warning and were able to accepted the untrusted certificate. The domain does has an SSL cert setup via LetsEncrypt. I did try to deploy before setting it up. Maybe it being missing is cached in the app?
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
ERROR_CERTIFICATE_VALIDATION_FAILED
Even though your website may have the LetsEncrypt certificate installed, you also need to have a valid certificate installed on the IIS Management Service for Web Deploy to work.
You can set your publish profile to AllowUntrustedCertificate to true to ignore the issue:
SO: allow untrusted certificates
If you do want to use your LetsEncrypt cert, this is how I got it to work (instructions may vary based on your IIS version):
Open MMC (Windows button + X -> Run -> type MMC and press enter
From the MMC menu bar select File -> Add or Remove Snap-ins
Select Certificates then click on Add >
Select Computer Account, Click Next
Select Local Computer, Click Finish and then OK
Expand the Certificate tree to Web Hosting -> Certificates
You will now see your list of LetsEncrypt certificates installed on your server, right click on the one you want to use for web deploy and select Copy
In the Certificate tree of MMC now expand Personal -> Certificates and right click and select Paste
Open IIS Management, click on the server node and open Management Service under management:
Click on Stop in the actions pane on the right to enable changes to be made to the service
Using the drop down under SSL Certificate you should now see your LetsEncrypt certificate you pasted in step 8, select it.
Click on Apply in the actions pane on the right and then click on Start
To test the certificate is now working open your web browser and navigate to https:yourdomainname:8172/msdeploy.axd
Instead of an SSL error you should now be asked to provide credentials to log on. Cancel the logon and go ahead and try publishing using Web Deploy.
I am using msdeploy to push out website code to 4 different servers (test and production servers). Works fine on the first 3, but the 4th is giving me an ERROR_CERTIFICATE_VALIDATION_FAILED error. I am using the -allowUntrusted option.
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:iisApp="E:\workspace\testDeploy\outproject\_PublishedWebsites\<webfolder>" -dest:iisApp="mycompany.com",ComputerName="https://<hostip>:8172/MsDeploy.axd",UserName="<userid>",Password="****",AuthType="Basic" -allowUntrusted -enableRule:AppOffline -skip:objectName=filePath,absolutePath="^.*<webfolder>\\web.*\.config$|^.*mycompany\.com\\web.*\.config"
Error Code: ERROR_CERTIFICATE_VALIDATION_FAILED
More Infenter code hereormation: Connected to the remote computer ("<hostip>") using the specified process ("Web Management Service"), but could not verify the server's certificate. If you trust the server, connect again and allow untrusted certificates. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_CERTIFICATE_VALIDATION_FAILED.
Error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Error: The remote certificate is invalid according to the validation procedure.
Any idea what I am missing?
Adding <AllowUntrustedCertificate>True</AllowUntrustedCertificate> to my pubxml file seemed to fix the problem initially.
Upon re-publishing days later though, I got the same error. I went into the Publish Settings, re-entered my password and the publish succeeded.
I'm now thinking my initial problem was solved by re-entering my password, not by adding <AllowUntrustedCertificate>True</AllowUntrustedCertificate>.
-allowUntrusted did not worked for me.
I used this:
/p:AllowUntrustedCertificate=True
Adding this solution as none of the others worked for me...
I had to add these lines to publish profile:
<UseMSDeployExe>True</UseMSDeployExe>
<AllowUntrustedCertificate>True</AllowUntrustedCertificate>
After adding those, publish still failed. Then I opened the publish profile settings, clicked validate connection, and saved. Only then did publish succeed.
I fixed this by going into the publish settings, then clicking "Validate Connection" at the bottom. Then this error goes away.
The problem was with the password for the user on the destination system.
I saw on another post that someone moved the -allowUntrusted flag before the -dest entry. I tried that and I started getting a ERROR_USER_UNAUTHORIZED message. Everything was correct with the password as it was entered, but it started with an * character and also had a single quote in it. I generated a new password for the user that didn't use those special characters and changed it on the remote system. After that, everything worked fine.
I was able to run the command as shown in the initial post without any error.
If you are getting a ERROR_CERTIFICATE_VALIDATION_FAILED or ERROR_USER_UNAUTHORIZED and everything is set up properly, try changing the password assigned to the user on the destination system. It would seem that some passwords just won't work.
Another Potential Solution - Deploying Web Jobs specifically
I know this is an old post, but I ran into this issue with VS 2019 when deploying my Azure Web Jobs. None of the above worked for me. What did end up working was re-authenticating using the tooling after updating the publishing profile. The way I resolved it was by right clicking the solution and selecting "Publish as Azure Webjob.." Even after creating a new publishing profile it still failed. I then added the following my publishing profile.
<_DestinationType>AzureWebSite</_DestinationType>
<UseMSDeployExe>True</UseMSDeployExe>
<AllowUntrustedCertificate>True</AllowUntrustedCertificate>
I tried publishing it again and it failed. Then I re-authenticated by clicking the edit password link shown below.
When you do, you'll see the following screen. Click on the "Attempt to retrieve credentials from Azure" link.
Don't forget to hit the save button at the bottom after retrieving the creds from Azure. Once you do, go back and try publishing again. It should work just fine.
NOTE: If you just pulled down/created your publishing profile for the first time, do not click the edit button under the name of the Publishing profile and validate the connection that way as shown below.
If you do, it may remove the username/password from the UI for the publishing tooling shown in my first image above. If it disappears, you need to start this process all over again by deleting your profile, creating a new one and finally following the steps above in order. I don't know why it does this, but just something I noticed.
I notice you used the IP address for the deployment server:
-dest:iisApp="mycompany.com",ComputerName="https://<hostip>:8172/MsDeploy.axd"
This caused the certificate validation error for me because the SSL certificate was issued for the domain name, not the IP address. Changing to domain name instead of IP address fixed it.
Just want to add my 50 cents and my solution so it may help someone else.
what i did yo solve this is to use remote desktop to connect to the host machine
and when asked to accept the machine certificate ( after input login and password ) i marked remember this at the bottom.
hope this help someone
In short, I can create a new MAMP Pro 3 host with success and then download and install Wordpress 4.0 via MAMP Pro's "Extra's" feature also seemingly with success (no errors, ) ...yet it doesn't turn out that way as the browser says, "Error code: ERR_CONNECTION_REFUSED".
Full Details: Hi, I've just installed MAMP Pro for the first time on Mac OS 10.9.5 with all the default settings, the WebStart page loaded in the browser, php looks to be running fine. The problem I'm having occurs when running a preliminary test of MAMP by trying the Extras feature and installing Wordpress 4.0. I get no indication that anything went wrong with the default install yet clicking the button next to the Server Name "Open the hosts web page in a browser"... I am greeted with an error in Google Chrome, Firefox, Safari, etc....
"This webpage is not available. Google Chrome's connection attempt to was rejected. Error code: ERR_CONNECTION_REFUSED
Google Chrome's connection attempt to testwpextra.dev was rejected. The website may be down, or your network may not be properly configured.
Check your Internet connection
Allow Chrome to access the network in your firewall or antivirus settings.
Check your proxy settings
"
I'm not using a proxy, I am running apache as my local user and have confirmed the document root is owned by the same user (with read/write permissions), I turned off firewall/littlesnitch just to be sure, same result in various browsers.
I read some fella saying something about setting up his host with IPv6 but I'm using the MAMP control panel to manage the process for me and don't see settings of that nature. Maybe this is done via the Extended tab with directory or VirtualHost parameters, I don't know... wish I did. Please help! Thanks!
I solved my problem by changing MAMPs ports from the default 8888 etc... to 80,443,3306 (on MAMPs General tab). Now all my includes are broken because MAMP doesn't allow "php_value" in htaccess files...one step at a time i guess. =]