On 21.10.2013 06:09, Trevor Perrin wrote:
> I looked at your patch. Besides lack of passphrase-handling, it
> breaks compatibility with existing config files (which assume
> certs/keys are matched by type, not order).
I don't think that "random order of multiple SSLCertificateFile and
SSLCertificateKeyFile directives" is a feature which has ever been
promised in our docs. In those rare cases where people are currently
configuring more than one cert per vhost, I would be quite surprised to
see a config where the order of the SSLCertificateKeyFile directive does
not match the one of the SSLCertificateFile directives.
> That would work, but someone would have to rewrite all the
> passphrase-handling code,
Correct, and an overhaul of ssl_engine_pphrase.c is actually long due,
so we shouldn't introduce more band-aid-style workarounds.
> and users would have to switch to a new set
> of commands for working with certs / keys.
No, that's not what I had in mind. SSLCertificateFile and
SSLCertificateKeyFile can stay (not the least to support existing
configs), but SSLOpenSSLConfCmd would offer an additional way of
configuring certs and keys, e.g. for those cases where more per-cert
tweaking is desired.
> Seems like a lot of work. For example, how would the generic
> SSLConfCmd commands get hooked-up with passphrase handling for the key
> files?
Based on Steve's recent work on OpenSSL-master ("PrivateKey" SSL_CONF
command), we might reuse the ssl_pphrase_Handle_CB() callback and set it
for use with SSL_CTX_set_default_passwd_cb(). This needs further
examination, though.
> Redesigning and reimplementing all of mod_ssl's cert / key handling
> around SSLConfCmd is a bigger task than I can handle.
I intend to work on that, and have already done some experiments with a
modified/trimmed down version of ssl_pphrase_Handle(), which only keeps
the tPrivateKey hash in the global SSLModConfigRec.
> But I still wonder if a ServerInfoFile directive would be worthwhile,
> in the meantime.
I don't see a justification for doing that at this time, also when
considering that we're currently coding against OpenSSL 1.0.2, which
isn't released yet.
Kaspar
