Apache stuurt het verkeerde certificate naar de client

[Cobalt]

Ik heb twee sub domeinnamen met ieder een eigen ssl certificate. Voor iedere domeinnaam heb ik een virtualhost. Nu is het probleem dat alleen de bovenste virtualhost het juiste ssl certificate naar de client stuurt. De onderste virtualhost stuurt het certificate van de bovenste virtualhost. Ik gebruik Apache 2.2.15 mod_ssl/2.2.15 OpenSSL/0.9.8m.

Wellicht is iemand eerder tegen dit probleem aangelopen en een oplossing weet.

code:

Listen 443

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

SSLPassPhraseDialog  builtin

SSLSessionCache "dbm:logs/ssl_scache"
SSLSessionCacheTimeout  300

SSLMutex default

NameVirtualHost *:443

<VirtualHost www1.example.com:443>

ServerName www1.example.com:443
ServerAlias www1.example.com
DocumentRoot "htdocs/www1"

SSLEngine on

SSLCertificateFile "conf/www1_example_com.crt"
SSLCertificateKeyFile "conf/server1.key"
SSLCertificateChainFile "conf/server-ca1.crt"

</VirtualHost> 

<VirtualHost www2.example.com:443>

ServerName www2.example.com:443
ServerAlias www2.example.com
DocumentRoot "htdocs/www2"

SSLEngine on

SSLCertificateFile "conf/www2_example_com.crt"
SSLCertificateKeyFile "conf/server2.key"
SSLCertificateChainFile "conf/server-ca2.crt"

</VirtualHost>

[ Voor 25% gewijzigd door Cobalt op 25-04-2010 14:25 ]

[raymonvdm]

Moet je niet voor elke SSL website een eigen ip adres hebben ?

[Cobalt]

Ik heb inmiddels de oplossing gevonden. http://httpd.apache.org/d...html#mass-virtual-hosting

code:

#  vhost.map
www1.example.com:443 "htdocs/www1"
www2.example.com:443 "htdocs/www2"

code:

# httpd.conf
UseCanonicalName on
RewriteEngine on

RewriteMap    lowercase    int:tolower
RewriteMap    vhost        txt:conf/vhost.map

RewriteCond   %{REQUEST_URI}  !^/cgi-bin/.*
RewriteCond   %{REQUEST_URI}  !^/icons/.*
RewriteCond   %{HTTP_HOST}  !^$
RewriteCond   ${lowercase:%{HTTP_HOST}|NONE}  ^(.+)$
RewriteCond   ${vhost:%1}  ^(/.*)$

RewriteRule   ^/(.*)$   %1/$1  [E=VHOST:${lowercase:%{HTTP_HOST}}]

[ Voor 4% gewijzigd door Cobalt op 25-04-2010 01:32 ]

[Shuriken]

raymondvdm heeft gelijk. Iedere ssl host moet een eigen ip adress hebben. Dus je "oplossing" gaat niet werken.

Om maar even te quoten uit de apache docs:

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.

[pinockio]

Wat ik me dan afvraag: hoe doen grote ISP's dat dan met tientallen ssl-sites op één server?

(Ik heb ook met dit probleem te kampen, en ken ook het verhaal dat het niet zou kunnen.)

[Cobalt]

Maar er is zoiets als SNI http://www.ietf.org/rfc/rfc3546.txt en http://www.ietf.org/rfc/rfc4366.txt hierbij wordt de fully qualified DNS hostname meegestuurd en sinds Apache 2.2.12 zou dit ook moeten werken.

Zonder de config die ik in mijn vorige post had geschreven werkt dit met Opera 10.51 en FireFox 3.6.

edit:

