Hi, section 3.1 of RFC 3546 [0] states: > "HostName" contains the fully qualified DNS hostname of the server, > as understood by the client. The hostname is represented as a byte > string using UTF-8 encoding [UTF8], without a trailing dot.
However when using curl sends the hostname also when a trailing dot is included, e.g. $ curl --trace out.log 'https://www.google.de.' Then out.log includes: > == Info: SSLv3, TLS handshake, Client hello (1): > => Send SSL data, 512 bytes (0x200) > [...] > 00b0: 00 00 13 00 11 00 00 0e 77 77 77 2e 67 6f 6f 67 ........www.goog > 00c0: 6c 65 2e 64 65 2e 00 0b 00 04 03 00 01 02 00 0a le.de........... Notice the 0x2e ('.') before the zero termination. When using OpenSSL curl sets the SNI hostname as follows: > !SSL_set_tlsext_host_name(connssl->handle, conn->host.name)) I could not find documentation for this OpenSSL function but a look into the sources revealed no indication of handling for a trailing dot. Leaving this trailing dot makes Apache pretty unhappy. He angrily replies that the HTTP Hostname does not match the SNI HostName, which is technically correct [1]. I wonder who is at fault here. Should Apache handle this trailing dot situation more in a more liberal fashion or should either curl or OpenSSL handle this? Many other applications like Mozilla Firefox seem to have similar issues with SNI trailing dot situations. Best regards, Leon Winter [0] https://tools.ietf.org/html/rfc3546#section-3.1 [1] "Hostname www.xyz.de. provided via SNI and hostname www.xyz.de provided via HTTP are different" ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
