Is there any reason for this other than key/certificate management on the client-side?

  • 4
    There are a few mobile browsers that don't support it, try it on most android browsers and they'll crash on you.
    – ewanm89
    Nov 11, 2012 at 12:51
  • 3
    The common ones Chrome, Safari and the default browser for Android all support client side certificates. Though setting it up to work can be a pain especially when the desktop gives less issues. Nov 26, 2014 at 6:54
  • This question is somewhat ambiguous. TLS deals with securing the connection, while client certificates deal with establishment of identity. They address separate issues.
    – user138899
    Jan 6, 2019 at 14:48

4 Answers 4


What is authentication ? That's making sure that whoever is at the other end of the tunnel is who you believe. It really depends on the kind of identity that you want to use.

For most Web sites, the interesting notion is continuity. They do not really care who is connected; indeed, the point of a Web site is to be readable by everybody. The kind of authenticity that a Web site wishes to achieve is to make sure that two successive requests are really from the same client (whoever that client may be). This is because the Web site experience is that of a logical succession of pages, driven by the user's actions (the links on which he clicks), and meddling with that movie-like framework is what the attacker is after. The user and the Web site designers think in terms of sessions and the attacker wants to hijack the session.

This authenticity is achieved by several mechanisms:

  • Successive HTTP requests from the same client go through the same connection (with the "keep-alive" feature).
  • SSL offers a session resumption mechanism, which reuses the negotiated shared key (that's the "abbreviated handshake" described in section 7.3 of the SSL/TLS standard).
  • The HTTP request can include a cookie which the server chooses; typically, a random, user-specific value is sent as a cookie to the user, and, upon seeing it coming back in subsequent requests, the server is convinced that the requests come from the same user.

The cookie is sufficient to ensure continuity.

What extra value would client certificates add ? Well, not much. Certificates are a way to distribute key/name bindings. There are mostly three scenarios where client certificates (in a Web context) are relevant:

  1. The Web server needs an extended notion of user identity, which is defined by someone else. For instance, imagine a governmental service that can be accessed by citizens, but only after proper authentication, e.g. an online election system. What makes the citizen, with his definite name and birth date, is managed by the State at large, but not the same part of it than the one running the service. Client certificates are then a way to transport the authentication from the PKI which issued the certificate to the citizen, to the online election system which is not at all entitled to say who is named what, but must nonetheless keep clear records of who connects.

  2. The system designer has little trust in the robustness of existing Web browsers. If a user's browser is hijacked, then the secret cookie can be stolen and the user has basically lost, forever. On the other hand, if the user has a smart card, and that smart card stores a private key (which is used in combination with a client certificate), then a complete browser hijacking is still a big issue, but it is more contained: since the smart card will commit honourable seppuku instead of letting the precious private key be revealed, the situation can be recovered from. Once the mandatory format-and-reinstall has been performed, things are secure once again.

  3. The Web site does not only want authenticity, it also wishes to get non-repudiation. Non-repudiation is a legal concept which needs some support from the technical parts of the system, and that support is digital signatures. We are outside of what SSL/TLS provides, here. In no way can a SSL/TLS client authentication be a proof which could be used to resolve some legal conflict between the user and the server itself (a bank server cannot show the transcript of the connection and say "see, that user really asked me to buy these actions at that price", because the bank could easily have fabricated the whole transcript). For such things, one needs client certificates and some client-side code which uses the certificate to sign the actual data. However, once the hard work of issuing certificates to clients has been performed, it makes sense to just use them for HTTPS.

In the common case of a Web server, none of these scenarios apply. So client certificates are not used, because they would raise practical issues while not adding any extra value. That would be a solution in search of a problem.

  • +1 good answer. Just to reiterate the headlines here - client authentication depends upon a pre-existing relationship between the end-points, and certificates identify computers - not users.
    – symcbean
    Nov 11, 2012 at 20:40
  • 3
    Client certs matching server certs giving full mutual auth does guarantee no MITM using via rogue CA signed server cert in SSL/TLS. And it can be the something you have factor in two factor authentication.
    – ewanm89
    Nov 11, 2012 at 20:43
  • 4
    For me the biggest reason for using client certs is avoiding passwords to login a client. Essentially the certificate is just some container for a key in that context. Nov 11, 2012 at 23:39
  • 5
    With a cookie stored client side, there is no need for a password. In a way, a client certificate is the asymmetric-crypto version of the cookie. Nov 11, 2012 at 23:47
  • Any e-commerce site or subscription website "needs an extended notion of user identity, which is defined by someone else": the payment credential. Feb 11, 2016 at 21:11

The primary reason is that 95% of internet users have no idea what a client-side certificate is, let alone how to use one. Some users can barely manage to use usernames and passwords, and most still don't bother with two-factor authentication. It's also a hassle to install a client certificate on separate devices (desktop, laptop, tablet, smartphone, etc.) for authentication to a single service.

So, for a quick list:

  • Ignorance. People just don't know what they are or why they're useful.
  • Convenience. People can't be bothered to configure their device to use client certificates.
  • Support. If people today still have to phone up tech support when they forget their password or can't log in, can you imagine how many more support calls will be required if they have to install a client certificate? This problem is multiplied even further by Internet Explorer's market share dropping, so staff need to be trained to guide users through installation on IE, Firefox, Chrome, Opera, Safari, etc. plus various mobile devices.
  • Complexity. Additional server-side code is required to validate the certificate in relation to a user account.
  • Prevalence. No major sites are using them en-mass yet, so nobody else will. I realise this is a catch-22, but technology adoption often is.
  • Complacency. Most vendors assume passwords (or 2FA) are strong enough for their purposes, even when those vendors are protecting highly sensitive / critical information such as financial data.

So, whilst it would be nice to see client-side certificates on a large scale, I really don't see it happening unless a serious event pushes vendors into doing it.

  • 1
    Extra complexity: You need renegotiation or client auth breaks confidentiality. Nov 11, 2012 at 13:41
  • Client cert can be a factor for two factor authentication. See how pip.verisignlabs.com handles it.
    – ewanm89
    Nov 11, 2012 at 19:58

The client is trying to reach a specific server, identified in the URL. So the client needs to authenticate the server.

On the other hand, in most uses of HTTPS, any client can contact the server. The server doesn't have any prior knowledge of the client. So there is nothing for the server to authenticate the client against. The server wants to authenticate the user, not the client machine.

In an Internet setting, the client may be behind a proxy, on a dynamic IP address, etc. There is nothing that the server might want to verify. The only point of authenticating the client would be to record its identity for future uses, either for forensic purposes or to track clients across multiple connections. Since users may connect from multiple machines, there is not much point in tracking client machines. Recording client identities is only very marginally useful to identify malicious clients or users after the fact (the attacker is likely to have generated a certificate that doesn't provide any useful information), it isn't worth spending any effort.

In an intranet setting, where only known clients should connect to the server, client authentication is useful and is used.

  • OP almost certainly wants to replace passwords with TLS client certs. "there is nothing for the server to authenticate the client against" makes no sense.
    – Navin
    Nov 16, 2017 at 11:16
  • @Navin The OP was asking a generic question, not with a specific goal in mind, so there's no reason why they would want to replace anything by anything. Passwords and client certificates serve different goals. If “there is nothing for the server to authenticate the client against” doesn't make sense to you, you need to study the answers on this page a bit more. You seem to be missing the important distinction between a machine and a user. Nov 16, 2017 at 11:52

In cases like Gmail, Yahoo and other web apps that use PKI to authenticate servers, client authentication is not done using certificates, but instead uses simpler authentication such as user/name passwords. Think about this. Your browser can store x number of certificates for the various CA's, and the websites out there. But can Gmail hold certificates for its millions of users ? It is simply not scalable.

This is a very simplified answer as to why client certificates are not used. However, when you SSH into a server, client certificates are/maybe used.

  • 3
    "But can Gmail hold certificates for its millions of users ? It is simply not scalable." Gmail manages usernames and passwords for millions of users, so the scale of the data isn't the problem. It's the client-side management problem including a single sign on for multiple user devices. People now understand (to a basic extent) how to work with usernames and passwords. PKI certificates and how to configure their various browsers (software more generally) on various platforms (PC, tablet, smartphone, etc.) to use them are far beyond their ken. Jun 12, 2015 at 15:10
  • 1
    Just as the client validates the server cert using only CA roots, the server can validate a client cert using only CA roots not data for each client, and that's much much less. But sites like gmail want to store data on each client anyway. Jul 15, 2016 at 5:08

You must log in to answer this question.

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