Resolve SSLCertificate directive bogosity?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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 :-]

Re: Resolve SSLCertificate directive bogosity?

[Mads Toftum <ma...@toftum.dk>]

On Mon, Jul 30, 2001 at 01:00:55AM -0500, William A. Rowe, Jr. wrote:
[SNIP]
> 
> 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.

I don't like SSLCertificateKeyFile being optional - I'd much rather make
it mandatory and in the relatively few cases[1] where the key and the
certificate are actually in the same file, then you should just put the
same for both directives.
> 
> The passphrase code simply assumes that each SSLCertificateKeyFile
> corresponds to the same SSLCertificateFile, as listed sequentially.  

Not good - although not many people seems to have been hit by it [2]

> 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?

I would prefer making a distinction between RSA and DSA certificate directives
(possibly just by adding DSA somewhere in the name) - DSA certs aren't used
very often [2].

[1] I say this because having the key and certificate in the same file usually
only happens if you specifically put them there. If you either make your cert
with the tools in mod_ssl or have your certificate signed by an external CA,
then the key and the cert will be seperate. And the security requirements are
also quite different between the two.

[2] Based on following the mod_ssl users mailing list closely for >2 years.

BTW: would it be a good idea to get some of the people that are used to
mod_ssl under 1.3.x to start testing? I'm sure that a short howto sent to
the mod_ssl users mailing list would get many more testers. 

vh

Mads Toftum
-- 
With a rubber duck, one's never alone.
              -- "The Hitchhiker's Guide to the Galaxy"