On 09.10.2013 15:52, Dr Stephen Henson wrote: > It's tempting to just add a directive but after some thought I think expanding > Apache SSL_CONF handling is the way to go. This would add some future proofing > so we don't have to go through this all again in future.
Yes, please. Let's not perpetuate the pattern of adding another directive to mod_ssl whenever a new OpenSSL feature needs to be exposed. As an interim step, and sort of a proof of concept, it might be worthwile to see if adding equivalents of SSLCertificateFile and SSLCertificateKeyFile to SSLOpenSSLConfCmd (in ssl/ssl_conf.c, at the OpenSSL end) would allow support for per-cert options. The concept of collecting the options in ssl_cmd_SSLOpenSSLConfCmd and replying them at the appropriate place in ssl_engine_init.c would remain, and you would use something like <VirtualHost ...> OpenSSLConfCmd KeyFile foo.key OpenSSLConfCmd CertificateFile foo.crt OpenSSLConfCmd ServerInfoFile foo.pem OpenSSLConfCmd KeyFile bar.key OpenSSLConfCmd CertificateFile bar.crt OpenSSLConfCmd ServerInfoFile bar.pem </VirtualHost> to configure multiple cert and "current-cert" settings in turn (and not worry about the case of encrypted private keys, for the time being). "KeyFile" would result in calling SSL_CTX_use_PrivateKey_file(), and "CertificateFile" in SSL_CTX_use_certificate_chain_file(). ssl_engine_init.c:ssl_init_server_ctx() is most likely the appropriate place for inserting this (i.e., it's perhaps best to move the current SSL_CONF_CMD block from the end of ssl_init_ctx_protocol() to somewhere in ssl_init_server_ctx(), maybe some tweaks are needed for ssl_init_server_certs(), too). What I would try to avoid right now is fiddling with the tPublicCert, tVHostKey and tPrivateKey hashes (and the ssl_asn1_table_* friends). Kaspar
