I am running an Apache web server and I have supposed to put 2 SSL cert on a single website. Is this possible? how can I do this? I read the apache user manual and it says I only can have 1 SSL cert for a single IP and port.
After the comments from the OP:
Setup two subdomains - one for static/to be CDN'd content and one for dynamic/not to be CDN'd content.
Get + setup a "wildcard cert" for your domain i.e. a cert for "*.yourdomain.com"... these are a bit more expensive but exactly for your situation...
As Yahia points out. A wildcard cert is an option. They are also expensive.
You can certainly have multiple named SSL certs on your server for images.domain.com and static.domain.com or whatever named sites you want and that is not a security issue. In fact, that is considered more secure than a wildcard cert.
It is true that you can only have one named cert per IP. Because SSL certs are bound to the IP in the web server config. So you would need to have multiple IP addresses on the server hosting the sites. If the dynamic and static content are already on different machines, then you're set there, but it sounds like they are on the same machine.
That doesn't mean that the ports need to be different between the site. You can have both 123.45.67.89 and 123.45.67.88 listening on the same port (443 in this case) on the same machine.
Here is a post I found that looks like it describes the config pretty well.
http://wiki.zimbra.com/wiki/Multiple_SSL_Virtual_Hosts
Related
This question already has answers here:
Is it possible to have SSL certificate for IP address, not domain name? [closed]
(7 answers)
Closed 11 months ago.
I wonder why I am getting certificate error if I try to access a site with ip address instead of domain name. Lets say for example nslookup says google.com is 173.194.43.96, so I tried to browse https://173.194.43.96 and I got certificate error saying that the security certificate presented by this website was issued for a different website's address. Why is that so?
This is because an SSL certificate is issued for a particular domain name. If the certificate name doesn't match the visited domain, the browser will show an error.
One of the main functions of SSL is to prove to the user that they are really connecting to the site they requested, and not to an attacker masquerading as the end site. Without linking the domain name to the certificate this would not be possible.
It is conceivable that the browser certificate system could have been designed to include the IP address in the certificate, but this would make it difficult to use DNS load balancing or even to change hosting providers, as a new certificate would have to be issued each time this happened. If the certificate included just the IP address and not the domain, this would leave the user defenseless against DNS spoofing attacks. So the only way forward really was to use the domain alone.
As a matter of interest, it is possible to obtain an SSL certificate for an IP address - and as Google is their own certificate authority, they could issue themselves a certificate for 173.194.43.96 and thus make it possible to browse google securely by ip address, so long as they used SNI to serve up the correct certificate. It seems implausible that this would be worth the additional complexity however...
This is a nice introduction to SSL if you want to read more:
https://timnash.co.uk/guessing-ssl-questions/
On MAC High Sierra and Python 3.6.4, I tried the solution: requests toolbelt:HostHeaderSSLAdapter 1st, unfortunately, it doesn't work for me, then I tried
forcediphttpsadapter, got it works finally.
The author explains everything in the readme part and has provided a sample script and it can be followed easily.
1.Install the library by pip install requests[security] forcediphttpsadapter
2.run the sample script:
import requests
from forcediphttpsadapter.adapters import ForcedIPHTTPSAdapter
session = requests.Session()
session.mount("https://example.com", ForcedIPHTTPSAdapter(dest_ip='1.2.3.4'))
response = session.get(
'/some/path', headers={'Host': 'example.com'}, verify=False)
Note: For some cases, you may need to remove the prefix: 'www' from the url.
What happens is that the certificate is issued to www.google.com, and not to its IP address. Hence, your browser won't be able to verify the certificate, which lists www.google.com as entity.
For more info, see: www.digicert.com/ssl-support/certificate-name-mismatch-error.htm
The Common Name is typically composed of Host + Domain Name and will look like www.yoursite.com or yoursite.com. SSL Server Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must be the same as the Web address you will be accessing when connecting to a secure site. For example, a SSL Server Certificate for the domain domain.com will receive a warning if accessing a site named www.domain.com or secure.domain.com, as www.domain.com and secure.domain.com are different from domain.com.
I am quite confused here:
I use DNSMadeeasy to manage my DNS. I have two apps.
One is Heroku hosted, and has https on https://example.com - Heroku has many great tutorials to setup the certificate, it hasn't been a problem.
The other one is a wordpress, hosted in 1and1 (though it shouldn't matter here), and is reachable at http://subdomain.example.com and we want it to be available at https://subdomain.example.com
1and1 does sell SSL certificate, but their automated setup works only when one uses their services for DNS also, as they say. Their support says it should be DNSMadeEasy which should be hosting our SSL certificate. I have the feeling it is not true, because for https://example.com, DNSMadeEasy was never involved.
Questions:
When does certificate querying occurs? Before, After, or in parallel of DNS resolution?
Who is hosting a certificate? The DNS provider? The server (accessible like a sitemap.xml at the root for instance)? A third party?
To enlarge the case, in general if I have a personal server with a fix IP, how can I communicate through https with a valid certificate?
In my case, how can I get my way out of it to make https://subdomain.example.com work?
You are right for not believing the 1and1 suggestion.
To answer your questions:
When does certificate querying occurs? Before, After, or in parallel
of DNS resolution?
A client resolves domain name to an IP address first. So DNS resolution happens first.
Who is hosting a certificate?
The server (in simplistic terms) hosts the certificate.
When a client wants to connect to your site (via HTTPS) it will first establish a secure connection with that IP address on port 443 (this is why usually (without SNI) you can only have one SSL certificate per IP address). As part of this process (which is called handshake) a client can also specify a server name (so-called server name extension) - this is a domain name of your site. This is useful if you have an SSL certificate that is valid for multiple domains.
A good/detailed explanation how it works can be found here
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
if I have a personal server with a fix IP, how can I communicate
through https with a valid certificate?
Your server will need to be able to respond on port 443 and have/host an SSL certificate for a domain that resolves to that IP address.
In my case, how can I get my way out of it to make
https://subdomain.example.com work?
You need to purchase a certificate for subdomain.example.com and install it on the wordpress server.
Usually in hosted solution like yours you have 2 options:
Buy the SSL certificate via the provider (1and1 in your case) - a simpler option, they will configure everything for you.
Buy the SSL certificate yourself. Here you will most likely need to login to your 1and1/Wordpress management interface and generate a CSR (essentially a certificate request). Then you purchase the SSL certificate using this CSR and then you can install it via the same management interface.
The process will look similar to this:
http://wpengine.com/support/add-ssl-site/
we need to host multiple site with different domains.
for instance
a.test.dk
b.test.dk
a.test.fi
b.test.fi
Now from what i know is that being either in apache or iis you would need 1 ip/host when using a domain ssl certificate, that means we would have to buy
4 certificate and 4 ip addresses to host them on
another option is to use wildcard certificates , if we buy a *.test.dk and a *.test.fi we can use 2 ip/addresses and 2 certificates to host the same amount of sites since our iis/apache can use sni.
But now my real question :
there is also something called multiple domain ssl
will this be allowed to run all 4 sites under 1 ip-address?
because we are strugling with our use of external ip-addressess at this moment.
Well you're confusing 2 different things. You're confusing wildcard certificates and SNI (Server Name Indication). They are definitely different solutions to similar problems.
Wildcard certs do not rely on header inspection to encrypt your traffic, you just point the DNS at the IP address you want and your request goes to whatever site you've configured in IIS.
SNI is different and is what you want. SNI inspects each HTTP request and figures out what IIS site you want based on the host headers. Before SNI existed you couldn't inspect headers in SSL requests because the headers were encrypted too.
With SNI, assuming you have certificates for each site (wildcard certs or single site certs, UCC certs, or some combination of those) you can use SNI to inspect each HTTP request and serve up the appropriate SSL cert and site. You can do this for as many websites as you'd like and share 1 IP:port combination across them all.
Here is a WikiPedia article that explains it in a little more detail:
http://en.wikipedia.org/wiki/Server_Name_Indication#Background_of_the_problem
Here is an article on how to configure it in IIS 8 and above:
https://www.digicert.com/ssl-certificate-installation-microsoft-iis-8.htm#multiple
In step 18 in those instructions is where you enable SNI.
Here is an article on how to configure it in Apache 2.2.12 and above:
https://www.digicert.com/ssl-support/apache-multiple-ssl-certificates-using-sni.htm
I'm implementing mutual SSL between service A and service B. Service A uses both 1-way and 2-way SSL. 1-way for the communication between a user and website A, and 2-way SSL to forward requests from that user to the service B in a secure way.
1-way SSL in service A is specified in Tomcat server.xml. 2-way SSL is implemented using JSEE secure socket communication on the client side (service A), and Tomcat config (service B). Atm. when I try to access service A I get ssl_error_rx_record_too_long error.
According to this answer ssl_error_rx_record_too_long and Apache SSL one of the reasons may be the fact that I'm using more than one SSL certificate for the same IP. Is this really the case that you can't use the same IP for several certificates? Even if one certificate is a server certificate (for 1-way SSL) and another is a client certificate (for 2-way SSL)?
This may not be the cause of my problem, but I just want to make sure if it's actually possible to have several certificates for the same FQDN. Thanks for help!
ssl_error_rx_record_too_long generally has nothing to do with certificate configuration, but the fact that what's talking on that port isn't actually using SSL/TLS.
The answers (and even the update to the question) in the question you linked to also point to this problem (e.g. missing SSLEngine on). You probably forgot something like SSLEnabled="true" in your connector configuration.
As I was saying in an answer to your other question, being able to configure two server certificates on the same IP address isn't really a problem for your case.
it's actually possible to have several certificates for the same FQDN
It is possible to configure multiple certificates on the same IP address and port using the Server Name Indication TLS extension, but both servers and clients would need to support it. In particular, this is not supported by the JSSE in Java 7 on the server side (only on the client side), but there are workarounds if you're willing to put a reverse proxy in front of your Java server.
This wouldn't be possible to do this with the same FQDN, since it's what allows to pick the certificate. This being said, having multiple server certificates for the same FQDN on the same IP address is generally pointless. Supporting multiple certificates is precisely useful when you need to support distinct names.
I have a site that has subdomains for each user and a wildcard SSL Cert
https://user1.mysite.com
https://user2.mysite.com
The question is can someone set a cname record such as user1.theirsite.com -> user1.mysite.com and have it still use https?
Will it work if they install a SSL Cert on their server to secure the connection?
Thanks
The best way for this to work is if they arrange with you to have your SSL certificate include their "alias" as a Subject Alternate Name extension in your X.509 certificate.
This is the approach used by some CDNs when they host https sites for clients - they put all of the known site names that are hosted on one server in one large SSL certificate, and then the clients use CNAMEs to point their domain at the right CDN server.
The host name and certificate verification (and in fact, checking that SSL is used at all) are solely the responsibility of the client.
The host name verification will be done by the client, as specified in RFC 2818, based on the host name they request in their URL. Whether the host name DNS resolution is based on a CNAME entry or anything else is irrelevant.
If users are typing https://user1.theirsite.com/ in their browser, the certificate on the target site should be valid for user1.theirsite.com.
If they have their own server for user1.theirsite.com, different to user1.mysite.com, a DNS CNAME entry wouldn't make sense. Assuming the two hosts are effectively distinct, they could have their own valid certificate for user1.theirsite.com and make a redirection to https://user1.theirsite.com/. The redirection would also be visible in the address bar.
If you really wanted to have a CNAME from user1.theirsite.com to user1.mysite.com, they might be able to give you their certificate and private key so that you host it on your site too, using Server Name Indication (assuming same port, and of course same IP address since you're using a CNAME). This would work for clients that support SNI. There would however be a certain risk to them in giving you their private keys (which isn't generally recommended).
The following is set up and working:
DNS entry for a.corp.com -> CNAME b.corp2.com -> A 1.2.3.4
The haproxy at 1.2.3.4 will serve up the cert for a.corp.com and the site loads fine from a webserver backend.
So, on your server you will need user1.theirsite.com cert and it will work.