I've read a bit about SSL certificates, and in particular I've read that an SSL certificate "requires a dedicated IP address". Now, I'm unsure of the meaning of this; does it mean that the certificate requires a dedicated IP address separate from the IP address used for normal HTTP communication, or just that it can't share the IP address with other SSL certificates?
To clarify, I have a VPS with a dedicated IP address. The VPS is hosting quite a few different sites, including several subdomains of the main site, but only the main site and the subdomains requires SSL. Can I simply purchase an SSL certificate for *.example.com using my current IP address, or do I need to get one that is separate from the other sites on the VPS? Or even worse, do I need to get one that is separate from all HTTP traffic on the server? Keep in mind that none of the other sites needs SSL.
Thanks for any clarification on the topic.
Edit: Some sources for my worries:
http://symbiosis.bytemark.co.uk/docs/symbiosis.html#ch-ssl-hosting
Is it necessary to have dedicated IP Address to install SSL certificate?
There's no such thing as "SSL certificate". The term is misleading. X.509 certificates can be issued for different purposes (as defined by their Key Usage and Extended Key Usage "properties"), in particular for securing SSL/TLS sessions.
Certificates don't require anything in regards to sockets, addresses and ports as certificates are pure data.
When securing some connection with TLS, you usually use the certificate to authenticate the server (and sometimes the client). There's one server per IP/Port, so usually there's no problem for the server to choose what certificate to use.
HTTPS is the exception — several different domain names can refer to one IP and the client (usually a browser) connects to the same server for different domain names. The domain name is passed to the server in the request, which goes after TLS handshake.
Here's where the problem arises - the web server doesn't know which certificate to present. To address this a new extension has been added to TLS, named SNI (Server Name Indication). However, not all clients support it. So in general it's a good idea to have a dedicated server per IP/Port per domain. In other words, each domain, to which the client can connect using HTTPS, should have its own IP address (or different port, but that's not usual).
SSL certificates do not require a dedicated IP address. SSL certificates store a so called common name. Browser interpret this common name as the DNS name of the server they are talking to. If the common name does not match DNS name of the server that the browser is talking to, the browser will issue a warning.
You can get a so called wildcard certificate, that would be admissible for all hosts within a certain domain.
...following up on #Eugene's answer with more info about the compatibility issue...
According to this page from namecheap.com SNI does not work on:
Windows XP + any version Internet Explorer (6,7,8,9)
Internet Explorer 6 or earlier
Safari on Windows XP
BlackBerry Browser
Windows Mobile up to 6.5
Nokia Browser for Symbian at least on Series60
Opera Mobile for Symbian at least on Series60
Web site will still be available via HTTPS, but a certificate mismatch error will appear.
Thus, as we enter 2016 I would venture to stick my neck out there and say, "If you're building a modern website anyway (not supporting old browsers), and if the project is so small that it cannot afford a dedicated IP address, you'll probably be fine relying on SNI." Of course, there are thousands of experts who would disagree with this, but we're talking about being practical, not perfect.
The ssl certificate commmon name has to match the domain name. You don't have any requisite over the ip address, unless it's a limitation imposed by the certificate provider or the http server software.
Edit: looking into the web, it seems that the rumor has been spread because Apache's ssl plugin doesn't have (at least it didn't have in 2002) any mechanism to use different certificate based on the hostname. In such scenario you would have to run two different Apache web servers on the two different IP addresses.
Anyway in your configuration you shouldn't have any problem using only one IP because you don't have to use two different certificates (because you plan to use a wildcard certificate).
I would try anyway configuring the webserver with a self signed certificate before spending money for a second ip or certificate.
Edit 2: reference apache documentation:
http://httpd.apache.org/docs/2.2/vhosts/name-based.html
It seems like now (apache >= 2.2.12) it is supported
Related
I'm planning an API that will be used by a client on their internal office networks in multiple separate locations. Each location will have a separate instance installed.
They want it to be secure and running on HTTPS.
What I cant seem to understand how can a HTTPS certificate work when there is no externally facing fully qualified name. eg. MyApiServer.mycompany.com
Instead they will likely just be running it on a server/computer with just a hostname. ie. MyApiServer
The data being transferred is not necessarily sensitive but it places records in a sales system.
If HTTPS is not possible in this scenario whats an alternative method to secure the communication?
The server name has not to be "fully-qualified". For securing the call it will be enough to have the domain specified in URL equal to the domain name specified in certificate.
So your clients would call https://MyApiServer/endpoint in your LAN which should cause your service to provide server certificate where the subject would be MyApiServer.
I have deployed an OpenVPN server from GCP market Place and have attached a Domain name to it along with the SSL certificate. Currently, I am able to access the server through both
https://domain-name.com
https://x.x.x.x -(Server Static Ip)
I want the server to be accessible only through the hostname and not its Server IP as the latter URL gives an SSL security error as the SSL certificate is attached to the Domain name and not to the server IP.
Can anyone help me to restrict it or give some advice to solve it?
You could try to do it(prevent access by IP) but I advice you to not try to do it.
Theoretically it could be possible for your HTTP server to reset SSL connection when browser sends "wrong" SNI(Server Name Indication) in a handshake.
Thus you could prevent your browser displaying security alerts.
Instead your browser would show network error message.
I doubt you would like to trade one type of error to another one.
I suggest you to do nothing about such "error" because legitimate visitors will come to your site via domain name and will not see such security warning.
Also there is huge possibility that legitimate visitor (with paranoid mindset) will use browser with SNI feature disabled so your server will not be able to make difference between good and bad URLs.
PS: here are relevant questions and discussions at reddit and at ServerFault and another one
I have two websites running on IIS 7. Both require SSL. Ports for the websites are http:8080/https:443 and http:8087/https:443 respectively. I've created self signed certificate and put them into the Trusted Root. Contents of the both websites are the same. Here are my questions:
Do I have to make some changes to the hosts file as well? If so, what changes exactly, both on
server and clients
What do I have to type in the address bar in order to be able to open them? (Like 172.16.10.1/website1?) Do I have to specify the port numbers?
For http traffic, you can have many websites which can differ by IP or Port or Host Headers or a combination.
So in your case it is simple. For website1, you have site binding on port 8080, so the url becomes http://172.16.10.1:8080. Ditto for website2: http://172.16.10.1:8087 .
To make things simple, you can do a sitebinding on host header. So, bind the IP 172.16.10.1 with default port 80 to a host header say "www.website1.com" for the first website. Simlary for the other make the same combination bind to "www.website2.com". Now you don't need to specify port in the url. You can simply open both the websites by their respective names.
However, in case of https, it becomes a bit tricky. The certificates are installed on a per server basis. So, you have to specify different IP-Port combinations and host header binding won't work.
One option you have is to use a wildcard certificate which you can then secure-bind to each host-header.
The other option is to get a SAN Certificate (Subject Alternative Name Certificate). This will allow you to do a binding on different host headers with the same IP-port combination.
This excellent article on MSDN will help you understand it better: http://blogs.msdn.com/b/varunm/archive/2013/06/18/bind-multiple-sites-on-same-ip-address-and-port-in-ssl.aspx
Regarding the first part of your question:
You don't need to do anything with the hosts file. If you have a proper third-party certificate, it only needs to be registered on the server. The Intermediate and Trusted roots are already available on the clients. So nothing to be done on the client-side. You can open up "options" in IE and then check "certificates" under the "content" tab to see that a list of publishers is already there.
However, if you are using a self-cert, then the client-part is tricky. Because, the clients will keep on getting the "certificate is invalid" warning every time. One way out of this is to manually install the certificate on each client. Another way is to deploy the certificates to all clients using group policy.
I'm pretty new to the https world, so bear with me.
There are 2 web-servers involved:
Webserver1 has been in the organization a few years and is hosting/running multiple websites with https encryption (app1.ourcompany.com, app2.ourcompany.com, etc). It has a valid, signed certificate.
Webserver2 is a new server, for which I am responsible. I am tasked with setting up https and getting the certificate, etc. It has a web app running on it, but it does not have a domain name (only has an IP address)...which as I recently learned, is a requirement for a signed certificate.
What I'd like to know is this -- is it possible to set up a site on Webserver1 that points to the site I'm hosting on Webserver2 (ie SiteOnWebserver2.ourcompany.com) which also utilizes the Webserver1's signed/verified certificate?
Thanks for your time, SO gurus!
--Dan
A regular SSL certificate is valid for only a single domain name (such as app1.ourcompany.com). If this is the type of certificate currently being used then the existing SSL certificates will not work on your new server. If you did try this you would get an error in the browser saying that the site's domain name doesn't match the name in the SSL certificate.
The other option is to use a wildcard SSL certificate. These kinds of certificates are assigned to a certain parent domain (like ourcompany.com) and will work for all subdomains. This kind of certificate would work for app1.ourcompany.com, app2.ourcompany.com, as well as your SiteOnWebserver2.ourcompany.com.
Is it possible to have a FTP server using SSL on a application server that does not use SSL?
How would you setup an ASP.NET 2.0 to consume a SSL certificate?
This certianly sounds possible but is it advisable, is it good practice?
The choice on using SSL us made on a per connection level, usually determined by the IP port being used (i.e. will be set up between client and server before any application code involved).
The same service/content could be set up on multiple ports each with a different choice for SSL.
The certificate is per host name, but servers can generally support appearing under different names.
To use SSL with ASP.NET takes nothing special, it just works once the IIS web site is configured to support SSL (or to require it: when connections to port 80 for HTTP are redirected to the SSL port); this choice can be made on a per folder basis.
FTP is at the application layer, and SSL is lower, at the presentation layer. The SSL sessions are on a per connection basis. Take a look at the Wikipedia page. The SSL connection is established before anything happens with your application. Your FTP server probably isn't running inside your .NET application server, is it? You should be able to setup an SSH server listening for SCP connections separately. If it really does run from inside your app server, you should be able to listen on a separate port for the SSL connection.
Short of any of that, heres a good link for configuring SSL in IIS. You don't have to make the certificates mandatory. That way you can allow unsecured traffic and secure traffic if that fits in with your application model.
While protecting an application with SSL is always a good idea, it is technically not trivial.
Having a web application protected with SSL requires the webserver to be reachable on a new port (443/https instead of 80/http). This has to be configured "system-wide". Also, there may be only one certificate per IP-address, which is often a problem when hosting multiple domains on the same server.