0

I've spent the last few days trying to learn x509 certificates (issued by CAs) and I think I have a solid understanding of the principle of how they work. My understanding is that a digital certificate has an associated signature, and that signature should only be able to be decrypted with the public key of the CA that issued/signed it.

What I'm failing to understand is how to actually implement that verification logic in Java. Where do I retrieve that public key from to decrypt the signature and verify the digest? Is there a lookup table somewhere where you can provide a DN and get a public key back?

I've tried to use the javax.security.cert.X509Certificate class to load a certificate, and I notice the verify function that requires a public key. I just don't know where to get the public key.

Joe D
  • 378
  • 1
  • 9
  • Verifying a signature is not decrypting and signing is not encrypting; see (my) https://security.stackexchange.com/questions/159282/#159289 . And per below note that verifying the signature on a cert, although necessary, is not nearly enough to establish the cert can be trusted. – dave_thompson_085 Jan 31 '23 at 20:22

1 Answers1

0

You can grab the public key from the certificate itself. After all, a certificate is a public key, some metadata and a signature.

Now you still need a trusted source of certificates or public keys. And that is the application's truststore. This one is filled with certificates the application is allowed to trust (blindly). So any certificate contained in the truststore is trusted, but also any certificate that was signed by one of the trusted ones. With that, you can build a hierarchy and validate an enormous amount of certificates.

On top of just checking the signatures and trust chains, you will also want to contact the CAs for their certificate revocation list - just to ensure the certificate in question is not contained there.

See also

Queeg
  • 7,748
  • 1
  • 16
  • 42
  • Revocation can be checked with OCSP instead and nowadays often is; in fact CABforum no longer requires CAs provide CRLDP for EEs, although all I've looked at do. And in addition to checking signature and revocation there are LOTS of other things you must check before trusting a cert; see rfc5280 section 6. In Java the best course is to use `CertPathBuilder` and/or `CertPathValidator` which already implement all this stuff _correctly_. – dave_thompson_085 Jan 31 '23 at 20:24