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.
Related
We have a AngularJS application where we have a nodejs app which creates certificates and key for service hostname only when HTTPS port is 443. Then created certificates are consumed in nginx as shown below:
<% if ENV["HTTPS__ENABLED"] == "true" %>
listen <%= ENV["HTTPS__PORT"] %> ssl;
# These files are generated by the node app
ssl_certificate /cert.csr;
ssl_certificate_key /tls_private_key.csr;
ssl_protocols TLSv1.2;
<% end %>
But when I set 443 port in route with re-encrypt termination it gives below error while accessing application
Application is not available
The application is currently not serving requests at this endpoint. It may not have been started or is still starting.
The request is not even reaching pod. If I create route with edge termination is gives error
400 Bad Request
The plain HTTP request was sent to HTTPS port
As in Edge termination there is no encryption from router to pod.
I cannot use passthrough termination policy as we have path in our route which is not supported by passthrough termination.
can someone please let me know how to achieve end to end encryption in openshift 4.3. We do not use custom domain here.
I was checking the way for creating re-encrypt route
oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
but as we are not using custom domain our route should use default cert and key right? So no need to provide those right? I am not getting how to create --dest-ca-cert for this route.
TLS is already enabled in our AngularJS app using a nodejs app which creates cert and key which is consumed by Nginx.Pod inside the cluster uses TLS, it’s issued by a CA, that’s the cert we should put in destinationCACert for the route.The CA cert is how the router determines if it can trust the upstream POD for the TLS communication.
We used ca.cert located at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt as destination certificate while creating re-encrypt route. We selected HTTPS port while creating route.
oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
Here tls.cert and tls.key is not needed for us as we were using default domain of the openshift cluster.Only cert we used is --dest-ca-cert which is also found at secret service-serving-cert-signer-sa-token-l42lm of openshift-service-ca namespace
For re-encrypt route the pod needs to be configured with a TLS certificate as it has to respond to TLS request originated at Openshift router. You already have it as evident from the error you are getting when trying to use edge route.
Now this TLS certificate, must be created with same host name that you want to use in the actual route. It is not necessary that this TLS certificate is a CA signed one, but the hostname must match with the route. Only then the route can forward traffic to your pod.
I have 2 sites running on the same machine, a client and an API.
Let's say the computer's IP is 10.10.10.10.
The API has a default page when you browse to it, the rest of the API is under 10.10.10.10/api.
The API has HTTP binding to port 80, and HTTPS binding to port 443.
The client has HTTP binding to port 8080, and HTTPS binding to port 64300.
Both HTTPS bindings use a self signed certificate I created via IIS manager.
Both sites have a HTTP to HTTPS redirect using "URL Rewrite".
When I try to browse either one of the apps, it works fine (gives the warning in the browser that you can skip).
When I do some action in the client which involves a HTTP request to the api using one of the following calls I get an error:
http://localhost/api/someMethod
http://localhost:80/api/someMethod
https://localhost/api/someMethod
https://localhost:443/api/someMethod
https://10.10.10.10/api/someMethod
The exception includes this error:
"The remote certificate is invalid according to the validation procedure"
I tried using the method described in this link (add the self-signed certificate to the Trusted Root Certificate Authorities folder) but it won't work.
Help please :D
found the answer.. posting if anyone else will get stuck on it.
It's pretty weird but the only thing that worked was to make the localhost http(s) request using the HOST NAME.
example:
https://the_name_of_the_computer:443/api/someMethod
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.
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).
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.