Apache SSL Named Virtual Host

A virtuális hosztok használata webes környezetben egy elterjeden használt megoldás, annak érdekében, hogy egy IP címmel több, eltérő domain név alatt üzemelő weboldal is kiszolgálható legyen. Ennek használatakor a web szerver a HTTP kérésben utazó HOST mező alapján azonosítja azt a virtuális kiszolgálót, amelyet használnia kell a kérés feldolgozához.

Ennek kapcsán még valamikor régebben foglalkoztatott a kérdés, hogy vajon lehetne-e ilyen virtuális hosztokat (named virtual host) csinálni HTTPS-t használó oldalakanál is, azonban akkor még sajnos nem volt rá a válasz.

Ennek az az egyszerű oka, hogy HTTPS esetében a TCP kapcsolat elején megtörténik az SSL handshake, aminek során a titkosítás érdekében egy kulcs csere is lezajlik, majd csak ezt követően indul el a HTTP kommunikáció a web szerverrel. Sajnos ezen kulcs csere során a szervernek még nincs tudomása arról, hogy a későbbiek során milyen HTTP kérést kell kiszolgálnia, így azt sem tudhatja, hogy milyen kulcsot (egész pontosan tanusítványt és privátkulcsot) válasszon a handshake során.

Mindezeknek egyenes következménye, hogy még ha a kiszolgálónak meg is adunk több tanusítványt, az mégse fogja tudni kiválasztani a megfelelőt, vagyis minden esetben ugyanazt küldi majd el a kliensnek, miközben a tanusítványok domain névhez kötöttek (persze léteznek wildcard tanusítványok is, melyek bizonyos domain név tartományra érvényesek, azonban azok drágák --- ilyen lenne például a *.halacs.hu domainre szóló certificate).

Erre a problémára sokáig az egyetlen megoldás volt, hogy minden HTTPS hoszthoz külön IP címet rendeltek. Ez azonban drága (legalábbis IPv4 alatt biztosan; sőt egyes esetekben nem is biztos, hogy kivitelezhető), így a legtöbb hoszting szolgáltató ezt nem is tette lehetővé.

Ez volt eddig.

A problémára a megoldást az SSL protokoll egy kiterjesztése, az SNI azaz Server Name Indication (RFC4366) jelentette, mely lehetővé teszi, hogy az első üzenetben átadásra kerülhessen a hoszt név, aminek a segítségével a web szerver már képes kiválasztani a megfelelő tanusítványt és privátkulcsot a kapcsolat felépítéséhez.

Szerencsére a Debian Squeeze óta az Apache webszerver és az OpenSSL támogatja az SNI-t, így rendelkezik azzal a képességgel is, hogy egy IP címen több HTTPS virtual hoszt működjön.

Az egyetlen probléma ezzel csak a visszafelé kompatibilitás, vagyis, hogy például Windows XP és Internet Explorer 7 páros alatt (de említhetném az Android 2.2.2-t is) az SNI nem támogatott, aminek következtében a már jól ismert problémával találjuk szembe magunkat.

A várható kompatibilitási problémák miatt, az SSLStrictSNIVHostCheck Apache beállítás segítségével meghatározhatjuk, hogy az SNI-t nem támogató kliensek esetében is elfogadott legyen-e a kapcsolódás.