Suppose you're interested in establishing a TLS connection with a specific host, and won't be using any sort of CA, or x509 certificate chains - you only want to compare if the target host uses a specific certificate. How would you make this comparison?

Compare the thumbprints (apparently not recommended the thumbprint is SHA-1 and you want to be really careful). Compare the raw data? My first idea was to just compare the public keys, but I can't see this mentioned anywhere, so I'm not sure whether maybe I'm missing some problem with this.

I can imagine that someone could simply create a certificate that uses has the same public key by some sort of modification. The fake certificate could then possibly have different fields, and perhaps somehow, that could be used in some way... but regardless, in the context of TLS, I can't see why any of that would matter - if the public keys matches, it will be used for the handshake, and so the attacker won't be able to do anything (assuming they don't have the private key).

  • You can compare the thumbprint, SHA1 isn't considered broken yet.
    – ThoriumBR
    Commented Jul 20, 2022 at 17:44
  • @ThoriumBR I think you should add a source like this sha-mbles.github.io as well... In the not so far future it's going to be rather affordable to get a collision.. And it also depends on your threat model Commented Jul 20, 2022 at 18:20
  • Two months using 900 GPU and 100k USD in infrastructure isn't something everyone would be able to do.
    – ThoriumBR
    Commented Jul 20, 2022 at 21:43

2 Answers 2


*Technically*, there is nothing wrong with comparing public keys. This process is known as HTTP Public Key Pinning (HPKP) which allows you to establish a trust based on public key.

Unfortunately, HPKP maintenance complexity didn't make it popular. Some time ago, Google used to use HPKP in their Chrome browser with hardcoded public keys of their services, but eventually dropped this technology, because key management/replacement on client side (public key pins) is hard and everyone must use the same version of client app.

  • From my understanding only HPKP settings using HTTP header is removed but not the internal pinning of strategic domains like google.com, facebook.com etc. (HPKP preload) But this is not based on the public keys of the services directly, but instead was pinning to some CA certificate in the certificate chain. Commented Jul 20, 2022 at 17:05

There is an official standard for using raw public keys without certificates in TLS: RFC 7250. The downside is that this isn't widely implemented: OpenSSL doesn't have it yet, nor wolfSSL, nor Mbed TLS. GnuTLS does.

Whether you end up using RFC 7250 or sending a certificate that's hard-coded to be trusted, you'll be confronted with the same problem: checking that the public key sent by the peer is the one you were expecting. When using certificates, this is done by checking the signature from the CA, which is performed over the whole certificate, which includes the public key. When not using certificates, you can do that by comparing the public key representation in the format sent by the peer with a reference value. You can also do that by doing a mathematical comparison, but that's trickier and doesn't really have any practical advantage.

Instead of storing a reference copy of the public key representation, you can store a hash of that representation. Use whatever hash you prefer (typically SHA-256 or SHA3-256, or a larger size if you prefer). You can also hash the whole certificate, if you want (this means the peer has to use exactly the same certificate). Note that if you rely on information in the certificate other than the public key itself, you must hash or compare the whole certificate.

The fingerprint of the certificate is a hash of the whole certificate. A SHA-256 fingerprint is fine. Don't use a SHA-1 fingerprint: that's vulnerable to collision attacks if a peer can enrol under one identity and then masquerade as another. SHA-1 is only safe if there's absolutely no way for an adversary to inject more than a few tens of bytes of content into the certificate. Rather than figure out whether a collision attack is truly irrelevant, just don't use SHA-1. Not using SHA-1 has the added benefit that you won't need to include a SHA-1 implementation in your applications.

  • If adversary can get you to pin any cert containing their key (or the key directly), you are already broken; they don't need a collision. Only in the usual case of deriving trust from a third-party (CA) does collision matter. Commented Jul 21, 2022 at 4:04
  • @dave_thompson_085 You seem to be assuming that a key is either trusted or not trusted, full stop. This is not a common trust model. Usually a key is trusted for a specific purpose (e.g. it's the key of my coffee maker). CAs may be involved but don't have to be. The threat that involves a collision is when an adversary can convince you to register a key for some purpose, and then they try to use that key for a different purpose. If the purposes are encoded as something partially under the adversary's control, and the purposes' encodings are hashed, a hash collision does the trick. Commented Jul 21, 2022 at 8:03

You must log in to answer this question.

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