Upfront, please overlook my naivety. I have a service app that talks to a web api. I only want the service to talk to the web api, nothing else. Means I need to secure it and I'm trying to understand why I should use a client certificate as opposed to a sufficiently long random shared key/string.

The way I'm thinking about it is; I live in a house and use a key to open my front door. I made a copy of the key and have given it to a family member so they can also unlock the front door. Now back to the digital scenario, if I create a random key/string, permit only those that pass that key with requests to my web api, and get my service app to include that key in all requests to the web api, am I not achieving my goal of only allowing the service app to access my web api? Why would I need the extra complexities of creating and installing a client certificate?


  • 1
    certs provide more capabilities, but you might not need any more.
    – dandavis
    Apr 22, 2017 at 16:48

1 Answer 1


Contrary to giving a hardware key to some family member the random string you propose is just data and could be easily copied without notice. And while you might feel that the transport of the hardware key in the pocket is sufficient protection the situation is different with data only as the key.

Still, if you protect your data key well it might be secure enough in your environment, although the exact security requirements of this environment are unknown. Protecting the key means at least using HTTPS so that nobody in between client and server can sniff the key.

But even with HTTPS it is enough that a single of the systems having the key gets compromised. In this case the key can simply be copied and misused because all systems use the same key. Assuming that the misuse of this shared key is noticed at all the only option is to revoke this single shared key which means a new shared key need to be distributed to all systems. In this case it would already an improvement if you use a different key for each system since then the impact of misuse is limited and you only need to revoke and update the key for a single client. This scheme of having a different key for each client could be simplified by using client certificates with your own certificate authority and just trusting any certificate issued by this authority.

Client certificates also have the advantage that they could be hardware backed using a smart card or similar. This way an attacker needs to have physical access to the system to steal the key. Compromising the system from remote is not sufficient, but misusing the existing key from remote might be possible if there is no local interaction required for using the key (i.e. always in smart card with no PIN). And even if the attacker manages to get physical access to the hardware key he will probably not be able to copy it with acceptable costs so the loss of the key will be noticed and access to the key could be revoked.

  • Thanks Steffen. Does the server normally authenticate the client certificate with the Certificate Authority? And if I will be using HTTPS without hardware backing, then would the certificate be passed in a HTTP header and thus be similar to a string that can be copied?
    – Steve
    Apr 26, 2017 at 2:11
  • 1
    If the server has client authentication enabled it will normally check that the certificate is trusted by a local CA. But some servers might not do it, see optional_no_ca setting in nginx. Also, the client certificate is sent inside the TLS handshake which precedes HTTP. It is send in clear text since like with all certificates the authentication comes from the proof that the client has the matching secret key. How to get access to the certificate in your application for further checks depends on the server. Apr 26, 2017 at 3:57

You must log in to answer this question.

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