I am a novice in SSL working on a Spring web application running directly off of an Apache Tomcat server. It is currently configured to be able to use LDAP (non-SSL) for authentication (this was set up by a previous developer). It also is running over http (also not SSL).
I want to be able to use both LDAPS and HTTPS.
My question is will I be able to use the same certificate to enable SSL for both LDAPS usage and HTTPS usage?
You can use the same certificate if:
you use the same server name in both cases or
if you have a certificate covering both names, with both names listed in the certificate, or
if they have some common domain suffix and you have a relevant wildcard certificate
Remember that certificates are used to prove the identity of some remote endpoint, and it is typically based on the hostname of the endpoint, as shown in some URLs, either for HTTPS or LDAPS.
RFC 6125 describes how identity is checked with certificates. Section 6 for the generic idea, and then appendix B.2 for HTTPS case and B.3 for LDAPS. They both use the name.
Related
I am using a setup wherein a chain certificate(Root CA Cert-> Intermediate CA Cert -> Client Cert) is being sent to the Nginx. I need to configure Nginx in such a way that it forwards the entire certificate chain to the middleware. Right now, it is just sending the leaf certificate i.e. client certificate.
I found the following options from the Nginx's documentation (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate)
1- $ssl_client_escaped_cert
2- $ssl_client_cert
None of the above returns the full certificate chain.
Is anyone aware if there is such an option available ?
This seems to be impossible by design - see https://serverfault.com/questions/576965/nginx-proxy-pass-with-a-backend-requesting-client-certificates
The usage of $ssl_client_escaped_cert (as explained in https://clairekeum.wordpress.com/2018/12/05/passing-client-cert-through-nginx-to-the-backend/) seems to be your only option.
This may not be a complete answer, but thought I'd post some resources that may give you a couple of ideas.
If you want the client cert details downstream, then one option is to avoid terminating Mutual TLS in nginx by using the stream module. Here is an example:
Mutual TLS Secured API Blog Post .
NGINX Config
In this setup there are 2 Mutual TLS connections being routed via nginx:
To authenticate with an Authorization Server - where Mutual TLS is not handled by nginx
To call an API with a certificate bound access token - where nginx terminates TLS
Note that this uses a LUA plugin and the ssl_client_raw_cert property to do the extra work of calculating a SHA256 thumbprint, which NGINX itself does not support.
Generally though it makes sense to externalise Mutual TLS plumbing from application level components, as in the above example. Eg you can forward ssl_client_eacaped_cert to your middleware, but perhaps nginx should do the more detailed work of checking issuers.
I have 2 domains (www.domain1.com, www.domain2.com). For both, I have a separate certificate. Both domains have the same IP, but different host headers. How can I add https with cert1 to domain1 and https with cert2 to domain2 (on the same IP)? I tried to work around but didn't help me.
one www.domain1.com binding I have selected https then I have given the hostname as www.domain1.com then I have checked the SNI checkbox then I have selected the domain1 SSL.
Same steps I have done for www.domain2.com but when I run domain2.com it uses the SSL of domain1 since both domains have the same IP I don't know where I am missing my steps. You help will be much appreciated
As per my knowledge, For Multiple Certificates installation using SNI, You do not require to enter the host name and check the SNI checkbox for the primary domain (www.domain1.com), But it is compulsory to enter the host name and check the Require Server Name Indication box for second domain (www.domain2.com).
Find more information from here:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/1159/37/certificate-installation-microsoft-iis-8x#multiple
However, I recommend you to use Multi-Domain SSL certificate to protect multiple domains instead of using Multiple certificates.
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot
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.
Can I purchase a single SSL certificate for domain A and sign all of my other domains with the domain A as reference.
Will it work ?
You certainly can install those certificates. However just as with self-signed certificates the main problem is that they cannot be validated by browsers due to a broken verification chain.
In short: it won't work as you desire.
No, you can't. The certificate for SSL is issued with specific allowed usage (which is encoded in the certificate). This does not includes signing other certificates.
Consequently though you technically will be able to sign certificates for other domains using the key of certificate A, such signed certificates will not be validated right and will not work.
I think you're looking for wildcard certificates. Issuing a cert for *.mydomain.com would be valid for sub1.mydomain.com, sub2.mydomain.com, etc.
If you're looking to get a cert for mydomain.com and use that to generate a cert for otherdomain.com, that won't work.
FYI, wildcard certs are more considerably more expensive from what I remember.
EDIT:
Rereading your question, you want to do second option, and no, you can't do that. You'll wind up with an invalid cert and most browsers put up giant warning signs that the cert isn't from a trusted source. It will reference your cert for domain A as a trusted signer, which it is NOT, even though it WAS issued by a trusted signer further up the chain. If what you wanted to do was possible, the entire trusted signer/TLS infrastructure would be useless. (The utility of basic TLS as a verification that you're dealing with whom you think your dealing is debatable since it's trivial/inexpensive to get a cert. Hence the existence of Extended Validation Certificates.)
You can not sign further certificates from your certificate. Otherwise you could sign somethign like www.paypal.com under your own legitimate SSL certificate - This was demonstrated as possible via a MITM attack at a blackhat conference but this has since been rendered no possible.
However you can get Multi-Domain certificates. These certificates allow you to include additional domains in the SAN field (Subject Alternative Name). So the certificate is generated for a single domain and the additional domains are added during the enrollment process with your SSL provider. You will need to verify ownership of each domain you request.
These certificates allow you to host multiple FQDN on a single IP with one SSL certificate.
In addition there are also wildcard certificates but these only let you secure *.domain.com with a single certificate.