Changeset 1899

Timestamp:

08/25/08 17:39:29 (3 months ago)

Author:

taher

Message:

Files:

cherokee/trunk/doc/Makefile.am

r1888	r1899
94	94	media/images/admin_handler_admin.png \
95	95	media/images/admin_handler_cgi.png \
96		media/images/admin_custom_error.png \
	96	media/images/admin_handler_custom_error.png \
97	97	media/images/admin_handler_dirlist_ex.png \
98	98	media/images/admin_handler_dirlist.png \

r1898	r1899
97	97	processed. Technically this might have been correct in the past. The
98	98	first thing that the server has to do is to connect with the other end
99		by using SSL/TLS, so at that point, before it receives the HTTP client
100		request, the crypto 'magic' already needs to have happened.
	99	by using SSL/TLS. The user entered host part of the URI must match the
	100	Common Name (CN) provided by the certificate. Since virtual hosts are in
	101	use, the CN of the first available certificate may or may not match
	102	the one specified in the early stages of TLS negotiation.
101	103
102	104	However, nothing is forever.. and that applies to SSL/TLS connections
…	…
105	107	certificates on the same IP address and port.
106	108
107		If SNI is supported by your SSL/TLS library, nothing of this needs to
108		happen because the host info can be put in the SSL handshake. Things
	109	Besides this there is a cleaner, more standard aproach called
	110	link:http://en.wikipedia.org/wiki/Server_Name_Indication[Server Name
	111	Indication] (SNI) that sends the name of the virtual host during the
	112	TLS negotiation.
	113
	114	If link:http://tools.ietf.org/html/rfc4366#section-3.1[SNI] is
	115	supported by your SSL/TLS library, the SSL layer does not need to be
	116	restarted. Since the host info can be put in the SSL handshake, things
109	117	will simply work as long as there is a web browser with SNI support at
110	118	the other side. Currently every modern web browser supports this, and