SSL Zertifikate und virtual Hosts

Im Büro entwickelte sich heute eine Diskussion über die Installation von SSL-Zertifikaten auf einem Webserver, der virtual Hosts verwendet. Meine Aussage dazu war, dass für jedes SSL-Zertifikat eine eigene IP-Adresse bzw. ein separater Port benötigt wird, das wusste ich. Nur leider konnte ich nicht schlüssig erklären, warum dies so ist. Nach ein wenig Recherche kann ich das jetzt nachholen.

Seitdem Browser den Hostnamen im HTTP-Header mitsenden können mehrere virtuelle  Webserver mit jeweils eigenem Domainnamen über eine einzige IP-Adresse bedient werden. Die Webserver Software, wie z.B. Apache unter Unix/Linux oder IIS unter Windows, ordnen hierbei die Seitenaufrufe der Browser über den mitgelieferten Hostnamen dem jeweiligen virtuellen Host zu.

Beim Aufbau einer HTTPS-Verbindung zwischen Browser und Webserver erfolgt zuerst der SSL-Handshake, bei dem sich Browser und Webserver über die Verschlüsselung der Verbindung einigen. Erst danach sendet der Browser den Hostnamen über die dann gesicherte Verbindung. Etwas deutlicher:

• User gibt URL in Browser ein https://domainname.tld
• domainname.tld wird in eine IP-Adresse aufgelöst und der Browser stellt Verbindung zu dieser IP-Adresse und Port 443 her
• Es erfolgt der SSL-Handshake. Der Server verwendet hierzu das Zertifikat, das für die Komination aus IP-Adresse und Port definiert wurde
• Der Browser übergibt über die verschlüsselte Verbindung den Hostnamen, der Webserver ordnet den Hostnamen einem virtuellen Host zu

Wenn also mehrere SSL-Zertifikate von einem Webserver verwendet werden sollen, gibt es nur folgende Abhilfemöglichkeiten:

• Für jedes Zertifikat muss im Webserver eine separate Kombination aus IP-Adresse und Port verwendet werden.
• Verwendung von sogenannten Wildcard-Zertifikaten (z.B. *.domainname.tld) – Nachteil: gilt nur für Subdomains (im Beispiel nur für Subdomains der Domain domainname.tld)
• Mit der Spezifikation von TLS Version 1.2 soll Server Name Identification (SNI) ermöglicht werden. Die Spezifikation ist jedoch noch in der Planung

Quellen: unter anderem http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure

Verwandte Artikel

• Thawte stellt kostenlosen Dienst “Thawte Personal E-mail Certificates and Web of Trust” ein (0)
• Exchange 2010: Zertifikatsanforderung generieren mit New-ExchangeCertificate (1)
• Exchange 2010: Zertifikat importieren und aktivieren (0)