I'm currently working on a project that includes client-authorization using client certificates, where my app is the Certificate Authority. Doing that, every user that registers to my web server gets a p12 signed certificate issued especially to his username as common-name. Currently the app signs every CSR it gets, only if the CN is not in the users database.

Am I exposed to potential risk doing so? Can the client abuse it somehow? Do I need to check more carefully the PKCS12 parameters?



Possible risks include:

  1. Complexity. The clients will have to generate and submit CSRs, securely store private keys, and renew them when they expire. That’s a lot more work for them than simply storing an API key.
  2. Response time. If you decide Client B needs to have their credentials revoked due to an incident, you may not want to sit around waiting for their certificate to expire, or for the next round of CRLs to be published.
  3. Spoofing. You have to validate the identity of each client as they request a certificate. How will you validate them so you know you aren’t giving a certificate to an impostor?
  4. Maintenance. You have to support expirations, renewals, revocations, and everything associated with running a PKI. This is a non-trivial amount of work.
  5. Dynamic clients. A certificate is associated with one instance. If you validate their domain name, they’ll need a new certificate for each instance. This might be OK for desktops, but gets tougher when you’re talking about mobile phones or kubernetes pods and docker containers.
  6. Lopsided capacity. As your root certificate approaches expiration, you can expect a giant rush of client renewal requests. So for a once a year occurrence, you may have to scale to handle a lot more traffic.

On the plus side, mutually authenticated certificates form a trustworthy bond in both directions. That’s worth a lot of headaches.

  • Presumably for pods/containers, they'd set up a proxy (say, nginx) and encrypt with their client cert there (and have internal certificates for proxy to instance communication). This reduces the number of things with access to the "real" private key considerably. – Clockwork-Muse May 10 at 22:18
  • @Clockwork-Muse , i assume that as well. But all those internal certificates add complexity, and thus more risk. And we can’t ignore the security implications of the internal certificates, even if the machines shouldn’t be accessible, mistakes happen. – John Deters May 11 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.