I am working on an application (using Spring Security) that has two possible user authentication mechanisms:

  • either X.509 certificate (using mutual SSL handshake)
  • or user + password

For user+password, I added a brute-force prevention mechanism based on IP blocking (simple POC tutorial), when there are lots of consecutive failed user+password login attempts from the same IP address (the app is internal, so should not be exposed to ISP proxies hiding users).

But is it possible to do (somehow) brute-force attacks with X.509 certificates?

EDIT: I am checking if the certificates are emitted by approved CAs (using a JKS trust-store).


3 Answers 3


The X509 just authenticates the identity the user is claiming to be, so in theory yes. But an attacker is not going to brute force guessing the correct keys for a X509 certificate because there are so many possibly keys.


Certificates embeds an asymmetric public key for some cryptographic scheme (e.g. RSA).

If you were to try to brute force certificate authentication, you would need to get your hand on the public certificate (easy), then derive the private key from the public key.

This would in fact be solving the problem of breaking the underlying cryptographic scheme, for which we do not currently have an efficient method to do so. Brute forcing isn't a realistic attack in this case.

The realistic attack on client certificate would be to acquire the private key from the client computer and acquire the password protecting it (if there's one). This can be done by conventional means, like using trojan, social engineering techniques and so on. The password method is already vulnerable to the same attack anyway.

  • Well said, it's why client's RSA key should be protected with all means. I'm working embedded devices, and this keys is always encrypted. Also we employ TEE, and in plain form it never leaves TEE, all private operations are there. It's petty sad to see how PC are retarded.
    – VovCA
    Commented Jun 1, 2017 at 17:56

Given that you've expressed that the cert alone is a sufficient identifier, I'll assume that you're asking "given that someone has seen a certificate go over the wire, can they brute force their way in as that user later?". (Vs "can someone wardial getting into account X by using all the certs they exfiltrated from some computers?" - which is an easy "yup")

The answer is: Of course. But anyone who would try to do so is foolish.

Given a certificate what a brute forcer is trying to do is determine the private key that goes with the public key embedded in the certificate. Doing a TLS brute force attack would be equivalently "try 000000...00000, 0000...000001, 000000...000002", which just comes down to signature forgery. But, since the attacker could themselves just compute the sign+verify operations they can do an offline attack; so by the time they get around to talking to your service they should have already determined they have the right answer (since they are just going to run the same formula you are, modulo whatever access rights you check for based on certificate properties).

They could also just start jamming self-signed certificates (or 3rd party CA signed certificates) at your service to see if you've done an overly simplistic authentication model (such as reading a value out of the subject without doing CA pinning); but that's not really "brute force" so much as "breaking your auth model".

You must log in to answer this question.

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