You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2012/02/04 08:29:37 UTC

DO NOT REPLY [Bug 52495] CACertificate, CADNCertificate, CARevocation, CertificateChain, Certifcate and CertificateKey per directory context

https://issues.apache.org/bugzilla/show_bug.cgi?id=52495

--- Comment #1 from Kaspar Brand <as...@velox.ch> 2012-02-04 07:29:37 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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org