| Summary: | Should apache ignore difference in trailing dot between SNI and HTTP requests? | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Jean-Luc Duprat <jld> |
| Component: | Core | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 2.4.10 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
|
Description
Jean-Luc Duprat
2015-04-13 23:47:05 UTC
I am trying to access a URL via https through both the regular URL and one that ends with a trailing dot: example.com example.com. The reason the second case matters is URLs reported by DNS-SD have the trailing dot appended. See http://www.dns-sd.org/trailingdotsindomainnames.html I have a certificate that contains the the subject's common name as CN=example.com and the following SANs: X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com, DNS:example.com., DNS:www.example.com. I am using Name-based Virtual Host Support, with the virtual host section looking like so: <VirtualHost *:443> Options None ServerName example.com ServerAlias www.example.com ServerAlias example.com. ServerAlias www.example.com. [...] </VirtualHost> CSP and HSTS are disabled. When trying to connect to example.com. I get the following error: [ssl:error] [pid 22158] AH02032: Hostname example.com. provided via SNI and hostname example.com provided via HTTP are different All desktop browsers I've tried (Firefox, Chrome, Safari) drop the trailing dot on the the name for the HTTP request. Since the URL is generated by service discovery I have no control over it. The clients also behave consistently. The only way to get this to work would be for apache to allow for this minor difference between the SNI and HTTP hostnames. Would such a patch be considered for inclusion? (In reply to Jean-Luc Duprat from comment #1) > [...] > [ssl:error] [pid 22158] AH02032: Hostname example.com. provided via SNI and > hostname example.com provided via HTTP are different > [...] > Since the URL is generated by service discovery I have no control over it. > The clients also behave consistently. The only way to get this to work > would be for apache to allow for this minor difference between the SNI and > HTTP hostnames. I believe that www.example.com and www.example.com. are equivalent. Apache already treats vhosts this way, it SHOULD (in the jargon of RFCs) ignore trailing dots for FQDN equivalence. My research indicates (most, in fact) clients are in error, because the SNI specification at least (not HTTP unfortunately) unequivocally calls for the trailing dot to be dropped. See bug 58007. |