I recently upgraded my machine to Windows 11. Prior to the upgrade, I could connection via IIS and IIS Express to localhost using SSL.
After the upgrade, I can connect to localhost over standard HTTP, but not HTTPS.
I have tried the following:
flushed the DNS
netsh int ip reset
netsh winsock reset
deleting the binding(s) and adding them back in
checked the protocols used in inetcpl.cpl (TLS 1.2 and TLS 1.3 are enabled)
turned off the Firewall
turned off MalwareBytes
Nothing has worked so far. I keep getting:
The page cannot be reached. The connection was reset.
I opened up Chrome and the status is (failed)net::ERR_CONNECTION_RESET
I am at a total loss and cannot figure out what is going on. Any help is appreciated.
I figured out the issue.
Apparently, the certificates I'm using to support SSL for my site and in IIS Express do not conform to TLS 1.3.
I had suspicion it was TLS 1.3 but couldn't figure out how to turn it off for IIS Express and IIS.
If you go into IIS and edit the bindings you have for your site, there is an option "Disable TLS 1.3 over TCP"
Once I set this setting and accessed the website on IIS, I found it connected and I got prompted for my PKI client certificate.
With IIS Express, I had to take a different tac.
I first deleted out the binding for one of the test sites in IIS Express:
netsh http delete sslcert ipport=0.0.0.0:44325
I then added it back in using:
netsh http add sslcert ipport=0.0.0.0:44325 certhash= appid={214124cd-d05b-4309-9af9-9caa44b2b74a} verifyclientcertrevocation=disable certstorename=My disabletls13=enable
The key is the disabletls13 setting.
A list of these settings is available at Windows Server 2019 disable legacy TLS in IIS via certificate binding is unavailable
I am posting them here again to guard against link rot:
Usage: add sslcert hostnameport=<name:port> | ipport=<ipaddr:port> | ccs=<port>
appid=<GUID>
[certhash=<string>]
[certstorename=<string>]
[verifyclientcertrevocation=enable|disable]
[verifyrevocationwithcachedclientcertonly=enable|disable]
[usagecheck=enable|disable]
[revocationfreshnesstime=<u-int>]
[urlretrievaltimeout=<u-int>]
[sslctlidentifier=<string>]
[sslctlstorename=<string>]
[dsmapperusage=enable|disable]
[clientcertnegotiation=enable|disable]
[reject=enable|disable]
[disablehttp2=enable|disable]
[disablequic=enable|disable]
[disablelegacytls=enable|disable]
[disabletls12=enable|disable]
[disabletls13=enable|disable]
[disableocspstapling=enable|disable]
EDIT - 02/03/2023:
I confirmed the issue is TLS 1.3.
I could reproduce the issue by turning on/off the setting in IIS. In IIS Expression, apps for which I did not disable TLS 1.3 were not accessible and the single app for which I did disable TLS 1.3 was accessible.
Because I have a number of applications I test in Visual Studio and until I can find a solution for this issue, the most efficient way forward for me was to enable TLS 1.2 explicitly and disable TLS 1.3.
Here is a PowerShell script to disable TLS 1.3:
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Name 'Enabled' -Value 1 -PropertyType DWORD
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Name 'DisabledByDefault' -Value 0 -PropertyType DWORD
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -Name 'Enabled' -Value 1 -PropertyType DWORD
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -Name 'DisabledByDefault' -Value 0 -PropertyType DWORD
Write-Host "Enabling TLSv1.3"
I am still hoping that someone might know what the cause of this issue is and how to resolve it. I hate this solution because it's not in line with best security practices of "always forward, never backward," but I don't know what else to do.
You are running IIS on your Windows 11 machine?
Have you tried restarting the IIS Service?
How about your firewall, is that turned on? For a test, try disabling it and see if you are able to reach 443, it may be blocking https traffic for some reason.
You aren't using an SSL cert for the traffic? Is it installed and valid still?
Can you setup a temporary test to see if that works (blank page) ?
Related
I'm running Red Hat Linux Enterprise Linux 7.9 which hosts a tentacle application.
After a vulnerability scanner on this server, it shows a TLS vulnerability over the port 10993, which is the port used for octopus tentacle and the vulnerability rapport shows that the server is successfully connected over TLSv1.1
I had verified on the server into /etc/octopus/Tentacle/ tentacle-Tentacle.config file but nowhere its mentioned the SSL/TLS settings on the Linux machine. I need someone to help where exactly it’s pointing this TLS1.0, TLS1.1 and where the TLS config file is located to disable the use of the weak version.
Thank you,
I have created a trusted certificate as follows (cleaning up potential pre-junk). During that, I got the popups telling my that a gang of crazy donkeys can do evil things if this is a root cert. The last comamnd confirms that I have a working certificate. I even ran the commands twice to verify that cleaning would produce a warning too, which it did, just as expected.
dotnet dev-certs https --clean
dotnet dev-certs https --trust
dotnet dev-certs https --verbose
I haven't imported any PFX-files as my understanding is that working in development towards a localhost instance doesn't require that. That seems to be confirmed by the information in the console letting my know that the certificate is generated properly. Running dotnet dev-certs http --check produces no warnings (no confirmation neither, it's no content in the result).
The HTTPS developer certificate was generated successfully.
A valid HTTPS certificate is already present.
Then I executed a call to my token dispencer endpoint getting a reply as expected too. It comes back from a secure HTTPS on localhost:5001/connect/token and containes all the vital parts.
{
"access_token": "eyJhbGciO...Ow7EEkA",
"expires_in": 3600,
"token_type": "Bearer",
"scope": "myapi.read"
}
What bothers me is the warning with red icon and the text Unable to verify the first certificate.
I've made sure to disable SSL checking and turned off CA Certificated (althoug I haven't added any Client Certificates in that menu. Googling gives me a bunch of hits on problems related to Ubuntu and/or MacOs but I'm based on a good old Win10 so those turned out irrelevant.
Have I misunderstood the approach all together or, possibly, confused some of the concepts? If not, what can I do to trouble-shoot it further?
I dig in to this a little.
dotnet dev-certs https --trust command just creates/makes sure a new localhost certificate (with friend name ASP.NET Core HTTPS development certificate) and puts it into the trust root store.
IIS Express server however won't use it automatically. It still uses the certificate (friend name is localhost) that is created when you run the APS.NET Core web app for the first time. If this certificate is removed from trust root store you will get the cert error.
You have a few options to address this issue.
Reset the IIS Express cert.
Switch the cert IISExpress use to the one you just created, you can retrieve it using the PowerShell command below and following this link.
Get-ChildItem -path cert:\currentUser\My | Select-Object FriendlyName, subject, Thumbprint
I have SSRS link, And we are planning to set SSL for it.
So I have went with the following steps on the server:
Generate a Self-Signing Certificate with Powershell
by running the following commands
New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\my -dnsname <MyHostNameServer>
$pwd=ConvertTo-SecureString "password1" -asplainText -force
$file="C:\temp\<MYHOSTNAMEServer>.pfx"
Export-PFXCertificate -cert cert:\LocalMachine\My\<Thumbprint produced during first command> -f
Import-PfxCertificate -FilePath $file cert:\LocalMachine\root -Password $pwd
Open Reporting Services Configuration Manager
Click Connect at the “Reporting Services Configuration Connection” Screen
Reporting services Configuration Manager pic
Click on Web Site URL in the left-hand pane window
In the “HTTPS Certificate” drop-down box select the certificate you installed. You will see the Port text box pre-fill and the Report Server Web Services URL pre-fill.
Click Apply
Web URL
And I have tested the URL , with https and worked
link is working pic
The issue now ! the HTTPS link works perfectly in the server, but with any other users ( from my laptop ) I got "invalid Certificate" ! and it seems not a trusted certificate
Could you please assist me to solve this issue.
Modern browsers like Chrome and Firefox will only accept CA-signed server certificates as trusted certificates for HTTPS. There are also other requirements such as SubjectAlternativeName extensions and the algorithm used for the certificate (SHA-1 is not recommended and the browser may present a warning).
Google provides documentation for a correct setup of your TLS server certificate, mentioning the requirement of it being CA-signed and so on.
Most likely if the TLS configuration is correct and working on Chrome it will work on other browsers. Internet Explorer is the outlier insecure browser that does not warn users of a potential MITM attack when the server presents a self-signed certificate.
I need to make sure that my web application works with HTTPS for secure account information. So I followed Hanselman's blog post to set it up:
Working with SSL at Development Time is easier with IISExpress
Everything was working like mentioned. However a couple of weeks ago it stopped working with the following error:
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.
I did not change anything on the local box or my code except for Windows updates. Can anyone tell me whats wrong? I can explain more if more clarification is required.
My application is an MVC4 application with a SQL Server DB.
I fixed this issue by following the steps described in a post from scott hanselman.
The following steps fixed the issue for me:
makecert -r -pe -n "CN=<SOMENAME>" -b 01/01/2000 -e 01/01/2036 -eku
1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
netsh http delete sslcert ipport=0.0.0.0:44300
Look up the thumbprint of the certificate by using MMC.exe
netsh http add sslcert ipport=0.0.0.0:44300 appid={<SOMEGUID>} certhash=<THUMBPRINT>
I have my site mydomain.local on my local development machine, which uses a local hosts file entry to point to 127.0.0.1. The directory is my working git copy and it works like a charm. It always points to whatever I have checked out.
I want to setup SSL but of course need to test locally and with my code before I go implementing it elsewhere. This is my Win7 Ultimate machine and this dev environment uses full-blown IIS 7.5 and not any built-in IIS express or localhost:port# auto-config.
Through multiple experiments, I've resorted to SelfSSL7 for greater control and setup of a self-signed SSL certificate. It has a great set of options and seems to work well.
Accordingly to the limited docs, I generate my SelfSSL cert with this command:
SelfSSL7 /Q /T /I "mydomain.local" /S "MyDomain IIS Name" /N cn=pc_name;cn=localhost;cn=mydomain.local
It does properly bind to my IIS setup with the right domain. BUT when I try to start the Site,I get this error:
The process cannot access the file because it is being used by another process. (Exception 0x80070020)
I look up these errors and am instructed to check which services are listening on port 443 for SSL. This is a snippet of the output from my netstat -ano output (where port==443) (I've trimmed all else)
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 5800
TCP [::]:443 [::]:0 LISTENING 5800
Problem is that the documentation sucks (surprise) and I'm not sure where to go from here. The registry path they've specified does not actually exit on my machine (no ListenOnlyList folder in Regedit). Also, I have 0 other IIS sites setup and definitely none setup on SSL over 443.
SUMMARY: the SSL cert can be generated, looks right, but I cannot Start the site in IIS once it's binding is in place. Again, SSL looks right - maybe it's more about my machine config with regard to port 443 and "socket pooling" (???)
I had the same problem, in my case I just stoped the iss server, closed skype, and restarted the server and skype, it worked, it seems that skype was using port 443.
Looks like you already have a program listening on port 443. Use Task Manager or Process Explorer to check what program is running with Process ID 5800 and then kill that.