An upvoted SO answer claims:
[SSL] breaks name based virtual hosting. With SSL, it's one site - one IP address.
Is that true? Does shared hosting that offers SSL certificates lease whole IP ranges?
With SSL, the server is always authenticated before application data is sent. The "Host" header of the HTTP request is application data. So, in general, you can't use HTTPS with virtual hosting.
However, if one party controls all of the sites that are hosted virtually, a single certificate can be created that lists all of the virtual host names in the "subject alternative name" extension. To emphasize, since there is only one key pair, a single private key is used to authenticate all of the hosts. This key should be controlled by a single owner.
Alternatively, Sripathi Krishnan pointed out that there is a TLS extension (currently specified in RFC 6066) that allows the browser to hint to the server which server certificate to present before the first handshake is completed. However, this extension is not universally supported.
If you look at A2Hosting SSL services, they require you to have a dedicated IP address besides shared hosting and that's it.
So yes, as long as you maintain a dedicated IP address you can obtain an ssl certificate.
http://www.a2hosting.com/services/ssl-hosting
Related
Here is my situation:
I own and control coolwebsite.com
Many websites have a CNAME entry pointing to coolwebsite.com
For example, lamewebsite.com CNAME's a.lamewebsite.com to coolwebsite.com
There are about 50 of these other websites that point to mine, none of which I can control easily
How can I get an SSL certificate that will work with these CNAME's?
There are about 50 of these other websites that point to mine, none of which I can control easily
If you have no control over these web sites or their DNS settings than you should not be able to get a certificate for these. If this would be possible than it would be a serious security issue.
This appears to be a shared hosting kind of setup where you host the websites for clients and allow them to point their own domains to your server and use SNI or host header to serve a correct website based on domain used in the request.
More information like is above correct, where you're getting your TLS certs from, do you want to use single cert to cover everything or a cert per domain would be useful, but in general you can get a certificate with multiple Subject Alternative Names for different domain names/sites.
E.g. if you're using Let's Encrypt, with Domain Validation, you don't need control over domain's DNS, only over content served from that domain. And if people point their aliases (CNAMEs) to your web server then you already have it.
My main site https://example.com has an SSL cert, no problem.
Now, I have developped a related application, that is hosted on a completely different server, and under : app.example.com. It has a dedicated IP.
The app uses websockets and needs SSL to function properly acros all devices. But I'm having trouble finding out how to register a new certificate for a subdomain... What's the strategy here? Should I have a wildcard cert on the main server, and somehow redirect from there? In that case, the app server wouldn't have access to the cert, and I wouldn't be able to create my secure socket connection, right?
The certificate has to be installed where the server which provides content using this certificate. This means
That the certificate for the subdomain has to be used on all servers which serve the subdomain, i.e. your websocket server.
And nowhere else, i.e. it is not needed at the main domain just to provide a redirect from the main domain away.
You are free to use any certificate which matches the subdomain, that is it can be a wildcard certificate but can also be specific for only this domain.
You can go for a wild card certificate and bind it to all the URL's who share the same domain. But keep in mind, the wildcard certificates (irrespective of any brands) supports unlimited first level sub domains .
Wild card certificates can be installed on any server where the FQDN is hosted. In situations where the the sub domains are hosted on multiple servers, the wildcard certificate will work for all of them.
We have a server running Win Server 2003 SP1 with IIS 6. The server runs three websites of which only one needs to be secured. However, adding HTTPS in front of any of the others redirects the user to the secured website.
From my reading I can see it's because pre SP1 SSL worked based on IP addresses only whereas post SP1 it is possible to configure it for host headers using some scripts. That's all great.
What I need to know is what the final requirements be if I have the following for my applications:
http://www.site1.com - SSL not required, but if the user types in https://www.site1.com it should not redirect to https://app.site1.com
http://www.site2.com - SSL not required, same as 1.
http://app.site1.com - SSL required.
Questions
Do I need to purchase 2 wildcard certificates for this configuration. One for *.site1.com and one for *.site2.com?
If I do get two wildcard certificates do I configure each of the sites to use them and assume that the user can choose to view https://www.site1.com can do so without being redirected
There are a number of similar questions on Stack, but not quite the same requirements. See
Hosting multiple sites in IIS 6, one need SSL
Edit
Microsoft's Recommendation on IIS6 and Wildcard certificates
I found a link where Microsoft explains more about using Wildcard certificates to configure the scenario I have described: https://web.archive.org/web/20161114165638/https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true
Note: We are definitely having the scenario where if the user browses to https://www.site1.com the browser displays the exception (which is correct) but then after accepting the exception they're being redirected to https://app.site1.com.
If you need to secure only http://app.site1.com then you don’t need to buy wildcard ssl certificate. You can simply secure your website using domain SSL Certificate. (Recommended SSL: RapidSSL Certificate, Thawte SSL123, QuickSSL Premium)
Suppose your all three websites are hosted on same IP address.
When user type https://www.site1.com then he will not redirect to your https://app.site1.com but visitor will get domain mismatch error in his browser because of same IP address.
Wildcard SSL can only secure your primary domain plus unlimited sub domain for that primary domain name.
Example: site1.com, www.site1.com, mail.site1.com, blog.site1.com
If you want to secure *site1.com and *.site2.com then you should go with Multi Domain SSL Certificate instead of Wildcard ssl certificate.
I have an application with a few war files all deployed on the same tomcat server. I need to force client authentication only for one war context, and only for a specific URL.
I've read a lot on the web and similar questions here, but the conclusions I've reached are not matching the solution I need:
define 2 connectors with different ports (one with clientAuth enabled and one without) and access the specific URL with the relevant port ==> this solution is not good since if a hacker tries to access this URL with the other port he can succeed
define transport-guarantee in web.xml (for example Enabling mutual SSL per service in Tomcat) ==> this is also not good since I don't want to define users in some realm, I just want the server to ask for the client certificate and verify it is trusted and valid.
Is there a way to use option 2 without defining users? Or maybe a third option?
Thanks in advance!
You can't do this in pure Tomcat. The best solution is to put an Apache HTTP in front of it, that terminates the SSL connection, and in which you can configure SSL to your heart's content right down to the level of an individual directory.
If you want to accept any certificate from trusted CAs, just put clientAuth="want" to Connector and write a filter to check, if a certificate was sent. Assign that filter to desired web app only. In the filter, get the certificate using:
request.getAttribute("javax.servlet.request.X509Certificate");
and check it's CA.
But remember, that any certificate from that CA will allow access. If this is a public CA, anyone can buy one and access your app. You should always check the DN, in Tomcat you do this by defining a user, or manually in a filter.
I've asked my provider for a SSL certificate. They said the CSR must be generated from a host having the ip address which blongs to the certificate. Otherwise it will not be vaild later.
As far as I know one can only assign a CNAME to a load balancer and it is not possible to generate the CSR on the load balancer. Apart from that the lb ip might change. So do you get your valid certificates?
Regards,
Jim
You don't have to generate the CSR on the load balancer. You only have to generate it with a name consisting of the required domain name. You can do that anywhere.
Jim, I had the very same question as you. This is my first foray into the realm of multi-server deployments with SSL.
I found this: http://www.martfox.com/customer/knowledgebase/140/Why-a-SSL-Requires-Dedicated-IP.html
It looks like it is commonly said that you must have a static IP address to run ssl, but it really looks like you don't need a Static IP as much as an IP that you are the only one using at the time. The IP address is not needed when signing a certificate, or creating a signing request. It is not attached to your keys in any way, so you change Static IP addresses or even move hosting providers without reissuing your SSL cert.
It appears that the limitation is because VHOSTS and other server aliasing methods don't have access to the HTTP request string before they have to connect the SSL layer, so they aren't able to route it like they do unauthenticated requests.