Am 24.12.2013 17:33, schrieb Viktor Dukhovni: > On Tue, Dec 24, 2013 at 11:16:50AM +0100, li...@rhsoft.net wrote: > >>> The symptom would be that your certificate chain is not verifiable, >>> verify error:num=7:certificate signature failure >> >> Thank you for that. >> >> Am I right that this does not break opportunistic TLS at a whole >> for such destinations? > > With clients using OpenSSL, probably not. I can't say how other > clients will react to certificates with unsupported digest agorithms. > Perhaps in some cases they try to instantiate the digest algorithm > and fail to connect. You'd need to test with Microsoft Exchange > 2003, various vendor appliances, ...
thanks for feedback and understood maybe my position is somehow easier because the MX is a barracuda appliance and so there is only outgoing opportunistic TLS maybe a good idea to consider using the wildcard-certificate with SHA2 for outgoing messages and order a 3072/SHA1 for the MX and use the wildcard for all other services at the same time i consider ignore TLS breakage for a minority because i expect falling back to unencrypted but at the same time recent systems talk to each other with state-of-the-art certificates that's a really interesting topic at all.... >> In that case I would still go with RSA 3072 / SHA256 for severar reasons >> >> * recent distributions ship OpenSSL 1.0.0 or 1.0.1 > > Yes, but some servers continue to be used for a decade or more. > >> * RHEL5: openssl-0.9.8e-26.el5_9.1 with backports > > I don't know what RedHat backported to 0.9.8e, with 0.9.8 vendors > generally backported critical fixes only, you'd need to test whether > the SHA2 enablement in SSL was one of these backports i try to test this in 2014 before decide how the new SSL cert will look like
