I have a website in my local network and the website is not ssl secured.
Many clients can not reach the website because of
"ERR_SSL_VERSION_OR_CIPHER_MISMATCH"
Is there any way to secure websites in a local network with ssl? I am using an Active Directory Server in my network.
There are also a lot of local Websites on a vmware that are not secured. I would like to secure them easily.
• I would suggest you to please install ADCS (Active Directory Certificate Services) role in your Active Directory and create a self-signed SSL certificate through it for your internal use. Since, Active Directory is a trusted public key authentication infrastructure provider, the concerned role installed on it for the said purpose does not need certificates from globally trusted CA (certification authority) and can be thus, used locally. For the time being, if you want to create a self-signed SSL certificate on the concerned server, you will have to install ‘Web Server (IIS)’ role and then open the ‘IIS manager’ console from where you can generate the SSL self-signed certificate and bind the same to the website on that server itself. For this process, kindly refer to the link below which explains in detail the steps to be followed for generating a self-signed certificate and binding it to a website: -
https://www.thewindowsclub.com/create-self-signed-ssl-certificates-in-windows-10
Please note that the above stated process is for that server on which the website is hosted locally. Thus, the self-signed certificate generated will not be useful on other servers in your environment.
• To generate an SSL certificate for a web service/website that is hosted on a cluster of servers configured for the same purpose/website, then you will have to configure an SSL certificate template from a root CA, in your case, an AD server installed with ADCS role will serve as a root CA in your domain environment. Then assign that template to the CA (AD server in your case) for it to authorize the issuing of the configured SSL template to the concerned server where the website for which this SSL certificate is to be installed is hosted. For more detailed information regarding this, please refer to the documentation link below: -
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn781428(v=ws.11)#obtain-an-ssl-certificate-from-ad-cs
Please note that the above link states the issuing of the SSL certificate for an ADFS Server. You will need to change the Subject Name of the issued certificate to that website for which you are issuing this certificate.
Related
A Certified Domain should be accessible only if SSL public certificate of the domain is already present in client's trust store. If not, client should prompt to import server certificate instead of getting it from tomcat server automatically(Via SSL handshake)
This will not work: the server has no knowledge which CA certificates are known to the client so the server cannot decide what to send to the client. Also, the server can only send a certificate to the client but not make the client import a new root CA - no matter if with or without prompt.
Apart from that it makes no sense: the idea of TLS/HTTPS is that the client will only connect to a server which identity can be verified. If the server can make a client import a new trusted root CA an attacker could do the same and thusman in the middle attacks would be possible.
If one instead just want to know if the client will trust a specific certificate or not one could include a resource (image, script...) served with this certificate into a known good HTML page and then check with some script in the page if the resource was loaded successfully. This check could also result in a redirect of the client, for example to some page describing the problem and linking to the correct root CA.
I have created a self-signed certificate on IIS and added it to Trusted Root Certificates using mmc.exe and when I launch my intranet using https://ipaddress shows secure. But when I go LAN and browse for the https://ipaddress shows me not trusted. I also used on IE, which I installed the certificate but still showing not trusted. Am I missing something, please help.
Self signed certificates are not trusted by browsers as the issuer (yourself) is not a trusted Certificate Authority. However, you can trust the self signed certificate if you want by adding the particular certificate to Trusted Root Certificate store. For IE, import the certificate to the Trusted Root Certificate Authorities folder in the client machine. Note that this has to be done on all client browsers/machines to trust your certificate.
Also, there could be other reasons for not trusting the certificate, please read the error description clearly.
If you use subdomain, i.e. subdomain.domain.com, the domain administrator (IT) should provide you with a wildcard certificate.
The domain administrator generates and assign the certificate to your subdomain server, also should allow port 80 and 443 firewall rules so that users can visit the site in the intranet.
The above answered methods can be used to generate the certificate, preferably sha256 certificate. Once the certificate is provided to you, install it on your server to “Personal”, “Trusted Root Certification Authorities” and “Web Hosting”. Open the certificate to validate it installed successfully, and you can use the thumbprint to sign files, such as rdp files. To do this, on your keyboard, START + R to open the run command and enter “certlm.msc” and once the window opens, navigate to “Trusted Root Certification Authorities” and there should be the certificate that was just being imported, i.e. *.domain.com, double click to open the certificate and click on Details tab. Drag the scroll bar until the Thumbprint is visible and then click on it to revel the code. Create an rdp file to your subdomain and save it to your desired location, such as desktop. Open CMD terminal and CD to the location and enter “rdpsign /sha256 thumbprint ‘./sumdomain.domain.com.rdp’”. Done, now when you open the connection, the compute should be trusted to connect to RDP, this process is not necessary, but it is nice to see the publisher is recognized.
The benefit of having the *.domain.com certificate generated for your organisation is that users should have this certificate already installed on their PCs and when they visit your website, users would automatically see the HTTPS secure padlock for SSL certificate. The certificate would usually be generated to allow all subdomains, i.e. *.domain.com.
IIS, When setting up the HTTPS binding on your IIS settings, check the "Require Server Name Indication" and continue to browse for the certificate and select and save the settings. Also turn off Directory Browsing while you’re there. Go to SSL Settings and check on Require SSL and hit Apply and go back. To control the flow of HTTP to HTTPS when users visit your site, you can use “URL Rewrite”, install it from Microsoft and you can do the configuration, please check on https://www.ssl.com/how-to/redirect-http-to-https-with-windows-iis-10/ for the appropriate settings. Even though, this answer is out of the scope for the question, it may be helpful for anyone who look forward to configuring their intranet site. Next to checkout is the security for who accesses your site, check on AppPoolIdentity, more help on IIS7 Permissions Overview - ApplicationPoolIdentity.
I've read quite a few articles on the client certificate authentication in IIS but they mostly talk about the Required mode for the client certificate. In this case, the authentication is fully done on the web server side and the user is redirected to the error page in case the certificate is missing or invalid. What I need is to configure IIS to check the client certificate if it exists and pass the results as http headers to my backend. It can be easily done with nginx or apache web servers. The client authentication can be set up as optional. Then, the web server checks the certificate and pass the results of the check as SSL_CLIENT_CERT (PEM representation of the certificate) and SSL_CLIENT_VERIFY (the result of the check - SUCCESS, NONE,...) headers to the application backend. So, on the backend part, I can read the headers and use the values to do the actual authentication -- find a user in the database, issue an auth token. Is it possible in IIS? If yes, is there any documentation on how to bypass the certificate and the check state as http headers?
After a while, I'm writing an answer to my question.
IIS has to be set up with ARR extension to act as a reverse proxy. Then, the client certificate authentication can be enabled for the default web site. Here are several links to instructions how to achieve it:
https://blogs.msdn.microsoft.com/benjaminperkins/2014/06/02/configure-application-request-routing-arr-with-client-certificates/
https://blogs.msdn.microsoft.com/asiatech/2014/01/27/configuring-arr-with-client-certificate/
and couple of links to very solid explanations of the SSL/TLS handshake and certificates in general:
https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/
https://blogs.msdn.microsoft.com/kaushal/2013/01/09/self-signed-root-ca-and-intermediate-ca-certificates/
https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/
Basically, the Application Request Routing (ARR) extension should be enabled for the IIS to act as a proxy. Then, you set up proxy bypass routes. Next, you need to set up a valid server certificate for the IIS server and use it in the Default Web Site https bindings. The certificate should be issued by a CA which certificate should be placed into the Trusted Root Certification Authorities and Intermediate Certification Authorities of the Local Computer. Then, you should require SSL in the SSL settings of the Default Web Site with the client certificates setting equal to Accept. In this case, any client that connects to the web server will be asked for a valid client certificate that has been issued by the same CA as the server certificate.
Actually, IIS sends a list of distinguished names of root issuers that are trusted by the web server to the client browser. The browser finds an intersection of this names with client trusted certificate issuers and looks for valid certificates that have been issued by the issuers in the intersection. After that, the user selects one of them (or none) and the selected certificate is checked against the CA certificate. If the certificate passes the check the request is "redirected" to the backend application with the certificate in the X-ARR-ClientCert header. The name of the header can be changed in the Server -> Configuration Editor -> system.webServer/proxy -> clientCertHeaderName IIS parameter. In case the user selects (or has) none of the required certificates, the request is "redirected" to the app backend without the header.
Seems, there is no need in the SSL_CLIENT_VERIFY header with the state of the check at all. If the certificate is valid it is passed in the header. If the certificate is missing the header is empty. If the certificate is provided by the client but is invalid then the request fails and is not "redirected" to the backend app server at all. Seems, it is a rare case but I have an example.
Imagine, a server certificate is issued by a CA with a distinguished name XXX, and there is a client certificate YYY (on the client computer) that is issued by a CA with the distinguished name XXX but those CAs are not the same (one or both of them are self-signed). In this case, the YYY certificate is present in the certificate selection dialog that is shown by a browser but the certificate doesn't pass the further validation against the real web server CA.
That's it. Also, seems IIS has no way to require (or accept) a client certificate for some app endpoints (addresses) only. I haven't found any other option apart from enabling in for the whole web site.
IIS ARR can also be configured with a client certificate for the backend or upstream server. In this case users connecting to this IIS do not need to provide the certificate as it will be attached by IIS automatically.
This configuration is available on IIS server level only.
I've tried setting up SSL for localhost running my azure web role.
What I've done is that I've created my own CA, created a client and server certificate and then installed them all in my certificate store. The server certificate is located in the local computer personal certificates, the client certificate is installed in the current user store under personal and the CA certificate is installed in trusted root certificates in both stores.
I've also configured my IIS website to use SSL and used netsh to bind the server certificate to the ip the site is running on.
However when I try to access my website through the IIS, I get an error:
HTTP Error 403.16 - Forbidden
Your client certificate is either not trusted or is invalid.
I know for a fact that the certificates I use are issued by the same CA, so I cant really see any other reason than that the IIS probably cant access my trusted root store. When I deploy my solution to azure, it works without giving me this error, so I'm positive that its a configuration issue with the local IIS that I cant work out.
Any suggestions on what could be the problem here?
I have purchased an SSL certificate and installed it to my Heroku app.
However when I try to access my site via https, Chrome reports that:
The identity of this website has not been verified. • Server's
certificate does not match the URL.
Other browsers report a similar message.
Inspecting the certificate information in Chrome shows that my site is still using Heroku's certificate, issued by Digicert (instead of my own CA).
Any ideas as to what I could be missing?
The problem had to do with an incorrectly set DNS record.
As per the documentation (...), once the certificates are uploaded to Heroku, do:
heroku certs
This provides you the correct end point for the SSL enabled domain. This is a domain that looks like "tokyo-2121.herokussl.com".
Next, go to your DNS service provider and update/add the CNAMe record for the SSL enabled domain to point to "tokyo-2121.herokussl.com".