osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 61081] New: per-domain SNI (to override per-vhost SNI)


https://bz.apache.org/bugzilla/show_bug.cgi?id=61081

            Bug ID: 61081
           Summary: per-domain SNI (to override per-vhost SNI)
           Product: Apache httpd-2
           Version: 2.4.25
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: mod_ssl
          Assignee: bugs@xxxxxxxxxxxxxxxx
          Reporter: felipe@xxxxxxxxxxxxxxxx
  Target Milestone: ---

Currently there is no way to associate an SSL certificate with a specific FQDN
unless that FQDN is the only one on its virtual host. We have longstanding user
expectations of specific patterns of FQDN/vhost grouping, though, so we can’t
switch to that without a great deal of pain for ourselves and our customers.

We could use Include and mimic the behavior, but that would increase the load
time on machines that serve many thousands of vhosts.

The situation is aggravated by the fact that all other SSL-enabled services
that we deploy--Exim, Dovecot, ProFTPd, and our own application--make it simple
to associate an SSL certificate with a specific FQDN. So we’re having to
maintain two separate SSL datastores and trying not to have our end users worry
about the complexities of Apache’s model versus everyone else’s, but it doesn’t
always work.

Has there been any discussion of a simple FQDN-to-certificate index in the
config, as an alternative to vhost-based SNI?

e.g.:

-----------------
<NameBasedSNI>
    <Name example.com www.example.com>
        CertificateChainFile /path/to/certs/chain
        CertificateKeyFile /path/to/key
    </Name>
    <Name somealias.com www.somealias.com>
        CertificateChainFile /path/to/certs/chain
        CertificateKeyFile /path/to/key
    </Name>
    <Name mail.somealias.com>
        CertificateChainFile /path/to/certs/chain
        CertificateKeyFile /path/to/key
    </Name>
    <Name *.somealias.com>
        CertificateChainFile /path/to/certs/chain
        CertificateKeyFile /path/to/key
    </Name>
</NameBasedSNI>

… then there would just be the normal vhost configuration:

<VirtualHost 1.2.3.4:443>
    ServerName example.com
    ServerAlias www.example.com somealias.com www.somealias.com
    #...
</VirtualHost>
-----------------

This would allow applications like ours to treat Apache the same way as other
services: there could just be a single datastore of certificates, indexed by
domain, rather than having to maintain Apache’s as a “special exception”.

While this is just our own particular deployment, it’s also one that powers
probably millions of sites. It also seems to me that decoupling the SNI from
the delivered content would be a better design?

Thank you for your consideration!

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: bugs-help@xxxxxxxxxxxxxxxx