Ezidáig a címben szereplő témára nem igazán volt lehetőség. Az volt a gond, hogy a http protokoll fölött ment az ssl kapcsolat létrehozása, az ssl kapcsolat létrehozásakor viszont a TLS handshake nem közvetítette hogy melyik virtualhosthoz szeretne csatlakozni majdan a http. Kb így zajlik rendesen:
K: Kapcsolódás
Sz: Nyilvános kulcs küldése (host1.hu)
K: Fogadás után a nyilvános kulcs segítségével elkezdi küldeni a titkosított http folyamot.
K: (titkosított adat, host1.hu PK) HTTP Kérés
Sz: (titkosított adat, host1.hu PK) HTTP válasz
Az okosok viszont kitalálták, mi lenne ha a TLS handshake során (mint az SMTP során a hello-val), elküldené azt is a kliens hogy kihez szeretne csatlakozni (host2.hu u.a. mint host1.hu):
K: Kapcsolódás (host2.hu -t küldi, a többi kötelező adat mellett).
Sz: Megkapott adatok alapján host2.hu nyilvános kulcsának küldése.
K: (titkosított adat, host2.hu PK) HTTP Kérés
Sz: (titkosított adat, host2.hu PK) HTTP válasz
Ennek a technikának a neve Server Name Indication (SNI). Mindehhez a TLS 1.1-t kell támogatnia a kliensnek. Nézzük milyen kliensek támogatottak (kapcsolódó wiki alapján):
- Mozilla Firefox 2+
- Opera 8.0+ (TLS 1.1-t be kell kapcsolni)
- Internet Explorer 7+ (csak Vista!)
- Google Chrome (Vista, XP nem)
- Safari 3.2.1 Mac OS X 10.5.6
Szerver oldalon:
- Apache 2.2.12+ vagy mod_gnutls mod_ssl helyett. (OpenSSL esetén 0.9.8f+, j-től default)
- Utolsó lighttpd
Azok a kliensek akik nem támogatják továbbra is kapják az ssl_error_bad_cert_domain -t a többiek számára megoldódik az ilyen jellegű probléma.
Rossz hír az ubuntusok számára, hogy a Karmic ugyan az apache 2.2.12-t fogja szállítani, viszont OpenSSL-ből csak a 0.9.8f-et ami bizony a funkcionalitás backportja nélkül édes kevés…
Szóval megoldás már van csak meg kell várni míg elterjed!