httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Resolve SSLCertificate directive bogosity?
Date Mon, 30 Jul 2001 06:00:55 GMT
Folks, if you could humor me a minute (perhaps I've lost my mind...)

#   Server Certificate:
#   Point SSLCertificateFile at a PEM encoded certificate.  If
#   the certificate is encrypted, then you will be prompted for a
#   pass phrase.  Note that a kill -HUP will prompt again. A test
#   certificate can be generated with `make certificate' under
#   built time. Keep in mind that if you've both a RSA and a DSA
#   certificate you can configure both in parallel (to also allow
#   the use of DSA ciphers, etc.)
SSLCertificateFile /pki/www2.rowe-clan.net.crt
#SSLCertificateFile @@ServerRoot@@/conf/ssl.crt/server-dsa.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /pki/www2.rowe-clan.net.key
#SSLCertificateKeyFile @@ServerRoot@@/conf/ssl.key/server-dsa.key

Ok... we can have an SSLCertificateFile directive for each cert defined,
and depending on the file (combined cert+key or seperate) we may also
have an SSLCertificateKeyFile.

The passphrase code simply assumes that each SSLCertificateKeyFile
corresponds to the same SSLCertificateFile, as listed sequentially.  
It gives a 'key file not found!' error instead of (gracefully) reporting 
that SSLCertificateKeyFile was ommitted.

Worse yet, if I have a combined cert+key RSA file and I'm using old, seperate
DSA cert and key files, the RSA (listed first) works (or maybe not) but it's
passed the DSA's key, and the DSA is missing it's key entirely.

The only solution I can figure is to allow two args to the SSLCertificateFile
directive, the certificate, followed by [an optional] key.  This will allow
us to explain WFT just happened to this poor user.

If we maintain the SSLCertificateKeyFile directive for backwards compatibility
(I'd _really_ rather we didn't) it would simply apply to the first _missing_
key in the listed SSLCertificateFile entries, so we have the same mismatch
possibility.

I personally believe we aught to depricate the SSLCertificateKeyFile, and have
simply a one-or-two arg SSLCertificateFile directive.  Any better suggestions?

Bill

[I should have the logging extentions (%{somefoo}x) code wrapped up tommorow,
 have to look at the %c arg in light of W. Stoddard's %c connection-termination
 logging patch from some time ago :-]


Mime
View raw message