OK I have a SSL issue that I can't seem to get past on this 1 Win7 x64 machine. I have been using self-signed certs for years and even blogged about them before so I have experience. However something is happening that I can't figure out this time.
I have (2) localhost SSL certs created and insalled on my machine.
localhost (friendly name) issued and created in IIS (7.5). It contains the 'Issued To' and 'Issued By' values of my machine name: 'DevMachine123'. This is the certificate being served up for applications configured under the 'Default Web Site' in IIS.
localhost SSL certificate created using makecert.exe tool where CN=localhost (common name) was used. It contains the 'Issued To' and 'Issued By' values of 'localhost'. This is the SSL cert I want served up in IIS for my applications configured under the 'Default Web Site'.
The error I'm getting is:
'The security certificate presented by this website was issued for a
different website's address.'
When I view the certificate being served up from the IE browser: it shows the localhost cert issued to 'DevMachine123' is being used and not the localhost issued to localhost (#2 above) which should resolve this issue. Hence the name mismatch because 'DevMachine123' does not match 'localhost'.
Another point to make; my certificates have been added to 'Trusted Root Certification Authorities' so they both are trusted certificates.
Last point to make, I checked the https port 443 Binding configuration for the 'Default Web Site' on my machine in IIS. I view the certificate and it shows the correct localhost certificate is bound (#2 above with CN=localhost).
I feel that I have covered my bases here (yes I have seen this and this so please do not re-post). What am I missing here?
Thanks!
I had a similar issue and had also gone through the checks you mentioned above for the site bindings. I ran the following netsh command
netsh http show sslcert
This showed me two SSL Certificate bindings. One on IP:Port 0.0.0.0:443 with the correct certificate and one on IP:Port [::]:443 with an expired certificate. I opened CertMgr.msc for the Local Computer (see here for instructions) and searched for the invalid certificate and discovered it had expired.
To resolve the issue I did the following
netsh http delete sslcert ipport=[::]:443
iisreset /restart
Very similar answer to #IsolatedStorage but with some more details of what helped me.
First a couple points that are probably the same for you
I was trying to update a certificate because it has expired.
I have multiple domains bound to the same IP. They happen to be a SAN certificate but that's probably irrelevant.
I was trying to use the centralized certificate store. Again I think this is irrelevant to most of my answer.
I had already attempted to update the certificate but it wasn't showing the new date.
You're probably in a panic right now if your old certificate already expired. Take a deep breath...
First I'd recommend strongly going to https://www.digicert.com/help/ and downloading their DigiCert tool. You can also use it online.
Enter in your website https://example.com and it will show you the expiration date and thumbprint (what MS calls the certificate hash). It does a realtime lookup so you don't have to worry whether or not your browser (or intermediate server) is caching something.
If you're using the centralized certificate store you'll want to be 100% sure the .pfx file is the latest version so go to your store directory and run this command:
C:\WEBSITES\SSL> certutil -dump www.example.com.pfx
This will show you the expiration date and hash/thumbprint. Obviously if this expiration date is wrong you probaly just exported the wrong certifcate to the filesystem so go and fix that first.
If you are using the CCS then assuming this certutil command gives you the expected expiration date (of your updated certificate) you can proceed.
Run the command:
netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt
You likely have a lot of stuff in here so it's easier to open it up in a text editor.
You'll want to search this file for the WRONG hash that you got from digicert.com (or the thumbprint you got fromChrome).
For me this yielded the following. You'll see it is bound to an IP and not my expected domain name. This is the problem. It seems that this (for whatever reason I'm not sure) takes precedence over the binding set in IIS that I just updated for example.com.
IP:port : 10.0.0.1:443
Certificate Hash : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
I don't even know where this binding came from - I don't even have any SSL bindings on my default site but this server is a few years old and I think something just got corrupted and stuck.
So you'll want to delete it.
To be on the safe side you'll want to run the following comand first to be sure you're only deleting this one item:
C:\Windows\system32>netsh http show sslcert ipport=10.0.0.1:443
SSL Certificate bindings:
-------------------------
IP:port : 10.0.0.1:443
Certificate Hash : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Now we've verified this is the 'bad' thumbprint, and expected single record we can delete it with this command:
C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443
SSL Certificate successfully deleted
Hopefully if you now go back to Digicert and re-run the command it will give you the expected certificate thumbprint. You should check all SAN names if you have any just to be sure.
Probably want to IISRESET here to be sure no surprises later.
Final note: If you're using the centralized certificate store and you're seeing erratic behavior trying to even determine if it is picking up your certificate from there or not don't worry - it's not your fault. It seems to sometimes pick up new files immediately, but cache old ones. Opening and resaving the SSL binding after making any kind of change seems to reset it but not 100% of the time.
Good luck :-)
Same symptoms
Changed HTTPS binding in the drop down list to the server IP (in the site bindings dialog). It was set to "all unassigned" Got a warning about overwriting an existing certificate / IP combination, which I accepted, and and issue resolved.
Verify you have only one site set per binding in IIS as well.
If the Default site and a separate one are installed, they may both have an HTTPS binding on the same port. If this happens, the cert served may be the one from the other site.
Related
After upgradeing to Windows 11, a local ASP.Net application is no longer prompting me for my CAC and so I cannot access the site via https. I can access it fine via http. I did some looking around and my bindings were set to a cert with the friendly name 'IIS Express Development Certificate' but when I looked for that in my certificate store, or 'localhost' which it is issued by I believe, it doesn't show up. So I went ahead and created a new self-signed cert via powershell:
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "localhost" -FriendlyName "IIS Dev Express Take 2" -NotAfter (Get-Date).AddYears(10)
I copied this to my trusted root certificate authorities and intermediate authorities folders in my certficicate store and selected this new certificate in my bindings, but still have the same issue. At this point I'm not sure what else I can try to resolve this issue.
Just to add a bit more since I've been working on this for a few days now:
I've tried removing and adding back server certificates a number of times, copying them from my personal store to trusted store and intermediate store, etc. I've tried copying a coworker's applicationhost.config file, or at least the parts specific to authentication that were different from mine. I've tried running the site directly from Visual Studio rather than stand-alone in IIS. I even tried removing and re-adding IIS Express, which regenerated the IIS Express Development Certificate that was the one installed originally. It doesn't seem to matter what I do. The application has the following:
_cert = Context.Request.ClientCertificate;
if (_cert.IsPresent)
{
transferCACLoginToConsent = ProcessCAC();
}
But it never gets to the innercode because Context.Request.ClientCertificate always evaluates to false as I'm stepping through this, and without prompting the user for a CAC/client certificate.
I too have now run into this issue, also after upgrading to Windows 11. I don't fully understand the problem yet, but believe I can offer you a substantial work around. The issue is tied up with TLS, and the defaults used by Windows - TLS 1.2 for Windows 10 and TLS 1.3 for Windows 11. I was able to restore my local site's CAC authentication/authorization by modifying the Registry to force TLS 1.2. (Obviously a long term or permanent solution will entail allowing TLS 1.3 to work; I intend to continue work on that front.)
Specifically, under the existing Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\ key, add (as necessary) TLS 1.2 and TLS 1.3 keys, and then under those two new keys add a Server key for each of them. In the new Server keys, add a DWORD with the name Enabled, and set it to 1 for the TLS 1.2 path, and leave it as 0 (the default) for the TLS 1.3 path.
This site will walk you through those edits: https://thesecmaster.com/how-to-enable-tls-1-2-and-tls-1-3-on-windows-server/. It has you also creating Client keys and DisabledByDefault DWORDs, but I didn't find those necessary.
Since this solution does entail edits to you system registry, it would be prudent to export its state beforehand for revertability. I exported my 'before' \Protocols branch.
For me it worked when I checked "Disable TLS 1.3 over TCP" in the Edit bindings.
IIS edit binding window
I actually found the answer to this question already, and just want to document my finding.
The problem has to do with using Node.js to access CouchDB through HTTPS. The CouchDB server has been configured with a SSL certificate generated by Let's Encrypt. The cert_file specified in local.ini contains both the server certificate and the issue's intermediate certificate. When I verified an URL through the browser, the connection was shown as valid. However, whenever I tried to fetch the same URL from Node, an UNABLE_TO_VERIFY_LEAF_SIGNATURE / unable to verify the first certificate error would be thrown.
I tried adding the root certificate to Node using the NODE_EXTRA_CA_CERTS environment variable. That failed. Then, I tried adding the intermediate certificate to NODE_EXTRA_CA_CERTS, and it worked. I could stop there, but somehow I knew that something was wrong.
After more digging, I finally found that even though the cert_file used by CouchDB includes both the server cert and the intermediate cert, unlike some other servers, CouchDB itself would only send back the server cert. In order to fix this problem the right way, I need to specify the intermediate cert as the cacert_file in the local.ini file as well. Once I did that, the error is gone.
I know that this question was asked many times but I couldn`t make it work with answers I found on web.
My goal is to make https://my.cloudapp.net to work. So solution for this, is to buy domain and certificate and make this domain point/redirect to my https://my.cloudapp.net. I bought lets say www.example.pl. Downloaded certificate from https://example.pl. Assigned certificate to https://my.cloudapp.net using IIS.
When I visit https://example.pl certificate itself is fine but firefox shows me error:
my.cloudapp.net uses an invalid security certificate. The certificate is only valid for the following names: example.pl, www.example.pl Error code: SSL_ERROR_BAD_CERT_DOMAIN
What I`m doing wrong?
Edit Solution:
I called microsoft support and resolved the issue. The issue was on my domain provider side. My domain example.pl had forwarding wildcard *.example.pl to go to example.pl. Thats why when I made another forwarding from app.example.pl to my cloudapp it went straight to example.pl. Removed the wildcard and it started to working fine.
I attempt to visit the website https://example.pl, it works fine with IE edge or chrome explorer. Also i do a test over at the Qualys SSL Labs to check your certificate. It shows me Incorrect certificate because this client doesn't support SNI and indicate thatThis site works only in browsers with SNI support. It is the browser issue. So you could try another explorer.
You can from here to get more details.
Need help with this odd issue.
I installed an SSL Certificated from GoDaddy for a site hosted on our server (lets call this example.com). This is a Windows 2003 Server with IIS 6 with several domains hosted on it. The SSL installed properly.
However, now if I type any url of a different domain (say example.org) hosted on this same server with HTTPS, I get the following error in Chrome:
Your connection is not private
Attackers might be trying to steal your information from
(for example, passwords, messages, or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID
Firefox will also give similar errors.
example.org has no SSL associated with it and there are no other SSL Certificates for any other sites either.
I am at a loss as to how ALL sites on the server are loading with SSL. Funny thing is that clicking on the link in browser error loads the Site to which SSL is assigned, but URL remains the same.
Ex. I type https://example.org (NO SSL Associated with this site) and type enter
I see the error above
If I click on Proceed to example.org (unsafe), it takes me to https://example.org but the content loads for domain example.com which has the SSL certificate bound to it.
I have checked Metabase for Bindings and seems clean.
I have deleted the SSL certificate and installed a fresh one issued from Godaddy
Tried deleting the site from IIS and recreating the whole thing but still no difference.
No other site has any host headers for SSL Port 443
Any ideas on how this can be resolved so that ALL Sites don't load on SSL? Thanks in advance.
Go to IIS Manager.
Open property page of website where you dont need SSL (example.org as mentioned in question) by right click on website and select properties.
Go to directory security tab
Click Edit button located in ottom section of tab.
Verify if very first checkbox called "Require secure channel(SSL)" is UNCHECKED.
In my server I have one SSL Certificate which is valid from 06/09/2009 through 06/09/2011. the client is getting invalid certificate error. I reissued the certificate and installed in the server machine. But still the client is getting the same error. Is there any problem with the Browser. Can anyone reply for this issue. But If I open the page in different machine I can go to the site without any invalid certificate error message.
I have had similar problems self signed certs switching to legit certs. The browser seems to cache the cert (though it shouldn't be browser specific)
I have noticed the problem more in Chrome than other browsers. You can try dumping the cache in the browser. You can also run
certmgr.msc
and see if the expired cert shows up, if it does you should be able to delete it and hit the site again to get the new cert.
My related question on serverfault: https://serverfault.com/questions/279984/clearning-chrome-ssl-cache