Na in IE8 ´Internet Options´ ´use TLS 1.0´ en ´use TLS 1.1` aangezet te hebben werkt het ook in Chrome 4.1 en IE8. Standaard staat in IE8 alleen SSL 3.0 en TLS 1.2 aangevinkt. Daardoor leek het dus niet te werken. Dus ik moet nog zorgen dat de server ook tls 1.2 ondersteund.

[ Voor 47% gewijzigd door Cobalt op 25-04-2010 01:34 ]

[DataGhost]

Inderdaad, met SNI zou het gewoon moeten werken. Hierbij moet je natuurlijk wel opletten dat je browser het ook ondersteunt, wat doorgaans geen probleem is tenzij je IE gebruikt op Windows XP.

Verder gebruik je dezelfde private key voor beide certificaten, dat kan natuurlijk nooit goed gaan. Ik denk dat je daar moet gaan zoeken. Kijk even in je (error) logs of je dingen met betrekking tot SSL kan vinden en kijk gelijk voor de zekerheid of je apache/openssl wel SNI ondersteunt.

Hiero.

If SNI is built in, then the error log will show "[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)".

[ Voor 21% gewijzigd door DataGhost op 25-04-2010 00:39 ]

[Verwijderd]

pinockio schreef op zaterdag 24 april 2010 @ 23:40:
Wat ik me dan afvraag: hoe doen grote ISP's dat dan met tientallen ssl-sites op één server?

Tientallen IP adressen op dezelfde server configureren. Simpel zat.

Shuriken schreef op zaterdag 24 april 2010 @ 23:37:
raymondvdm heeft gelijk. Iedere ssl host moet een eigen ip adress hebben. Dus je "oplossing" gaat niet werken.

Om maar even te quoten uit de apache docs:

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.

Het jammere is dat ze vergeten te melden dat het wel prima werkt als je bijvoorbeeld een wildcard certificaat hebt die je inzet voor meerdere virtual hosts. Dat werkt wel perfect.

[ Voor 85% gewijzigd door Verwijderd op 25-04-2010 00:50 ]

[pinockio]

Ja, en IP-adressen zijn niet duur en schaars?
(IPV6, jawel, maar dat gebruikt nog niemand. Nu ja, bijna niemand.)

[alt-92]

pinockio schreef op zondag 25 april 2010 @ 11:17:
Ja, en IP-adressen zijn niet duur en schaars?
(IPV6, jawel, maar dat gebruikt nog niemand. Nu ja, bijna niemand.)

offtopic:
Er liggen hele ipv4 subnets op de plank die ooit toegekend zijn aan bedrijven/instanties die daar nog nooit gebruik van gemaakt hebben of gaan doen. Sommigen daarvan worden inmiddels al weer teruggeclaimed en heringezet. Die schaarste is niet zo groot als wel eens beweerd wordt.

[Verwijderd]

pinockio schreef op zondag 25 april 2010 @ 11:17:
Ja, en IP-adressen zijn niet duur en schaars?

IPv4 adressen zijn bij ons absoluut niet duur, omdat wij effectief een /17, /18 en /19 tot onze beschikking hebben, dus tienduizenden adressen. Daarbij is het nodig hebben van een IP voor een SSL certificaat één van de weinige redenen om een dedicated IP adres te gebruiken. Ik verwacht dat wij het langer kunnen uitzingen dan menig andere zakelijke ISP. Kortom, ze zijn alleen duur als je hosting provider krap zit.

(IPV6, jawel, maar dat gebruikt nog niemand. Nu ja, bijna niemand.)

Overigens hebben wij IPv6 al uitgerold op kleine schaal, en op grote schaal gebeurt dat zeer binnenkort. Totdat elke ISP IPv6 aanbiedt, en elke website via IPv6 beschikbaar is, is dat echter geen oplossing voor dit specifieke probleem.

alt-92 schreef op zondag 25 april 2010 @ 11:26:
Er liggen hele ipv4 subnets op de plank die ooit toegekend zijn aan bedrijven/instanties die daar nog nooit gebruik van gemaakt hebben of gaan doen. Sommigen daarvan worden inmiddels al weer teruggeclaimed en heringezet. Die schaarste is niet zo groot als wel eens beweerd wordt.

Punt is wel dat dat meestal in Noord-Amerika is gebeurd, en dat die nog weinig haast schijnen te hebben met IPv6.