Opened 5 years ago

Last modified 5 years ago

#15 new enhancement

SSL configuration independent from virtual hosts, automatic certificate selection

Reported by: https://id.mayfirst.org/dkg Owned by: https://id.mayfirst.org/dkg
Priority: minor Component: code
Version: Keywords: certificates sni config vhosts
Cc:

Description

imported from mantis, joachim breitner wrote:

With one certificate covering all hosted domains (using wildcard domains and/or subject alternative name entries), it is possible to

  • have all SSL configuration in one place.
  • define one virtual host once and serve both HTTP and HTTPs

This works by having only one virtual host with ssl configuration. This virtual host is not actually used (and the ServerName? may be anything): Before the SSL handshake, apache looks only at that virtual host, sends the certificate, then recieves the request with the Host: header and re-selects the right virtual host.

It is not possible to obtain the same level of convenience with multiple certificates and SNI: Now I do need to configure SSL for each virtual host idependently. Worse, I need to duplicate every virtual host configuration, because the same configuration can no longer server both SSL and non-SSL.

Worse: If I have larger number of domains that I want to handle in a single virtual host (e.g. using mod_rewirte magic), I still need to duplicate the configuration if I need to show separate certificates for different domains.

It would be nice if I could, in my original setup with the single „dummy“ SSL virtual host, multiple certificates (or even a whole directory), and have apache select the right certificiate by matching the SNI data against the CN and SAN entries of the ceritificate, showing the client the first one that matches.

After the SSL handshake, virtual host selection would work as before, i.e. based on the ServerName? attribute.

This would entangle virtual host configuration and SSL configuration, which I think is a good thing in many use cases.

A suggested change would be to have, in addition to GnuTLSCertificateFile, a GnuTLSSNICertificateFile directive that can be used multiple times. mod_ssl will then first go through all certificates mentioned in GnuTLSSNICertificateFile and use the first one with a matching name. If none matches, GnuTLSCertificateFile is used.

It seems to me that this would be a non-intrusive local change.

(This is also filed against mod_ssl at https://issues.apache.org/bugzilla/show_bug.cgi?id=54385 [] as I would be fine with either implementation providing this feature.)

Change History (4)

comment:1 Changed 5 years ago by https://id.mayfirst.org/dkg

on 2013-02-01, dkg wrote:

Hi Joachim--

this is an interesting suggestion, but i think it conflates a bunch of different configuration settings that maybe shouldn't be conflated. Maybe we can simplify the suggestion for clarity?

It seems like there are several different TLS configuration options that an admin might care about, including (for example) GnuTLSPriorities (or SSLCipherSuite for mod_ssl), GnuTLSClientVerify, etc. I think most of these are covered by ticket:14 here, which is resolved in my master branch:

Then we come to your idea of a pool of certificates and their associated secret keys, and their interaction with SNI and apache's vhost selection mechanism, which i think is distinct.

Would you be OK with re-scoping this ticket to just cover certificate and vhost selection?

There are a number of parts here, none necessarily insurmountable:

  1. we need to track which secret key goes with which certificate
  2. we need to track which intermediate certificate authority certs should be served with each certificate to avoid creating a "trans-valid" situation (this is currently handled in the normal case by having the full chain (EE cert + intermediate CAs) in GnuTLSCertificateFile.
  3. we'd need to specify how an admin would configure this in a simple/clean way that would result in intuitive and repeatable behavior.

What if the directive was GnuTLSSNIPKIPool and it took two arguments: the secret key and the EE cert + chained CAs? Then it could be declared any number of times. What order should they be scanned in when a new SNI request comes in?

does this directive need to be in vhost configs? What if GnuTLSSNIPKIPool was only acceptable in the "server config" (i.e. global) context? Would you ever want to have the ability for a given vhost to opt out of the pool? (hmm, what would that opt-out mean?)

Sorry for all the questions, i just want to make sure that we scope out the feature in a reasonable way, and that we're talking about the same thing.

Cheers!

comment:2 Changed 5 years ago by https://id.mayfirst.org/dkg

joachim followed up with:

Thanks for considering the feature. I don’t care too much about how it is configured; it is the result that counts :-)

Would you be OK with re-scoping this ticket to just cover certificate and vhost selection?

Sure. Although I’m not sure that vhost selection is the right word – isn’t that done by apache _after_ mod_gnutls has established the connection?

What order should they be scanned in when a new SNI request comes in?

Being more a declarative guy, I’d say that the order should not matter. Rather the “best fit” should be taken. Or even better, any fit (assuming that every certificate matching is good enough). This would allow the server to use fast query data structures. Also, in case the directive would take a directory (and consider every file therein), the order should not matter.

does this directive need to be in vhost configs?

I’d say no. One advanatage of the scheme would be the vhosts can be void of all SSL configuration.

Would you ever want to have the ability for a given vhost to opt out of the pool?

Don’t know, but if someone needs it, he’ll surely shout.

comment:3 Changed 5 years ago by https://id.mayfirst.org/dkg

dash said:

This definitely sounds like it could improve the module's performance for those who need it. This feature will be considered for the next major version.

comment:4 Changed 5 years ago by https://id.mayfirst.org/dkg

  • Keywords certificates sni config vhosts added
Note: See TracTickets for help on using tickets.