diff options
author | Daniel Lowrey <rdlowrey@php.net> | 2014-03-05 10:50:23 -0500 |
---|---|---|
committer | Daniel Lowrey <rdlowrey@php.net> | 2014-03-05 10:03:33 -0700 |
commit | fad14e3180b17127496c95fe7f0a4b1ca4f36196 (patch) | |
tree | 563d06c3eb14ecece42b3fa0915a2288ae2ad5fa /ext/sqlite3/libsqlite/php-sqlite3-changes.patch | |
parent | 020e161966db1603f28df9baa33141ae59067243 (diff) | |
download | php-git-fad14e3180b17127496c95fe7f0a4b1ca4f36196.tar.gz |
Add encrypted server SNI support
- New "SNI_server_certs" context option maps host names to
appropriate certs should client handshakes advertise the
SNI extension:
$ctx = stream_context_create(["ssl" => [
"local_cert" => "/path/to/cert.pem",
"SNI_server_certs" => [
"domain1.com" => "/path/to/domain1.pem",
"*.domain2.com" => "/path/to/domain2.pem",
"domain3.com" => "/path/to/domain3.pem"
]
]]);
- Prefixing a "*." will utilize the matching cert if a client
requests the primary host name or any subdomain thereof. So
in the above example our "domain2.pem" will be used for both
requests to "domain2.com" -and- "subdomain.domain2.com"
- The "SNI_server_certs" ctx option has no effect for client
streams.
- SNI support is enabled by default as of 5.6 for both servers
and clients. Servers must specify the "SNI_server_certs" array
to actually use the SNI extension, though.
- If the `"SNI_enabled" => false` ctx option is also passed then
"SNI_server_certs" has no effect.
- While supporting SNI by itself is enough to successfully
negotiate the TLS handshake with many clients, servers MUST
still specify a "local_cert" ctx option or run the risk of
connection failures from clients that do not support the SNI
extension.
Diffstat (limited to 'ext/sqlite3/libsqlite/php-sqlite3-changes.patch')
0 files changed, 0 insertions, 0 deletions