Summary: | CACertificate, CADNCertificate, CARevocation, CertificateChain, Certifcate and CertificateKey per directory context | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Christoph Anton Mitterer <calestyo> |
Component: | mod_ssl | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | NEW --- | ||
Severity: | enhancement | ||
Priority: | P2 | ||
Version: | 2.5-HEAD | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
Christoph Anton Mitterer
2012-01-22 01:31:55 UTC
(In reply to comment #0) Short reply: it's rather unlikely that most of this is ever going to happen (unless some future release of OpenSSL would extend its API for changing connection settings). Longer reply - looking at the directives in question: > SSLCACertificateFile > SSLCACertificatePath OpenSSL doesn't allow changing the list of trusted CAs once a connection has been established (there's SSL_CTX_load_verify_locations(), but no SSL_load_verify_locations()). > SSLCADNRequestFile > SSLCADNRequestPath This is doable, in theory (OpenSSL provides SSL_set_client_CA_list()), but IMO of limited use as long as SSLCACertificateFile/SSLCACertificatePath can't be adjusted. It would only change the list of DNs ("hints") sent to the client to assist him in picking an appropriate cert, but verification would still be based on the per-vhost list of trusted CAs. > SSLCARevocationFile > SSLCARevocationPath These should simply mirror the options for SSLCACertificateFile/SSLCACertificatePath (there's no point in making them configurable per directory as long as the list of trusted CAs can only be configured at the vhost level). > SSLCertificateChainFile > SSLCertificateFile > SSLCertificateKeyFile Changing the certificate when renegotiating is permitted by the spec, in theory, but it's hard to see a use case for per-directory configuration of the server cert. It would have to include the same DNS name(s) as the one configured at the VirtualHost level (ServerName/ServerAlias directives), since clients might otherwise (rightfully) reject the new cert due to name mismatches. Generally speaking, I would recommend to separate sites with differing TLS requirements into their own virtual hosts (perhaps based on SNI, depending on the browsers you need to support). This can also reduce the number of required renegotiations, which has further performance benefits. |