Bug 52495

Summary: CACertificate, CADNCertificate, CARevocation, CertificateChain, Certifcate and CertificateKey per directory context
Product: Apache httpd-2 Reporter: Christoph Anton Mitterer <calestyo>
Component: mod_sslAssignee: 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
Hi.

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:
SSLCACertificateFile
SSLCACertificatePath
SSLCADNRequestFile
SSLCADNRequestPath
SSLCARevocationFile
SSLCARevocationPath
SSLCertificateChainFile
SSLCertificateFile
SSLCertificateKeyFile
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.


Cheers,
Chris.
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.