Editing Transport Layer Security (section)

==Support for name-based virtual servers==
From the application protocol point of view, TLS belongs to a lower layer, although the TCP/IP model is too coarse to show it. This means that the TLS handshake is usually (except in the [[STARTTLS]] case) performed before the application protocol can start. In the [[Virtual domain|name-based virtual server]] feature being provided by the application layer, all co-hosted virtual servers share the same certificate because the server has to select and send a certificate immediately after the ClientHello message. This is a big problem in hosting environments because it means either sharing the same certificate among all customers or using a different IP address for each of them.

There are two known workarounds provided by [[X.509]]:
*If all virtual servers belong to the same domain, a [[wildcard certificate]] can be used.<ref>{{citation|url=https://ssl.comodo.com/wildcard-ssl-certificates.php|title=Wildcard SSL Certificate overview|work=ComodoCA Official Site |access-date=2015-07-02|url-status=live|archive-url=https://web.archive.org/web/20150623231035/https://ssl.comodo.com/wildcard-ssl-certificates.php|archive-date=2015-06-23}}</ref> Besides the loose host name selection that might be a problem or not, there is no common agreement about how to match wildcard certificates. Different rules are applied depending on the application protocol or software used.<ref>{{citation|url=https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf|title=Named-based SSL virtual hosts: how to tackle the problem|access-date=2012-05-17|url-status=live|archive-url=https://web.archive.org/web/20120803022659/https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf|archive-date=2012-08-03}}</ref>
*Add every virtual host name in the subjectAltName extension. The major problem being that the certificate needs to be reissued whenever a new virtual server is added.

To provide the server name, {{IETF RFC|4366}} Transport Layer Security (TLS) Extensions allow clients to include a [[Server Name Indication]] extension (SNI) in the extended ClientHello message. This extension hints to the server immediately which name the client wishes to connect to, so the server
can select the appropriate certificate to send to the clients.

{{IETF RFC|2817}} also documents a method to implement name-based virtual hosting by upgrading HTTP to TLS via an [[HTTP/1.1 Upgrade header]]. Normally this is to securely implement HTTP over TLS within the main "http" [[URI scheme]] (which avoids forking the URI space and reduces the number of used ports), however, few implementations currently support this.{{citation needed|date=February 2019}}