Am 27.05.2015 um 09:33 schrieb Rainer Jung:
Am 27.05.2015 um 08:40 schrieb Kaspar Brand:
On 26.05.2015 10:33, Rainer Jung wrote:
I find it questionable. I would find it more natural to embed the params
in the cert files they apply to, so e.g. the DH params in the RSA cert
file and the EC params in the ECDH cert file and also to not require a
special order for the files which at the end we do not check. Since
missing the embedded params goes unnoticed (finding them is only a DEBUG
log line) it is not very user friendly.
When I added this with r1527295, I didn't expect custom [EC]DH
parameters in a certificate file to be the typical case for a mod_ssl
configuration - and even in the light of Logjam, I don't think that we
would want to recommend creating custom DH parameters for the average
admin. As long as 2048-bit RSA keys are configured (the standard for
certs issued by publicly-trusted CAs these days), there's nothing wrong
with relying on the built-in DH parameters, i.e. those from RFC 3526. [1]
Can't we simply try to read DH and ECC params from every certificate
file and stop in each of the two cases when we have found some? That
would tighten the user unfriendlyness to the case of having multiple
inconsistent parameters embedded in different cert files. And even that
could be checked and logged as a warning.
I don't have strong feelings on this, but am not sure if it's worth
adding more code to address this specific case. My guess is that
multi-cert virtual host configurations with OpenSSL < 1.0.2 are
extremely rare, since they are prone to the
one-intermediate-CA-cert-only issue, and with OpenSSL 1.0.2 or later,
SSLOpenSSLConfCmd is definitely preferrable.
OK
As far as your observation "to embed the params in the cert files they
apply to" is concerned, I think there might be a misunderstanding here:
the [EC]DH parameters are orthogonal to the authentication algorithm -
for an RSA key, both are applicable (cf. openssl ciphers -v aRSA+DHE and
openssl ciphers -v aRSA+ECDHE).
Thanks for the correction.
That means if you start mixing embedded keys and separate key files,
I would definitely discourage from doing so, and wouldn't bother with
adding configuration code to address such cases (would introduce
unneeded complexity). Putting the the private key into the
SSLCertificateFile has been discouraged since the 2.0 release, actually
- see the SSLCertificateKeyFile docs added with r93825. What is probably
missing is a more prominent notice in the section on SSLCertificateFile.
OK I'll have a look at the docs an see whether I can improve them.
[1] The weakdh.org site needs an update on this, as acknowledged by a
team member meanwhile, see
https://www.ietf.org/mail-archive/web/tls/current/msg16515.html
I edited the mod_ssl docs and faq in r1682923 and r1682937 (trunk),
r1682929 and r1682939 (2.4) and r1682942 (2.2). I hope things are at
least as clear as before my editing.
Regards,
Rainer
