Bug 57810 - Should apache ignore difference in trailing dot between SNI and HTTP requests?
Summary: Should apache ignore difference in trailing dot between SNI and HTTP requests?
Status: RESOLVED DUPLICATE of bug 58007
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.4.10
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-13 23:47 UTC by Jean-Luc Duprat
Modified: 2016-09-22 20:47 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Luc Duprat 2015-04-13 23:47:05 UTC

    
Comment 1 Jean-Luc Duprat 2015-04-14 00:11:09 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?
Comment 2 Fred Morris 2015-06-09 01:19:15 UTC
(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.
Comment 3 Yann Ylavic 2016-09-22 20:47:42 UTC

*** This bug has been marked as a duplicate of bug 58007 ***