We use a self-signed certificate with DSA key algorithm (and RSA signature algorithm) for securing a Kafka cluster in production. The access to the Kafka servers is already limited (by firewall) by allowing access only to specific IP subnets. The certificate generation and configs as done as mentioned in https://docs.confluent.io/2.0.0/kafka/ssl.html

But, someone strongly suggested moving to certs with RSA key algorithm and made it sound like a serious vulnerability. From reading multiple answers (like this Is the use of DSA keys a security risk?) I don't find it that bad. Should we move to RSA based cert stopping everything else we are doing?

I'm looking for a suggestion based on best practices, as I could not find proper guidelines or standards.

  • 2
    With TLS 1.3 DSA is no longer supported. This should be an indicator too that you should not use DSA anymore. Commented Apr 26, 2019 at 2:42

1 Answer 1


RSA is generally considered to be a better idea simply because it is less fragile than DSA. When used properly, they are both equally secure. The problem stems from the fact that DSA signatures, if created on a system with insufficient entropy, can leak the private key. All it takes is for this to happen once. RSA does not have this issue. So yes, best practices are to use RSA instead of DSA, if possible.

Make sure you pin the fingerprint (since you said the certificates were self-signed), and use keys that are at least 2048 bits in size. This goes for both RSA and DSA. If moving to RSA would be problematic, then there's really no rush. DSA is simply fragile and not an ideal choice, but is not cryptographically broken.

If you have control over the signing code, you can use RFC 6979 to create signatures in a deterministic manner without risking loss of the private key in the event that only poor randomness is available.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .