Subject: virtual hosting and ssl

From: Michael Grant <[email-masked]>
Date: Mon, 6 May 2002 16:30:23 +0200 (MEST)

I've been playing around with the apache and our virtual hosts.  I am
well aware that I could have different certs for each IP address if I
were using IP based virtual hosting but I'm using name based virtual
hosts.

I host a variety of domains which are not at all subdomains of my main 
domain.  What I would like to do is have one cert for all my domains.

I sort of have it working with name based virtual hosting, but in some
cases, I get the following warning in Internet Explorer:

"The name on the security certificate does not match the name of the
site."

It appears that some web browsers, Netscape for example, support a *
as a wild card in the CN.  For example CN=*grant.org.  There's also
some talk on Microsoft's web site of some versions of IE supporting
this too.  Though, apparently not 5.01 running on windows 98 or me. 

The cases seem to be:

1) I generate a cert with CN=grant.org.  No complaints when I connect
to https://grant.org.  Both Netscape & IE complain if I connect to
www.grant.org or any other of my domains.

2) I generate a cert with CN=*grant.org.  No complaints when I connect 
to https://www.grant.org or https://grant.org from Netscape.  IE
complains that the name is incorrect.  I can import the self-signed
cert into both IE's and Netscape's trusted root ca list.

3) I generate a cert with CN=*.  No complaints when I connect to any
of my domains with Netscape, however IE complains that the name is
incorrect.  I can import the self-signed cert into Netscape's trusted
root ca list but NOT IE's.

Can someone tell me if there is a right way to generate a cert that
works with more than one site with the various different browsers out
there? 

Michael Grant
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Owen Boyle <[email-masked]>
Date: Mon, 06 May 2002 16:53:34 +0200

> "The name on the security certificate does not match the name of the

Indeed. There is a fundamental problem with using NBVHs with SSL - it
don't work, see:
 
	http://www.modssl.org/docs/2.8/ssl_faq.html#ToC47
	http://marc.theaimsgroup.com/?l=apache-modssl&m=98559369910170&w=2

YOu can get it "sort of" working if you don't mind that all your VHs
share the same certificate. What happens is:

- an https request for a session comes in on port 443 - that's all
apache gets. Since the session hasn't been established yet, there is no
Host header.
- with no host header, apache has no idea which VH to use (what can it
use to match the ServerName?).
- since apache doesn't know which VH to use, it can't decide which
certificate to send.
- to get out of the loop, apache just selects the first VH on port 443
and send its certificate.
- probably the cert is for a different site so the browser pops a
warning. If the user clicks OK, the browser establishes a session-key,
encrypts its request (this time containing a host header) and sends it
off.
- the server decrypts the request and now finds the Host header. 
- Now apache can decide which VH to use and so serves the correct
content.

But you can't get by the warning because the default cert doesn't match
the requested site.

The only possible non-general "solution" is if the sites are like
www1.acme.com, www2.acme.com and so on. Then you can get a wildcard cert
which is valid for *.acme.com. Even then though, the behaviour is
browser dependent. Before you ask, there is no such thing as a
super-wildcard *.*.com cert...

Rgds,

Owen Boyle.

---

From: "Steve Leach" <[email-masked]>
Date: Mon, 6 May 2002 16:10:37 +0100

Owen,

I just followed this thread - thanks for that condensed 'how it works' for
certificates - I picked up two things I did not know, and as they say
knowledge is power :)

I am wondering at the last statement as to whether the limitation lies in
the ability to produce a certificate that could verify all hosted domains,
or whether Apache (or indeed any HTTPS server) could  work with such a
beast?

Best Regards,

Steve Leach
Network Manager
Mi-Int Limited
Eaglescliffe Logistics Centre
Durham Lane
Egglescliffe
URL: http://www.askalix.com
TEL: 01642 356205
e-mail: [email-masked]

---

From: Andrew Lietzow <[email-masked]>
Date: Mon, 06 May 2002 11:38:44 -0500

While we're on this topic...
Owen Boyle wrote .... on 01.03.26

"This question comes up so often it ought to be in the .sig of the list... ", and
this ends with "Use different port numbers for different SSL hosts".

I personally don't know what the .sig would mean, but the last comment
intriques me.

By using different IP ports ... might something like the following work?
For example:

<VirtualHost 192.168.1.1>
ServerAdmin [email-masked]
ServerName www.acme.com
DocumentRoot /var/www/www.acme.com
</VirtualHost>

<VirtualHost 192.168.1.1:443>
ServerAdmin [email-masked]
ServerName secure.acme.com
DocumentRoot /var/www/secure.acme.com
SSLCertificateFile /path/to/original/cert
SSLCertificateKeyFile /path/to/original/key
</VirtualHost>

<VirtualHost 192.168.1.1>
ServerAdmin [email-masked]
ServerName www.anotherdomain.com
DocumentRoot /var/www/www.anotherdomain.com
</VirtualHost>

<VirtualHost 192.168.1.1:745> (or other unassigned IP Port)
ServerAdmin [email-masked]
ServerName secure.anotherdomain.com
DocumentRoot /var/www/secure.acme.com
SSLCertificateFile /path/to/second/cert
SSLCertificateKeyFile /path/to/second/key

</VirtualHost>

My question is when running Apache 2.0.X, can one
Listen 443
AND
Listen 745
and obtain the intended result?  I am close to trying this but thought
maybe someone more experienced has already done so and knows
what results I could anticipate.

Andrew Lietzow
The ACL Group, Inc.
______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [email-masked] Automated List Manager [email-masked]

---

From: Cliff Woolley <[email-masked]>
Date: Mon, 6 May 2002 12:50:47 -0400 (EDT)

On Mon, 6 May 2002, Andrew Lietzow wrote:

>...

Change those to 192.168.1.1:80, and you're fine.  Of course you realize
that that means your second ssl vhost will have to be accessed as
https://secure.anotherdomain.com:745/ , right?

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   [email-masked]
   Charlottesville, VA

---

From: Owen Boyle <[email-masked]>
Date: Tue, 07 May 2002 10:31:34 +0200

> or whether Apache (or indeed any HTTPS server) could  work with such a

As I understand it, the trouble is that there are two aspects to SSL:
encryption and authentication. If it was only about encryption, you
wouldn't have to tie your certificates to the different sites - so you
could just serve up a general server-certificate which would contain
your public key (which is, after all, just a big long number). The
client would use this to send you a session-key and you'd have
established the secure channel. Then you could exchange the HTTPS
packets in confidence and use the "Host:" fields therein to select
virtualhosts. Indeed, this is what happens when people naively set up
NBVHs on port 443 - the server just uses the certificate from the first
VH for any request it receives.

However, we've forgotten about authentication. If you really want a
secure connection, it is no use just encrypting the datastream; you have
to be sure that the packets are really going to the destination you
want. If you send your credit card details to www.amazon.com how can you
be sure that the server at the other end really does belong to Amazon
Books Inc. and is not a fake server with a copy of their site and that
some crook has not hijacked a router somewhere along the way? The answer
is that when you get the cert from amazon.com it contains not only the
public key but also their site name. Their cert has also been signed by
Verisign or somesuch and so can be verified. 

Now you can't just make a self-signed cert which says you're amazon.com
because "the browser does not recognise the authority which signed this
certificate". 

Really, these "problems" are all client-side. The server is only
interested in setting up a secure channel so will use any cert that
seems appropriate. The trouble only starts when the browser starts
checking out the cert and finds that it can't verify it because the
signing authority is unknown or that it looks fishy because the
site-name on the request doesn't match the site-name in the cert. This
is really just the browser manufacturers protecting you from being
conned and themselves from being sued.

Rgds,

Owen Boyle.

---

From: "R. DuFresne" <[email-masked]>
Date: Tue, 7 May 2002 04:53:12 -0400 (EDT)

The ony other issue one really has that  Owen has not covered, is trsting
the issuing CA to do things correctly. There's an incident not too long in
the past whence a site not Microsoft affilliated obtained a fake microsoft
cert.  Of course there are also man in the middle exploits, even with ssl
and ssh, though they tend to be rare and hard to impliment, for the most
part.  With wireless being the new toy in use by many, there are issues of
information leakage too, but these are different topics in and of
themselves...

Cool writeup Owen, we;re saving it here to send out as common requests
come in.

Thanks,

Ron DuFresne

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart

testing, only testing, and damn good at it too!