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