On 2010-05-29 11:19 AM, K Post wrote: > Google's your friend here, but it's not a complicated process. It's > no different from requesting a single certificate, except you run > through the process three times. In our case, we requested one > certificate for each of one.domain.org, two.domain2.org and > three.domain3.org. Here's an example httpd.conf framework: > > NameVirtualHost *:443 > > <VirtualHost *:443> > DocumentRoot "[one root]" > ServerName one.domain1.org > SSLEngine on > SSLCertificateFile "[location]/one.domain1.org.crt" > SSLCertificateKeyFile "[location]/one.domain1.org.key" > ... > </VirtualHost>
<snip additional vhost defs on port 443> And as I pointed out - with a link to the docs in question - the official apache docs say you can't do that (on a single IP)... >From their FAQ: "Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts? Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server. It comes as rather a shock to learn that it is impossible. The reason is that the SSL protocol is a separate layer which encapsulates the HTTP protocol. So the SSL session is a separate transaction, that takes place before the HTTP session has begun. The server receives an SSL request on IP address X and port Y (usually 443). Since the SSL request does not contain any Host: field, the server has no way to decide which SSL virtual host to use. Usually, it will just use the first one it finds, which matches the port and IP address specified." So, either you are leaving something out, or these apache docs are just flat out wrong? There are two ways I know of to do this with a single cert - use either SNI or SAN certs: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI http://www.digicert.com/subject-alternative-name.htm > Saying the SSL Auth aspect over and over, including after I've said > we're using commercially issued certificates leads me to ask the > SAME QUESTION to you, what's the issue? There is no issue with commercial SSL certs, and I never said there was. I said there was an issue with SELF-SIGNED certs - and there IS. What I did do was make it sound like you couldn't do this with commercial Certs - of course you can, if you're willing to pay big(ger) bucks for SAN certs. However - I'm still very curious if you are really using separate, commercial certs on the standard port 443? If so, I would definitely like to know HOW, because everything I've read says it is impossible because of how SSL works. >> the only way to use name based virtual hosts on a single IP is with >> a single cert with multiple names - which means a self-signed cert >> - and it is this that causes you to lose the auth aspect to SSL (no >> way to prove you are who you claim to be). > And that's simply not true. You are correct that not *all* certs with multiple names must be self-signed - for some reason I was thinking in terms of 'free', or at least low cost. SSL certs from legitimate CA's that have lots of SANs cost big bucks. > I don't know where you're getting your information, but it's wrong. It is true for all *self-signed* certificates... there is no authentication/verification because that can only be done by a 3rd party - aka commercial - SSL cert from one of the CA's that is included in the average web browsers list of valid CA's... Oh - and I get my information where all good sys admins should get their information - from the back of the Cocoa Puffs cereal box. -- Best regards, Charles ------------------------------------------------------------------------------ _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
