We have a Win 2008 server running IIS7. The webserver runs several sites, one of which requires SSL for its e-commerce / data-capture components:
www.domainA.com :80 & 443
www.domainB.com :80
www.domainC.com :80
www.domainD.com :80
I have installed a certificate for domainA and added an HTTPS/443 binding for the www.domainA.com website. However, if I try to access https://www.domainB.com, I am shown the content from the domainA site.
How can I prevent all sites using the 443 binding from domainA? When I add the certificate to the binding, I am unable to set the hostname. If I use appcmd to set a hostname, the site gets 2 bindings and access via SSL doesn't work.
Only domainA should allow access on port 443 and other sites should refuse the connection.
Thanks
James
SSL starts connection BEFORE any HTTP header is sent - so clearly the server has now way of distinguishing what domain this connection is for until SSL connection is established.
Your binding is correct - the other sites are NOT bound to port 443... but by the time the SSL connection is established and the first HTTP header is sent it is already on the IP address (the name has been resolved via DNS).
As to a solution:
To circumvent what you see you need to bind domainA.com to a different IP address than the rest (and modify DNS accordingly).
Related
I have applied a free certificate for my website and successfully installed the certificate in the certificate store. And the CN is the same as my domain(issued to mydomain).
I also set up the site bindings and added an https binding using the free certificate.
The port 443 is opened for both inbound and outbound.
Windows Network Troubleshooting detected the resource(my domain) is online but isn't responding to connection attempt.
But I still get ERR_CONNECTION_TIMED_OUT error from the browser.
Did I miss any steps? How could I enable the https in IIS?
UPDATE 11/14/2018
I have run bindings diagnostics and SSL diagnostics using JexusManager suggested by #Lex Li, and got more information as below:
Binding Diagnostics:
BINDING: https *:443:whatever.com
This site can take external traffic if,
TCP port 443 must be opened on Windows Firewall (or any other equivalent products).
Requests from web browsers must be routed to following end points on this machine,
[::1]:443.
My.private.IP.address:443.
This site can take local traffic at 127.0.0.1:443.
This site can take local traffic at [::1]:443.
Web browsers should use URL https://whatever.com:443. Requests must have Host header of "whatever.com".
Start DNS query for whatever.com.
DNS Query returns 1 result(s).
127.0.0.1
Binding Diagnostics does not verify certificates and other SSL/TLS related settings.
Please run SSL Diagnostics at server level to analyze SSL/TLS configuration.
And then I ran SSL diagnostics as below:
BINDING: https *:443:whatever.com
SSLCertHash: 2962cd5b2b450403bce520169c268de1f17a6216
SSL Flags: None
Testing EndPoint: 127.0.0.1
CertName: whatever.com
Version: 3
You have a private key that corresponds to this certificate.
Signature Algorithm: sha256RSA
Key Exchange Algorithm: RSA-PKCS1-KeyEx Key Size: 2048
Subject: CN=whatever.com
Issuer: CN=TrustAsia TLS RSA CA, OU=Domain Validated SSL, O="TrustAsia
Technologies, Inc.", C=CN
Validity: From 11/11/2018 4:00:00 PM To 11/12/2019 4:00:00 AM
Serial Number: 0B365B8ABC8118CD7F818FD5B7BB485C
DS Mapper Usage: Disabled
Archived: False
Subject Alternative Name: DNS Name=whatever.com DNS Name=www.whatever.com
Key Usage: KeyEncipherment, DigitalSignature
Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1),Client
Authentication (1.3.6.1.5.5.7.3.2)
Basic Constraints: Subject Type=End Entity, Path Length Constraint=None
Certificate verified.
And, I also have run an SLL Checker and it returns:
whatever.com resolves to My.Public.IP.Address
Server Type: Microsoft-IIS/8.5
No SSL certificates were found on whatever.com. Make sure that the name resolves to the correct server and that the SSL port (default is 443) is open on your server's firewall.
The certificate passed the SSL Diagnostics but it has some problem. I didn't get it. How could I enable https protocol for my site? Many thanks!
Problem solved.
As #John Wu said, this is not a programming problem but a network gateway problem.
First, the certificate has no problem and so does the server/firewall setting.
The problem occurred in the network gateway of the cloud service provider that blocked the 443 port inbound and outbound. In my case, I am using AliCloud server and it blocked every request which went through 443 port from the public network. And this is why I could only get access to the SSL website through the browser on the server.
The solution is very simple. The only thing needs to do is to inform the cloud service provider to open the 443 port. In my case, I just added the 443/443 port authorization in the control panel of the cloud servers and then everything fixed.
I have a website on server 1 that has an SSL certificate, I need to move a new developed site to server 2 which has a new SSL certificate. The SSL has been installed on server 2, is there anyway to check if the site and the ssl certificate works before changing the nameservers from server 1 to server 2.
I have tried editing the hosts file on my computer with the IP address of server 2 and the site loads, but as it only shows the IP address in the url bar so there doesn't seem to be a way to tell if the SSL is working, if i add https:// to the domain IP it doesn't work.
Thanks in advance.
When you change the hostfile to the second server with the correct domainname it should listen as if it were used from a nameserver from the outside world.
For example, if you want to test server 2 with IP 194.194.194.194 with the domainname www.example.com you should add this line to your hostfile:
194.194.194.194 www.example.com
After you add this it is possible to go to https://www.example.com which should serve you the certificate if everything is configured right.
Cheers!
I have a ASP.NET MVC site set up in IIS7 on Win2K8 with a single SSL binding on Port 443. The team in charge of the server only has port 443 open for security reasons, but this shouldn't be any issue because that's the only binding I have and I'm not making any regular HTTP calls on port 80.
When I call my site, my main login page (using forms authentication) comes up in the browser (over HTTPS) which looks fine. However, as soon as I try to login I get the following error:
[SocketException (0x274d): No connection could be made because the target machine actively refused it 10.x.123.123:80]
Ok that is the correct IP assigned to the site, but I'm not making any calls on port 80. Why would I get this error if all I need is a SSL binding on port 443? Am I required to have port 80 open as well? I'm not making any calls internally that use port 80, unless MVC is doing something I'm unaware of that requires port 80.
When digging into the code it turns out that our service turned around and made additional REST calls to other parts of the same service using a HTTP url, thus causing the error.
Since I configured IIS to only allow SSL traffic and I had internal calls to a HTTP URL the error was generated. The root cause was that I forgot we were making RESTful calls within the code and those URLs had to be updated to their respective HTTPS counterpart.
I have multiple sites running on my IIS, now for one of the websites (SiteB) we need to support ssl requests. I have enabled it editing bindings for the website, but the problem is when I selected protocol SSL editing bindings HostName field is disabled, being unable to set hostname to respond to https request, this causes that all sites of my IIS if are requested with https:// loads web site of siteB.
For example my bidings are the next
Site A
IP Port HostName
* 80 www.sitea.com
Site B
IP Port Hostname
* 443 www.siteb.com
* 80 www.siteb.com
If I type https://www.siteb.com in my browser it works correctly, but if I type https://www.sitea.com in the browser, siteb webpage is loaded with the hostname of sitea.
How Can I make that only https://www.siteb.com responds to https requests on my IIS?
I have tried with command appcmd too but It't doesnt work.
appcmd set site /site.name:{sitB} /bindings.[protocol='https',bindingInformation='*:443:*'].bindingInformation:*:443:siteB.com
Thanks for your help.
The Root Problem
This unexpected behavior isn't because of IIS so much as it is because of the web encryption protocols.
The two major web encryption protocols are SSL and TLS. Both of these protocols negotiate a secure connection before passing any request information to the server. This means that, on secure requests, servers don't actually learn the hostname until after the secure connection is made.
An extension to TLS and SSL has been created to address this limitation. It's called SNI (Server Name Identification). The problem is that this extension needs to be supported on both the server and client machines. Currently the client browser support is somewhat spotty. See the SNI article for a browser list.
IIS's Handling Of The Problem
It is because of the above mentioned hostname limitation that IIS doesn't allow you to bind hostnames to HTTPS bindings. There is no way for IIS to route HTTPS requests to a particular hostname since it doesn't know the requested hostname when it first begins to negotiate the connection.
Once IIS has negotiated a secure connection with a client and learns that their requested hostname is for a site other than the one with the HTTPS binding (e.g. a request for https://sitea.com) IIS can either return a failure code or try to fail gracefully. IIS chooses the latter and tries to fail gracefully by serving up the site with the HTTPS binding even though the user is requesting a different site.
Solutions/Workarounds
Create a rewrite rule to redirect all HTTPS requests for nonsecure websites to HTTP.
Upgrade to IIS 8 to use the SNI extension. Then ask visitors to upgrade to browsers that suport SNI.
Have your secure site return an error message when it receives a request for a different domain.
Bind by IP address instead of hostname since IIS can route HTTPS requests by IP address
References
Most of my information came from the Wikipedia article on SNI
We run webservers with multiple sites requiring SSL with no problem.
If I understand your problem correctly - you'll need to set up a binding instead of a host name - which won't work. So, for each SSL-enabled site we host, we require a distinct external IP address. Then, enter that IP address as the binding when setting up the site in IIS.
I have the following Web Farm:
1. http: mydomain1.com port: 80
2. http: mydomain2.com port: 80
3. https: port: 443 SSL Certificate: myCertificate
In II7 when you select https binding, the host name will be disabled.
I used the appcmd to bind the host name "admin.mydomain2.com" to the
website.
appcmd set site /site.name:"admin" /+bindings.[protocol='https',bindingInformation='*:443:admin.mydomain2.com']
A new item was added to the bindings.
3. a. https: port: 443 SSL Certificate: myCertificate
b. https: admin.mydomain2.com port:443 SSL Certificate: None
If for example I want to remove the first item (a), is it possible to assign a certificate to the second binding (b)?
Links as answers are not the best way to do it, because often those links go cold. Here's a summary of the answer posted above, along with supporting information from elsewhere.
When it comes to SSL, host headers are really left out in the cold. The purpose of SSL is to encrypt your traffic, and part of that traffic is the HTTP headers sent by the browser to the server. One of those headers would be the "Host" header which IIS uses to determine which site to load up with the request. Since the certificate needs to be loaded to establish the secure connection BEFORE the request headers are sent, IIS has to select the certificate based only upon the IP address and port number, thus rendering the host header useless. This, however, does not relieve us of having to comply with STIG v6724 as it relates to IIS Site configuration. So, instead of allowing you to enter the information even though it's useless, Microsoft attempts to out-wit you by not allowing you to enter it at all. There is, however, a way around this.
Please note that this answer assumes that your certificate has already been generated, added to the certificate store, and added to IIS. It also assumes you do not want any other bindings to your website besides the SSL one.
First, we need to gather some information. We need the hash, the application ID and the host name.
Open IIS, select your server and double click on "Server Certificates" in the bottom section.
Note the "Issued To" address. This is our host name. Save this.
Select your site
Bind your site to port 80 using the http protocol
Remove all other bindings
Bind your site to port 443 using the https protocol
Open a command prompt
netsh http show sslcert
Save the Certificate Hash and the Application ID
Remove the https binding on your site
At the command prompt:
netsh http add sslcert ipport=0.0.0.0:443 certstorename=my certhash=<put Certificate Hash here> appid={<put Application ID here>}
appcmd set site /site.name:"<put site name here>" /+bindings.[protocol='https',bindingInformation='*:443:<put host name here>']
NOTE: Appcmd.exe can be found in c:\windows\system32\insetsrv. You may need to be in that folder for this command to work.
Remove the http binding from your site
NOTE: You can leave the http binding if you want to have your site auto-redirect to https, but that is another topic.
REM Solution to bind https for "Default Web Site" on IIS 7
cmd /c
pushd %systemroot%\System32\inetsrv
set sitename=Default Web Site
appcmd set site /site.name:"%sitename%" /+bindings.[protocol='https',bindingInformation='*:443:']
REM To assign ssl certificate to "Default Web Site" on IIS7
REM Go to inetmgr assign ssl certificate manually to the "Default Web Site" in Edit Bindings
REM Go to DOS command prompt use command (netsh http show sslcert) and get the Certificate Hash (certhash) and Application ID (appid) information
REM Execute the netsh command
netsh http add sslcert ipport=0.0.0.0:443 certhash=******** appid={********}
This blog post might help you. It got me to the point of having the host header defined in IIS and the correct SSL cert assigned to it, and while it worked fine locally if we pointed 127.0.0.1 to the site's address in the hosts file, it just timed out when put in production. Hopefully it'll get you a little further:
http://www.awesomeideas.net/post/How-to-configure-SSL-on-IIS7-under-Windows-2008-Server-Core.aspx
Remove all your bindings, assign the SSL cert with the command line, then add the SSL bindings with host header via the command line.