On Wed, Apr 17, 2024 at 3:21 AM Uwe Sauter uwe.sauter.de@gmail.com wrote:
Hi all,
one of my Rocky Linux 8 servers was updated automatically to 2.6.7 this night from the Symas repo. The install script seems to include an automated restart of the service but that failed with:
main: TLS init def ctx failed: -1 error:0A00018E:SSL routines::ca md too weak
As this is an internal network with a private CA the strength of the CA is of minor relevance.
I think the change comes with symas-openssl-libs-3.0.8-1.el8.x86_64…
Can anyone suggest a workaround (other than exchanging the CA and its issued certificates)?
One workaround is to use SECLEVEL=n, where n is in the interval [0, 5]. A typical string would be "@SECLEVEL=1", and you would set it in your cipher string. I selected 1 because that allows SHA-1, which may (or may not) be correct for your issue. If you show your certificate, then we could tell you which value you should use for SECLEVEL. See < https://www.openssl.org/docs/man3.0/man1/openssl-ciphers.html%3E and < https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_security_level.html%3E.
Note that the md cipher used on a root ca certificate does not matter. The security level of public key matters on a root ca certificate. That is, you could self-sign your ca root with MD2 using a 4096-bit RSA moduli, and the root certificate would be fine. That's because a root ca certificate is trusted and distributed out-of-band; and a weak hash does not matter on a root certificate because it does not suffer 2nd preimage (collision) attacks. If the attacker finds a different certificate with the same hash (and different public key), the attacker cannot use it for an attack since the public key is not trusted by relying parties. The thing that matters for a root certificate is the public key cannot be factored over the lifetime of the certificate. If an attacker can factor the public key (and recover the private key), then the attacker can issue certificates.
And note that the previous paragraph only applies to root ca certificates. Subordinate or intermediate ca certificates do suffer 2nd preimage attacks, so they must use an appropriate hash, like SHA256. That's because subordinate or intermediate ca certificates and end-entity certificates are placed on the wire, and an attacker can swap-in a new certificate using the old signature after finding a collision. Flame malware did this.
Jeff