Bug 52495 - CACertificate, CADNCertificate, CARevocation, CertificateChain, Certifcate and CertificateKey per directory context
Summary: CACertificate, CADNCertificate, CARevocation, CertificateChain, Certifcate an...
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2012-01-22 01:31 UTC by Christoph Anton Mitterer
Modified: 2012-02-04 07:29 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2012-01-22 01:31:55 UTC

It's already possible to set the Client Auth Requirements per directory context, which triggers a renegotiations. The same is true for the CipherSuite.

I'm not an SSL/TLS expert, but some of the following suggestions might be possible to (eventually) implement:
should be settable per directory-context.

I don't know whether SSL/TLS allows changing the server certificates, certificate chains and the proposed DNs in renegotiations...
But at least CACertificate should be changeable on a per directory basis, as this is only a server side verification.

Comment 1 Kaspar Brand 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.