[cryptography] Allergy for client certificates

ianG iang at iang.org
Thu Oct 10 23:27:39 EDT 2013

On 9/10/13 01:41 AM, Tony Arcieri wrote:

> We use client certs extensively for S2S authentication where I work
> (Square).
> As for web browsers, client certs have a ton of problems:

I have successfully used them in a PHP website of my own design.  I just 
plugged away until they worked.  I grant they have a ton of problems, 
but it may be a case of half-empty or half-full.  Here's my point by 
point experiences, partly because the whole exercise for me was in order 
to find out...

> 1) UX is *TERRIBLE*. Even if you you tell your browser to use a client
> cert for a given service, and you go back to that service again,
> browsers often don't remember and prompt you EVERY TIME to pick which
> cert to use from a giant list. If you have already authenticated against
> a service with a given client cert, and that service's public key hasn't
> changed, there's absolutely no reason to prompt the user every single
> time to pick the cert from all of the client certs they have installed.

Yes, that part doesn't work.  So what my site did was to take every cert 
provided and hook it up to the account in question.  This was a major 
headache to code up because I had to interpolate the contents of the 
certs and do things like match email addresses.

It has a number of interesting edge cases such as correct name but 
different email address.  Also, the name isn't unique, or is it?

I solved these edge cases by leaning on CAcert's systems of governance, 
and simply asking the user:  "is this you?"  If they lie, I can fall 
back on Arb to solve everything.  (OK, I cheated a bit there to get it 
to work, there are other solutions and other possibilities, but I wanted 
seamless non-support solution.)

> 2) HTML <keygen> tag workflow is crap and confusing. It involves
> instructing users to install the generated cert in their browser, which
> is weird and unfamiliar to begin with. Then what? There's no way to
> automatically direct users elsewhere, you have to leave a big list of
> instructions saying "Please install the cert, then after the cert is
> installed (how will the user know?) click this link to continue"

This is a problem that is outsourced from the website/user to the 
CA/user interface.  It can be done.  I don't know how the coding is 
done, but CAs do handle this well enough.  I think again it is just a 
matter of plugging away until you get the code going.

(What is not easy is using the certs for email.  That's a fail, unless 
you are using some form of automatic certs distribution.)

> 3) Key management UX is crap: where are my keys? That varies from
> browser to browser. Some implement their own certificate stores. Others
> use the system certificate store. How do I get to my keys? For client
> certs to replace passwords, browsers need common UI elements that make
> managing, exporting, and importing keys an easy process.

It is true that key management is crap, but how much do you care?  As 
long as the keys work, everything is cool ... for *users*.  They never 
need to look at keys.  Only developers need that ... ;-)

(Yes, this is skipping the whole privacy question, but having worked 
through it, you aren't going to do any worse with certs.)

> Passwords may be terrible, but they're familiar and people can actually
> use them to successfully log in. This is not the case for client certs.
> They're presently way too confusing for the average user to understand.

I think, if you can crack the "get a cert in the browser" problem, that 
whole equation flips around.  In my experience, client certs worked way 
easier than passwords.  They just worked.

The big benefit we had in our community was that our target audience 
already had to have put their cert into their browser, it was part of 
the Assurer test.

What was not easy is the websites.  Taking random site X like a wiki and 
engaging it for immediate auth with the cert is hard, mostly because 
these systems out there have never really considered certs, and often 
enough they haven't even considered SSL.


ps;   More here:

More information about the cryptography mailing list