Client Cert Authentication: Accept cert in request or retrieve from host?

Question

Is it more secure to retrieve a client cert from their host rather than accept the cert presented in request?

Example:

• B2B
• Client pre-shares public cert with me
• I store public cert in database
• Later, client sends GET request + cert to my HTTPS endpoint
  • Endpoint has Enforce HTTPS and Require client certs set to true
• Python code takes client cert from GET request and compares the properties to those in the pre-shared cert from database (cert pinning of sorts)
  • valid_not_before/after
  • issuer
  • common_name
  • etc.
• Python code then:
  • Determines OCSP responder url from client cert in request
  • Retrieves issuer cert
  • Creates an OCSP request
  • Verifies OCSP response is GOOD
• Only then does the api perform work for the requestor

Question:

• Is it possible/is there any benefit to instead:
  • Parsing the hostname from client cert in the request
  • Retrieving the client cert from client source (hostname.com:443)
  • Then using this retrieved cert to compare with the pre-shared cert from database and make OCSP calls, etc?

Hope this makes sense.

Answer 1

No, there is no benefit to doing that, and in fact it likely opens a security hole. Let my explain.

First, a metaphor. A bouncer at a bar asks for your ID. The normal system is for you to present your ID (metaphor: client cert), the bouncer checks that the ID legitimate (metaphor: validates the issuer, revocation, etc), and checks that the photo matches the person standing in front of them (metaphor: the client cert will digitally sign part of the TLS handshake using their private key). You are proposing that instead of accepting the ID presented to you, you should take their name and go retrieve the ID from a government database. This is only necessary if you don't have a good way to check legitimacy of the ID on the spot. That may well be a weakness of physical IDs, but it is not a weakness of digital certificates. If the issuer signature is valid and the cert is not revoked, then it is authentic and you would get the same certificate from the CA or domain owner. So the extra lookup is not necessary.

I said your suggestion might open a security hole; let me explain:

As part of TLS client auth the client will perform a "proof of possession" by signing part of the TLS handshake with the private key that matches the certificate. If you (the server) go off and get their "real" certificate, maybe they have multiple valid certificates, how do you know that you're getting the one that matches the private key they're trying to use? Also, how are you going to do the lookup, with a name (DN) that the client gave you? How do you know that they are not lying to you and getting you to look up someone else's cert? So the extra lookup may in fact introduce vulnerabilities.