On 22.12.2010 11:05, Tony Mountifield wrote:

In article 133721.39495.qm-j4IRtXk+ZdTuQS8rMknbopOW+3bF1jUfVpNB7YpNyf8@public.gmane.org, S Mathias smathias1972@yahoo.com wrote:

...

http://help.godaddy.com/article/1054

"# Set up SSL protection on your website."

is it an inescapable requirement to have a dedicated [not fix] ip address, when i want to use ssl on my domain?

Not exactly. An SSL certificate is not tied to an IP address, but to a hostname. If you only have a single SSL site on the server, it doesn't matter what the IP address is, or even whether it is a dynamic address registered with a dunamic DNS provider. It will still work.

The thing you CAN'T do is to have name-based virtual hosting with multiple domains on a single IP address, with more than one of them using SSL. Name-based virtual hosting relies on the HTTP Host: header to identify which virtual host is being accessed. But under SSL, the headers are not sent until the encrypted SSL channel has been set up. So the only way the server can know which certificate to use is by the IP address on which the request is recieved. So multiple SSL sites on a single box MUST each have their own IP address.

Very good explanation ! I just want to add that there is such a thing named "Server Name Indication". With that the Virtual Host Name is sent at SSL Handshake time, so it is possible to use name based Virtual Hosts (No need for additional IP adresses). It needs Server and Client support, though. Apache in CentOS 5 does not support it as far as I know.

http://en.wikipedia.org/wiki/Server_Name_Indication

The question was:

On Tue, 2010-12-21 at 22:53 -0800, S Mathias wrote:

...

http://help.godaddy.com/article/1054 "# Set up SSL protection on your website." is it an inescapable requirement to have a dedicated [not fix] ip address, when i want to use ssl on my domain?

and one reply asseted:

On Wed, 22 Dec 2010, Adam Tauno Williams wrote:

Yes.

Reverse DNS has to be working.

ehh? so what? It is perfectly possible to update PTR records dynamically, just as with CNAMEs or A records

A CSR countersign by a CA is from information totally ignorant of the actual IP's in play [see the req_distinguished_name stanza of such requests as to the information needed, below] -- indeed, such IPs need not even be allocated, nor the host live, before a key file is generated, a CSR submitted to a CA and countersigned, and a PEM returned by the CA to the requestor

Managing DNS, and placement of a PEM, key and chain into the hosts providing a SSL accessible website (mailserver, etc) are totally disjunct from the specific IP's a host is at for a given time

[ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = US countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Ohio localityName = Locality Name (eg, city) localityName_default = Columbus 0.organizationName = Organization Name (eg, company) 0.organizationName_default = 781 Resolution, LLC organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, your name or your server's hostname) commonName_max = 64 emailAddress = Email Address emailAddress_max = 63 emailAddress_default = domains@781resolution.com

The 'commonName' field here is usually the FQDN, and may be an A record or a CNAME; validations are optionally done by a remote host querying the PTR record values to make sure there is a name match in the array returned [a PTR is usually unique and one to an IP, but I am not specifically aware of a formal RFC requirement of only one PTR record per IP, having looked again for such writing some code on DNS content validation for an interface that builds zone files in the last few months]

-- Russ herrold

On 22/12/10 11:52 PM, Nico Kadel-Garcia wrote:

It's the easiest way to do it. If you allow someone else to hold your SSL keys, they can do interesting things to act as your front end to

Where in the original post did it mention using a system that's not under their control? The question was about a static IP address, not the system the keys and certificates would be installed on.

register your hostname associated with a registered key, but that gets tricky. And there are other fancy tricks, but they get weird and painful.

Yes, it also depends on how much effort they're willing to go to and whether or not they care if a visitor notices.

But let's be honest. Most SSL encryption is not done to authenticate a website as a signed, registered websites. Most of us at penny-wise workplaces have to hit "Yes, I accept this unsigned key" pop-ups all the time. SSL is often useful merely to encrypt the traffic end-to-end while clients accept such unsigned or incorrectly registered keys without concern. For that kind of use, dodging and weaving unregistered IP addresses are common place.

That's what my self-signed site is for, but then I live in a country that is still debating mandatory Internet censorship.

Most people wanting SSL on their website see it as a business requirement and most of those sites are running on shared or VPS hosting.

Regards, Ben

Dne 23.12.2010 1:08, Les Mikesell napsal(a):

The issue is that the server needs to know the hostname given to the browser to find the matching certificate, and the only way to do that and stay on the standard port 443 with the apache version on centos is to bind each virtual host to a different IP address. Per the apache ssl faq at http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2, 2.2.12 or later supports SNI where the browser passes the hostname before the ssl session starts.

Guys, Of course that it's possible to host multi-site on ONE ip. As Les has said, it's about SNI enabled web clients and servers. Not all clients support SNI. As to Apache, there's no need to go with 2.2.12. SNI is very easy to support with both Centos 4 and Centos 5. There's module mod_gnutls packed for Centos in one of my repo. Used in production for a few years now.

http://fs12.vsb.cz/hrb33/el5/hrb-tls/stable/i386/repoview/ http://fs12.vsb.cz/hrb33/el5/hrb-tls/stable/x86_64/repoview/ http://fs12.vsb.cz/hrb33/el4/hrb-tls/stable/i386/repoview/ http://fs12.vsb.cz/hrb33/el4/hrb-tls/stable/x86_64/repoview/

Regards, David Hrbáč

On Thursday, December 23, 2010 07:10:36 am Ross Walker wrote:

As long as the forward DNS resolves to the common name the cert will be accepted and you can have multiple host names resolve to the same IP.

There's also the possibility that you can use multiple subdomains. Instead of

https://foo.com https://bar.com

You might use

https://foo.yourdomain.com https://bar.yourdomain.com

This involves the use of a wildcard subdomain certificate, which any/all of the major Certificate vendors provide. I've been doing this for hundreds of customers by domain name and it works with basically all clients all the time. (I've had ZERO issues from this) It's a tad more expensive than a "normal" SSL certificate, but it's dramatically cheaper than buying a separate SSL certificate for each client, and reduces certificate administration to a SINGLE httpd.conf entry. (if your application is structured thusly)