Summary: | per-domain SNI (to override per-vhost SNI) | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | felipe |
Component: | mod_ssl | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | NEW --- | ||
Severity: | enhancement | ||
Priority: | P2 | ||
Version: | 2.4.25 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
felipe
2017-05-09 14:32:36 UTC
(In reply to felipe from comment #0) > 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. Is this true? The code looks like it scans ServerAlias entries (ssl_util_vhost_matches) to use the SNI name to map to an SSL vhost config. (In reply to Eric Covener from comment #1) > (In reply to felipe from comment #0) > > 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. > > Is this true? The code looks like it scans ServerAlias entries > (ssl_util_vhost_matches) to use the SNI name to map to an SSL vhost config. This associates the certificate with the vhost, not with an individual FQDN. So all FQDNs on the vhost have to share a single certificate. What I’m proposing is a means to decouple the vhost logic from SNI matching: if there’s a matching NameBasedSNI entry for the cert/key, then use that; otherwise, do business as usual. (In reply to felipe from comment #2) > (In reply to Eric Covener from comment #1) > > (In reply to felipe from comment #0) > > > 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. > > > > Is this true? The code looks like it scans ServerAlias entries > > (ssl_util_vhost_matches) to use the SNI name to map to an SSL vhost config. > > This associates the certificate with the vhost, not with an individual FQDN. > So all FQDNs on the vhost have to share a single certificate. > > What I’m proposing is a means to decouple the vhost logic from SNI matching: > if there’s a matching NameBasedSNI entry for the cert/key, then use that; > otherwise, do business as usual. I see, I think that is reasonable, but I would suggest avoiding new container/section construct for it. In a proprietary SSL plugin, that uses named certificates rather than paths, it was just repeated "SSLSNIMap hostname label". The interaction with current ssl-vhost-config selection by SNI would need to be sorted out too. Documenting the status quo would be a good start! (In reply to Eric Covener from comment #3) > > I see, I think that is reasonable, but I would suggest avoiding new > container/section construct for it. In a proprietary SSL plugin, that uses > named certificates rather than paths, it was just repeated > "SSLSNIMap hostname label". However it seems most reasonably implemented in the config would be fine with me. :) It seems like right before ssl_find_vhost() is where this would happen? > > The interaction with current ssl-vhost-config selection by SNI would need to > be sorted out too. Documenting the status quo would be a good start! I think just having a fallback would suffice? Incidentally, lighttpd’s SNI functionality is per-domain, not per-vhost: $SERVER["socket"] == ":443" { ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/ssl/the-default-domain.com.pem" $HTTP["host"] == "www.example.org" { ssl.pemfile = "/etc/lighttpd/www.example.org.pem" } $HTTP["host"] == "mail.example.org" { ssl.pemfile = "/etc/lighttpd/mail.example.org.pem" } } I think a directive similar to IBM's SSLSNIMap would be ideal; I'm unsure whether it'd be preferable to have separate mapping directives for the certificate, key and chain files, or if you'd want one directive with multiple arguments. The latter would get extremely lengthy, so I'm leaning towards the former. |