10 ms·

Why is nobody using SSL Client Certificates?

255 points by e1ven 15y ago

th0ma5 15y ago
I did this one time at home to share some files quickly somewhat securely, and sent my friend a cert to install. It worked fine. At my Fortune 500 of course the wifi has certs, but they don't do any certs for authentication (er, unless you count drive encryption and NT security?) but no HTTPS ... of course SSL for user keys, but no "authorized clients" style of client based keys. I think it is probably the perceived overhead of operating your own CA, even though modern web app like interfaces exist and make doing such a thing a breeze. It could be that the less technical people like architects (that don't have to implement it themselves) just assume that it'll be too much of a conceptual thing to try and sell. It works tho! And seems like it would be in theory more secure given the features of revocation, but I guess that's the same as turning off someone's ID in the directory perhaps.
pagekalisedown 15y ago
Ancient article. But as a side note, startssl.com uses them very effectively.
- mappu 15y ago
  They do, indeed, and they provide a great service. However, if you have two accounts there, logging out and logging in again causes IE9 to just re-use the same certificate instead of prompting you again.
acheron 15y ago
I found the headline funny: my job for the past 3 months or so has been heavily involved with SSL client certs. Of course, it's on a private network, not the Internet, so that makes it easier. (By which I mean "easier to force the clients to use them", not actually easier to use.) I absolutely agree the browser interface for certs is terrible. The post is from 4 years ago, and the interface still looks just the same, and is still just as much of a pain in the rear. I would take this over "What color was your first car?" any day, though.
TazeTSchnitzel 15y ago
So just like how I authenticate with GitHub and SSH? That could be very useful.
gergles 15y ago
Probably because people want to be able to change browsers/computers without the bullshit of transferring around an SSL cert and doing so in a secure fashion?
- e1ven 15y ago
  Now that Firefox, Chrome and Safari all sync through various cloud accounts, is that really still an issue?
  - ceejayoz 15y ago
    Given that a good 50% or so use IE, yes?
    - e1ven 15y ago
      I believe Windows 8 has this built in, but doesn't have a critical mass yet.
  - Too 15y ago
    And how do you log in on that cloud account? Hen and chicken... Not a problem as long as you only have a fixed number of machines to use but once you start using other machines, family/friends/school/work/library you need a secure way to access the certs.
    - Too 15y ago
      egg and chicken of course :P
chc 15y ago
I think the bigger issue in general is that client certificates only authenticate the machine, not the user. That is, unless you password-protect the certificate — in which case you've only succeeded in adding a step to the process of getting into your site, a process that most commercial sites would like to streamline as much as possible because it's essentially a giant ramp in the middle of your funnel. Basically, even if the cost is marginal, so are the benefits for most sites — and although I haven't implemented this myself, I do not believe the cost would be marginal once you take into account all the new problems it creates.
- serge2k 15y ago
  Yup, plus you have the issue of users gettng a new machine and being totally lost. Or owning 2 machines. I suppose you could help that a bit. i.e. have a cert used for authentication, if it is not present then ask for the users info and offer to create a cert for next time.
- alexchamberlain 15y ago
  How absurd. This is 2 factor authentication... Validating something you have (ie the computer) and something you know(ie a password).
  - tehmeh 15y ago
    Except that in most "real" two-factor systems, you can't duplicate the second factor easily. The problem here is if the private key is in main memory, malware can copy it to another computer that will be indistinguishable (for the purposes of authentication) from the first. With something like a smartcard that is made much more difficult. Not impossible, but beyond the reach of most folks.
    - alexchamberlain 15y ago
      You have a point. I would like to see crypto chips on motherboards/in the CPU that can generate a key, export a public cert and then be asked to sign things. Then this vulnerability disappears.
seanalltogether 15y ago
I have now built 5 mobile banking apps for iOS / Andrdoid for 4 different clients. We have proposed this as a security measure to every app we've built so far. It is a perfect solution since many banks can now identify the user and ensure the the traffic is really coming from them. It also helps that since we're building custom apps, we don't have to rely on simple cookie+ssl based solution. Guess how many companies bite? Zero. None of them want to do it, and these are major nationwide banks. So much of their knowledge comes from handling browser based sessions that they can't imagine a different way.
- ajross 15y ago
  They're not insane though. Client certs, like ssh keys, aren't the whole storey. Users don't use the same browser all the time. How do you move a cert securely? How do you "move" a cert at all given that peer-to-peer transfer between devices basically hasn't worked for common users since the end of the floppy disk (seriously: try asking your aunt to copy a big PDF file from her computer to her iPad without broadband). Someone needs to do this in the browser. You'd need to put a (escrowed!) keyphrase on the cert, back it up to the cloud securely, associate it with the user's account in such a way that they can get to it. And then enough browsers need to support it to make it worthwhile. That's a tall order.
  - throwaway64 15y ago
    you never move a cert, just like you never move an ssh key. you simply generate a new one and add it to their auth, any time the user is using a new browser they have to go through extra authentication steps, and get issued a new cert for their browser (or not, on a public machine).
    - ww520 15y ago
      Usually what are the ways to authenticate the user when generating a new cert? A user moving to a new browser has to identify himself as the real user, thus requiring some sort of authentication. It's a chicken and egg thing.
zobzu 15y ago
And that is why they made stuff like browserid: - UI is slick - you don't need to remember to carry your certificate around, because while you complain about the UI do you think average joe who's scared by the preference button will actually .. copy his cert and carry it around? Please, get f. realistic for a moment, that is the real major useability issue. - it uses certs to authenticate to sites as well basically browserid provides a third party to store and manage certs for you and you can request them from anywhere without knowing anything about computing or security.
- e1ven 15y ago
  BroserID looks neat, but doesn't it rely on using external JS to hit browserid.org? I'm generally not in favor of adding additional 3rd party dependencies to my websites.
  - deleted 15y ago
    [deleted]
  - mcpherrinm 15y ago
    The long-term goal is to make the API supported by the browser itself. Consider the JS more like a "proof of concept", I think.
  - callahad 15y ago
    Kind of. We're suggesting that people link to the javascript shim on Mozilla's servers, while we refine the API, but we hope to support self-hosting by autumn. The entire system is designed to transparently drop away as identity providers and user agents implement native support for the BrowserID protocol, but for now we're supplying a shim implementation for the browsers and are acting as a trusted third party for identity providers. For how this plays out, imagine the following combinations of native support for the BrowserID protocol: 1) BROWSER AND IDENTITY PROVIDER: Mozilla's services are left completely out of the loop. 2) BROWSER ONLY: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user. 3) IDENTITY PROVIDER ONLY: Mozilla's shim and services step in to provide a surrogate implementation of the BrowserID protocol. 4) NEITHER: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user, and to provide a shimmed implementation of the BrowserID protocol. Again, the protocol was designed to be distributed from the very start, so nothing is locking it down to using Mozilla's shim and services, but they're there for you if you want to use them. Disclaimer: I do not currently work for Mozilla, but I will be joining the Identity team later this month.
lucb1e 15y ago
If it were possible to: 1) Synchronise the certificates automatically between every computer in the world; 2) Change user; and 3) Create multiple identities, I think this would indeed be used on a huge scale already. Traditional accounts do all of this: you can log in to your Gmail account from any computer in the world. You can sign out of your Gmail account and sign in with a different user. If you are feeling paranoid or scared about having no backup Gmail address, you can create a secondary account. Now you are probably able to use multiple certificates and maybe switch between them, but none of this has been made user-friendly. So that is the crux, browser builders (Microsoft, Mozilla, Apple, and--a bit later on--Google) just didn't pick this up. Still though, the first problem would remain. But don't I remember entering a password for my self-signed SSL certificate which I created for my Apache webserver? Couldn't you do something like that and generate a certificate based on a password? Like signing up for a website, only on browser level and for every website at the same time? Maybe there is actually future in this after all. This sounds good to me at least!
dfc 15y ago
The last time I tried to get apache to do authenticate with client certs it was an absolute nightmare.
- eCa 15y ago
  My experience as well. I tried to implement client side certificates for an internal system (changing computers/browsers/ugly UI/etc not an issue), but couldn't quite get it to work. And in that setting not worth the time compared to Basic Auth.
- spc476 15y ago
  I didn't find it being an absolute nightmare, but it wasn't trivial either. Here's the configuration that works for me: http://boston.conman.org/2009/03/02/siteconf.txt http://boston.conman.org/2009/03/02/siteconf.txt I also found that the Firefox Convergence add-on (which itself is a neat concept) breaks client certificates (which I keep forgetting, so when I hit the private areas of my secure server, I keep getting denied until I remember to disable Convergence).
lisper 15y ago
An alternative to browser certificates: http://dswi.net/ http://dswi.net/
- SMrF 15y ago
  This is indeed very simple. But I'm afraid this will evoke what I call the "crypto gag reflex" which in this case would be, "client-side javascript + crypto === BAD." How do you respond to this criticism? Is it valid in this case?
  - lisper 15y ago
    It's a very valid criticism, and it's the main reason that DSSID is not quite ready for prime time. I'm participating in a W3C working group trying to develop new browser standards that would allow secure client-side crypto with a better UI than client certificates. It's a very hard problem. But even in its present state I would argue that DSSID is at least as secure, and probably a great deal more secure, than any other extant authentication scheme out there. If you trust SSL, trust the DSSID server to be secure against write attacks (i.e. attacks that allow a hacker to change the content being served), and pay attention to the URL in your browser bar before entering your pass phrase, then DSSID is secure. (There's actually one other vulnerability, and that is malicious plug-ins, but no software-based security scheme can possibly be secure against that.) By way of contrast, with passwords, you have to trust EVERY SINGLE SITE that you log in to. You have to trust the certificate chain for every single site that you log in to. (With DSSID you only have to trust the certificate chain for your DSSID server.) You have to trust that every single site that you log in to has not had malicious Javascript injected. You have to pay attention to the URL of every single site you log in to, not just one. Most problematically, many HTTPS sites do not have valid certificates, which trains users to ignore warnings about invalid certificates, which essentially undermines ALL of the security of SSL. So having to only ever trust one certificate (which will always be valid) is a huge win. If DSSID were be broadly adopted it would become more secure. Once the code is stable enough, I am going to open-source the DSSID server code so that anyone can run their own DSSID server if they don't trust mine. The Javascript that is served from the DSSID server is static (except for the nonce) so it can be independently audited and verified. The DSSID protocol doesn't have to implemented in Javascript. You could write a plugin that implemented it, or build the capability into a browser. It's a lot easier to plug the holes in DSSID than anything else out there.
sriramk 15y ago
I have a bit of a history with SSL client certs; I'm the reason the Windows Azure management APIs all use SSL client certs for auth/security. Looking back, I think it's a bad idea. - Most developers don't understand them. - Library support for them is wonky - we've run into issues with curl, the PKI infrastructure in Windows and weird bugs up and down the stack - There is a lot of complexity around cert management - how do developers move it around machines, share with their team, etc. We had a lot of good reasons for using it and a lot of scenarios were made much easier still. But if I had to go back and have a do over, I would probably use OAuthv2 (which didn't exist then :) ).
- wmf 15y ago
  Weren't InfoCards like client certs with better UX? What happened there?
  - sriramk 15y ago
    Nobody adopted them (my opinion, not sure what the official take is). Don't think anybody understood them either.
    - ComputerGuru 15y ago
      That was one of the features I was most excited about in Windows Vista, and I was really sad that MS did not push them in way, shape, or form; or even make an effort to use them on their own web properties. I think they could have caught on at least as well as BrowserID will.
throwaway64 15y ago
What is even more baffling to me is many bank cards now incorporate smart card chips on them, yet are never used for online activities. Every desktop browser has decent support for card readers, hand all your customers a $5 card reader, and save millions a year on fraud.
- zokier 15y ago
  "never" is a strong word. I know at least one (fairly large in it's country) bank that does credit card based auth. And if there is one, there probably are others too.
- alexchamberlain 15y ago
  Every bank in the UK uses card readers.
recursive 15y ago
Probably because no one understands them. Using myself as an example, any time I've had to do any work with certs, I've had trouble figuring out how to get them to work at all. I'm no security expert, but neither are most devs.
rickette 15y ago
Well I frequently use client certs. My company develops and maintains an web-based application platform. The platform is only accessible using client certs and used daily by a couple of thousand people.
yalogin 15y ago
Usability and cost are the biggest concerns. It might even end up being less secure. You have to carry your key pair with you and import it into the browser anywhere you want to use it. You have to make sure you delete the key (securely, ideally) before leaving the machine. What is the guarantee that the machine you are trying to use is not compromised or holding on to your keys? Even then the website is not sure if its really you. They also need to implement a password based authentication. Some one stealing your keys is more possible (given that you want to login from any machine) than some stealing your password. Of course they can guess your password but I won't get into that. One way to do it would be to build a dongle that has keys and provides the authetication service on behalf of the user. But then we would need multiple identities, which means we need multiple certificates and the cost will multiply. Anonymity is completely gone. Even if the CA grants you an "anonymous" certificate it can always be traced back to you based on the cert parameters. So no.
Joeri 15y ago
IIS 5 used to have issues with client certificates. I remember random php process crashes when we tried using them.
emily37 15y ago
It seems that the only type of client cert we're likely to see in wide use on the web in the near future are origin-bound certificates (Google): http://www.browserauth.net/origin-bound-certificates http://www.browserauth.net/origin-bound-certificates The proposal is to automatically generate a self-signed cert for each origin. This gets rid of many of the UI problems: it eliminates the need to choose which cert to send to each site (which also means the user can't be tracked across sites via OBCs, and thus the user doesn't need to grant permission before sending his cert). On the other hand, it doesn't solve the problem of re-authenticating on different machines. It's not proposed as a primary authentication mechanism, but instead as a means of strengthening ordinary HTTP session cookies (http://www.browserauth.net/channel-bound-cookies http://www.browserauth.net/channel-bound-cookies).
- rektide 15y ago
  Given all the things the Google Chrome User-Agent does keep in sync across different User-Agent instances, I'd imagine keeping a host of origin-bound certs in sync wouldn't pose too great a challenge. I'd love to see BrowserAuth take off!
soumyadeb 15y ago
I don't necessarily agree with the perceived benefits highlighted in the article. i) No need to enter username and password: Yes, we won't have to enter those but the real problem is keeping track of multiple usernames/passwords, not entering them. Even if we implement certificate based authentication, we will probably need multiple of them. Single identity is unlikely to happen because of (a) Privacy - You won't want to use the same identity (username or certificate) on facebook and a .xxx site. (b) Security - Sites who care about security like banks would want stronger control on identity (e.g. by expiring passwords or certificates periodically) whereas other consumer facing sites would not. Given these reasons, single identity is not going to happen anytime soon. If keeping track of multiple usernames/passwords is a problem, think how hard would it be to keep track of multiple certificates. (ii) Two factor authentication: Well, just storing certificates in the browser/computer doesn't make it two factor authentication. The second factor in 2-factor should include something which is outside your computer such as a hardware token or your mobile phone. If you store your certificate in your laptop, the same malware which steals your password would steal it too. (iii) Delegation and revoking: OAuth already solves this problem. You don't give your facebook username/password to a third party site for it to access your profile. And you can revoke access anytime. Certificate based authentication is useful if you store them on some 3rd device like Smart Card or USB keys. There are a bunch of companies doing that but they mostly sell to enterprises. We don't want to carry multiple cards, right?
joeyh 15y ago
Several openid providers do use them to identify users. For example see link on https://www.myopenid.com/signin_password https://www.myopenid.com/signin_password Also, I've heard mention that Monkeysphere is working on something to generate client SSL certs that are tied to your gpg key. Which would allow logging into a site with one, based on the web of trust.
zorked 15y ago
SSL Client certificates can be easily and completely stolen by worms and botnets. So they can't be used by serious applications like online banking. For everything else, there are much simpler solutions.
- augustl 15y ago
  The certificate is public anyway, you'd need the private key as well in order to authenticate.
- daxelrod 15y ago
  Worms and botnets can steal passwords just as easily, and session cookies almost as easily. What do you consider appropriate for online banking?
- fl3tch 15y ago
  That problem is not specific to SSL client certs. It potentially affects every authentication mechanism (on the same computer). Typing in your passwords? Keylogger. Using a password manager? Stolen passwords. The password database is encrypted and you have to type in a password to decrypt it? Keylogger. If your system is rooted / infected with malware, you lost. The only solution is to format the drive and start over. The alternative is to use a 2 factor authentication mechanism that uses a separate device, like your phone receiving a text message. That's a pain for the average user, and certainly not "simpler".
  - 7952 15y ago
    People are very familiar with text messages. Its very easy to explain.
joeblau 15y ago
The U.S. Government is doing it. It's called PKI.
alexchamberlain 15y ago
Hacker News you have let yourself down. Half the comments on here are about moving certicates! YOU NEVER MOVE PRIVATE CRYPTOGRAPHIC CERTIFICCATES!
- luser001 15y ago
  Can you educate me? Are you saying that using something like 'openssl x509' to export a certificate as PKCS12 to import into my browser is a bad thing?
  - alexchamberlain 15y ago
    I'm not sure I fully understand. However, if the private key ever leaves your computer, it's a Bad Thing.
    - luser001 15y ago
      Hmm, what I described above is how a client certificate signed by a certificate authority is created. Random site that describes the procedure is below. What is the right way to do this? Exporting the private key of the certificate Enter the password of the private key, and then export the client key onto the generated client certificate using the following command: openssl pkcs12 -export -out client.pfx -inkey client.key -in client2.pem http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=%2Fcom.ibm.netcool_OMNIbus.doc%2Fprobes%2Fmicrosoft_scom%2Fmicrosoft_scom%2Fwip%2Freference%2Fmsscom_gnrt-clnt-crt.html http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index...
- tehmeh 15y ago
  Not to be too pedantic here -- but what do you mean by "PRIVATE CRYPTOGRAPHIC CERTIFICATES"? Certificates are intended to be public. Private keys are intended to be private. They are not equivalent although they are certainly related.
  - pyre 15y ago
    They work as a pair. If you access from a different machine you need the private key on that machine. You can't just copy the public key over to that machine and expect it to work.
CPlatypus 15y ago
It's the classic chicken and egg problem. Few sites use them because they correctly believe that the browser configuration is too painful for most people. The browser configuration remains painful because users aren't pressuring browser makers, and they're not pressuring browser makers because they don't use any sites that make such configuration necessary. It won't change until (a) enough sites require client certs despite the painful configuration or (b) browser makers take some initiative to make configuring them less painful. Neither seems very likely.
- wmf 15y ago
  (b) is sort of happening, but with a new protocol (BrowserID).
Duff 15y ago
The process for installing client certs is wonky. We setup a PKI to authenticate computers and allow us to use SCCM inside or outside of the firewall -- it works great. I tried to get other folks to use it, but people equate cert with complexity and money and their eyes roll back into their heads if you mention PKI.
pilif 15y ago
I'm the author of this, now quite dated, article and by now I really don't agree with its contents any more - at least not fully: 1) this is not truly two-factor authentication as the certificate is stored right there on the machine I'm using for authentication. If this would ever get widespread use, we'd have issues with malware extracting the key from the browser. Not even password-protecting the key (giving you something comparable to SSH authentication) would help much as malware presumably has access to your memory anyways. 2) With the problems inherent to the SSL protocol in conjunction with renegotiation (http://www.kb.cert.org/vuls/id/120541 http://www.kb.cert.org/vuls/id/120541), this becomes a bit annoying because you can't safely have resources for which you check a client certificate on the same server as resources where you don't. Remember: The article predates the vulnerability by a year. 3) More and more people are beginning to have multiple devices they use. There's not even a "main" machine any more. Not having access to the client-side certificate is annoying though with the various browser syncing solutions out there, this might become a non-issue over time. None the less. My personal complaint about the overly complicated UI still stands - heck, this is even annoying for me and I would (aside of point 2 above) have good use for this at times - but clicking through this jungle of dialog boxes remains annoying to this date.
- jdwhit2 15y ago
  Would this be able to handle multiple accounts for the same website? Or would you use a separate browser for each account?
  - wmf 15y ago
    The browser could ask you which cert to present, but as the saying goes, now you have N problems.
  - oomkiller 15y ago
    Chrome and Safari prompt you (at least on OS X, not sure about others) which certificate you want to use if there are multiple matches.
    - 15y ago
rincewind 15y ago
Can anyone recommend a good smart card device that works with openssl and firefox?
dpratt 15y ago
I've used client certs several times, but not necessarily to authenticate a user. We have a few mobile apps with a public facing HTTPS API endpoint. Currently, we have it set up to use a client cert that we ship with the app itself to 'secure' the connection between the app and the server. In reality, it's no more secure than embedding a username/password in the app itself and using basic auth. It was slightly tricky to get the iOS/Android programmatic HTTP layers to properly format and present the cert to an auth challenge, but since we figured that out, it's been seamless.
augustl 15y ago
Apple uses client certificates for their APNS API (push notifications). Both to verify that you can actually send push, and to identify which app and environment (dev or production) you're sending push for. I have also used client certificates for a number of computer-to-computer systems. So client certificates are being used, even though people aren't using them in their browsers.
trotsky 15y ago
because pki is hard
- joeblau 15y ago
  LOL, I was going to write this. I worked on Government PKI for 4 years. Most enlightening security course ever.
topbanana 15y ago
We used client certs in my last project, a private cloud document storage API. Big mistake! I probably spent a quarter of my time helping other teams organise their certs.
bonaldi 15y ago
It's bizarre that we're reduced to forms-based authentication. Surely even basic authentication could be improved to include the basic signup/forgotten flows. Odd that this crucial UX is so overlooked by browser devs.
netanimus 15y ago
It is just like signing certificates for servers of any type but the subject is you. I recommend using P12 as most browsers will 'just get it'. With Nginx for example, you can build in SSL support and then configure a directive to request a client cert at which point the web browser will load a relevant certificate to choose to pass along. More so, Nginx can be configured to extract information from the client certificate and use it as variables. http://wiki.nginx.org/HttpSslModule#ssl_client_certificate http://wiki.nginx.org/HttpSslModule#ssl_client_certificate http://wiki.nginx.org/HttpSslModule#Built-in_variables http://wiki.nginx.org/HttpSslModule#Built-in_variables So one can have ssl.awesome.io and extract info to only allow 'Joe231' to see ssl.awesome.io/Joe231. Even better is by serial or what have you. Now my 2 cents on the problem; it confuses people, revocation and issuance. I'm guessing here DoD had certificates built into our ID cards and that was extracted with the reader at a need. Not sure, just a guess. Personally I think the cryptic nature that is command line Openssl is what slows down the mob from pushing new tech unto everyone. Think about it. Some comments present are disappointing for hacker news; you should be playing with cryptic technologies and making them work. Want a startup idea? Plop certs into AXE body spray cans and done. oh looky what Wikipedia cited: http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html
nikcub 15y ago
It creates a support headache. I have rolled out client certs on a number of projects, the first over 10 years ago. I now know the perfect project that suits client certificates: authenticating work computers in high-risk transactions where you have a small base of users (500-5000). In one scenario even with 500 users we would get 2-3 support calls per day regarding the certificates. And having Verisign set us up as an intermediary with an ability to sign client certs was very expensive.
- alexchamberlain 15y ago
  You could use openssl or openca for free....
  - nikcub 15y ago
    customers were banks so they wanted the brand name
wdr1 15y ago
We used SSL client certificates for the 2008 Olympics ticketing systems. What a nightmare. It's hard to know how much to blame on Windows & how much has changed since then, but they were a never ending source of pain. We had to provision & manage 1,000+ workstations, dispersed not only through Beijing, but all of China. We couldn't find a way to install the certs as part of the imaging processing, so we attempted to automate as much as we can. Only on Windows (XP, I believe) you couldn't automate the entire installation. So we had to print up instructions & try to make it understandable to bank tellers. (Olympic point of sales where located at various Bank of China branches.) Additionally, each certificate was store with a specific window account. So either accounts had to be shared, or we had to provision each machine for the dozens of tellers who might use it. (As well as making sure the process was easy when someone new started. And that the certs were revoked when they left. Again ugh.) BTW, did you know that Java on Windows XP w/ the Chinese language pack has a different default classpath than Chinese Window XP? One of the other joys we discovered. Actually, maybe the morale of the story here isn't client certs, but rather that Windows does.
nickzoic 15y ago
I've implemented two projects using SSL Client Certificates in the last few years, and one of them, a B2B kind of thing, has been live for a couple of years with several hundred customers using it day-to-day. Some times it works great, and other times it is an intractable pain, and the browser UI is a pain, and the end user doesn't really understand it at all. These are not high-tech people. They don't put passwords on their keyrings, they forget they're there, they buy new computers and give the old ones away and then their new PC doesn't work and they panic! For a small number of customers (<1%) it never really works on at least one of their PCs and I have no idea why. I think it is a bit of a chicken and egg problem: no-one uses them because no-one understands them, and no-one understands them because no-one uses them. The certificate management UI is also awful, which doesn't help.
seanp2k2 15y ago
I think that we can pretty much all agree that SSL is the new WEP; broken beyond repair. If you don't believe me, try using OpenSSL in C. Very relevant: https://en.wikipedia.org/wiki/X.509#Security https://en.wikipedia.org/wiki/X.509#Security

255 points by e1ven 15y ago

I did this one time at home to share some files quickly somewhat securely, and sent my friend a cert to install. It worked fine. At my Fortune 500 of course the wifi has certs, but they don't do any certs for authentication (er, unless you count drive encryption and NT security?) but no HTTPS ... of course SSL for user keys, but no "authorized clients" style of client based keys. I think it is probably the perceived overhead of operating your own CA, even though modern web app like interfaces exist and make doing such a thing a breeze. It could be that the less technical people like architects (that don't have to implement it themselves) just assume that it'll be too much of a conceptual thing to try and sell. It works tho! And seems like it would be in theory more secure given the features of revocation, but I guess that's the same as turning off someone's ID in the directory perhaps.

pagekalisedown 15y ago

Ancient article. But as a side note, startssl.com uses them very effectively.

mappu 15y ago
They do, indeed, and they provide a great service. However, if you have two accounts there, logging out and logging in again causes IE9 to just re-use the same certificate instead of prompting you again.

acheron 15y ago

I found the headline funny: my job for the past 3 months or so has been heavily involved with SSL client certs. Of course, it's on a private network, not the Internet, so that makes it easier. (By which I mean "easier to force the clients to use them", not actually easier to use.) I absolutely agree the browser interface for certs is terrible. The post is from 4 years ago, and the interface still looks just the same, and is still just as much of a pain in the rear. I would take this over "What color was your first car?" any day, though.

TazeTSchnitzel 15y ago

So just like how I authenticate with GitHub and SSH? That could be very useful.

gergles 15y ago

Probably because people want to be able to change browsers/computers without the bullshit of transferring around an SSL cert and doing so in a secure fashion?

e1ven 15y ago
Now that Firefox, Chrome and Safari all sync through various cloud accounts, is that really still an issue?
- ceejayoz 15y ago
  Given that a good 50% or so use IE, yes?
  - e1ven 15y ago
    I believe Windows 8 has this built in, but doesn't have a critical mass yet.
- Too 15y ago
  And how do you log in on that cloud account? Hen and chicken... Not a problem as long as you only have a fixed number of machines to use but once you start using other machines, family/friends/school/work/library you need a secure way to access the certs.
  - Too 15y ago
    egg and chicken of course :P

chc 15y ago

I think the bigger issue in general is that client certificates only authenticate the machine, not the user. That is, unless you password-protect the certificate — in which case you've only succeeded in adding a step to the process of getting into your site, a process that most commercial sites would like to streamline as much as possible because it's essentially a giant ramp in the middle of your funnel. Basically, even if the cost is marginal, so are the benefits for most sites — and although I haven't implemented this myself, I do not believe the cost would be marginal once you take into account all the new problems it creates.

serge2k 15y ago
Yup, plus you have the issue of users gettng a new machine and being totally lost. Or owning 2 machines. I suppose you could help that a bit. i.e. have a cert used for authentication, if it is not present then ask for the users info and offer to create a cert for next time.
alexchamberlain 15y ago
How absurd. This is 2 factor authentication... Validating something you have (ie the computer) and something you know(ie a password).
- tehmeh 15y ago
  Except that in most "real" two-factor systems, you can't duplicate the second factor easily. The problem here is if the private key is in main memory, malware can copy it to another computer that will be indistinguishable (for the purposes of authentication) from the first. With something like a smartcard that is made much more difficult. Not impossible, but beyond the reach of most folks.
  - alexchamberlain 15y ago
    You have a point. I would like to see crypto chips on motherboards/in the CPU that can generate a key, export a public cert and then be asked to sign things. Then this vulnerability disappears.

seanalltogether 15y ago

I have now built 5 mobile banking apps for iOS / Andrdoid for 4 different clients. We have proposed this as a security measure to every app we've built so far. It is a perfect solution since many banks can now identify the user and ensure the the traffic is really coming from them. It also helps that since we're building custom apps, we don't have to rely on simple cookie+ssl based solution. Guess how many companies bite? Zero. None of them want to do it, and these are major nationwide banks. So much of their knowledge comes from handling browser based sessions that they can't imagine a different way.

ajross 15y ago
They're not insane though. Client certs, like ssh keys, aren't the whole storey. Users don't use the same browser all the time. How do you move a cert securely? How do you "move" a cert at all given that peer-to-peer transfer between devices basically hasn't worked for common users since the end of the floppy disk (seriously: try asking your aunt to copy a big PDF file from her computer to her iPad without broadband). Someone needs to do this in the browser. You'd need to put a (escrowed!) keyphrase on the cert, back it up to the cloud securely, associate it with the user's account in such a way that they can get to it. And then enough browsers need to support it to make it worthwhile. That's a tall order.
- throwaway64 15y ago
  you never move a cert, just like you never move an ssh key. you simply generate a new one and add it to their auth, any time the user is using a new browser they have to go through extra authentication steps, and get issued a new cert for their browser (or not, on a public machine).
  - ww520 15y ago
    Usually what are the ways to authenticate the user when generating a new cert? A user moving to a new browser has to identify himself as the real user, thus requiring some sort of authentication. It's a chicken and egg thing.

zobzu 15y ago

And that is why they made stuff like browserid: - UI is slick - you don't need to remember to carry your certificate around, because while you complain about the UI do you think average joe who's scared by the preference button will actually .. copy his cert and carry it around? Please, get f. realistic for a moment, that is the real major useability issue. - it uses certs to authenticate to sites as well basically browserid provides a third party to store and manage certs for you and you can request them from anywhere without knowing anything about computing or security.

e1ven 15y ago
BroserID looks neat, but doesn't it rely on using external JS to hit browserid.org? I'm generally not in favor of adding additional 3rd party dependencies to my websites.
- deleted 15y ago
  [deleted]
- mcpherrinm 15y ago
  The long-term goal is to make the API supported by the browser itself. Consider the JS more like a "proof of concept", I think.
- callahad 15y ago
  Kind of. We're suggesting that people link to the javascript shim on Mozilla's servers, while we refine the API, but we hope to support self-hosting by autumn. The entire system is designed to transparently drop away as identity providers and user agents implement native support for the BrowserID protocol, but for now we're supplying a shim implementation for the browsers and are acting as a trusted third party for identity providers. For how this plays out, imagine the following combinations of native support for the BrowserID protocol: 1) BROWSER AND IDENTITY PROVIDER: Mozilla's services are left completely out of the loop. 2) BROWSER ONLY: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user. 3) IDENTITY PROVIDER ONLY: Mozilla's shim and services step in to provide a surrogate implementation of the BrowserID protocol. 4) NEITHER: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user, and to provide a shimmed implementation of the BrowserID protocol. Again, the protocol was designed to be distributed from the very start, so nothing is locking it down to using Mozilla's shim and services, but they're there for you if you want to use them. Disclaimer: I do not currently work for Mozilla, but I will be joining the Identity team later this month.

lucb1e 15y ago

If it were possible to: 1) Synchronise the certificates automatically between every computer in the world; 2) Change user; and 3) Create multiple identities, I think this would indeed be used on a huge scale already. Traditional accounts do all of this: you can log in to your Gmail account from any computer in the world. You can sign out of your Gmail account and sign in with a different user. If you are feeling paranoid or scared about having no backup Gmail address, you can create a secondary account. Now you are probably able to use multiple certificates and maybe switch between them, but none of this has been made user-friendly. So that is the crux, browser builders (Microsoft, Mozilla, Apple, and--a bit later on--Google) just didn't pick this up. Still though, the first problem would remain. But don't I remember entering a password for my self-signed SSL certificate which I created for my Apache webserver? Couldn't you do something like that and generate a certificate based on a password? Like signing up for a website, only on browser level and for every website at the same time? Maybe there is actually future in this after all. This sounds good to me at least!

dfc 15y ago

The last time I tried to get apache to do authenticate with client certs it was an absolute nightmare.

eCa 15y ago
My experience as well. I tried to implement client side certificates for an internal system (changing computers/browsers/ugly UI/etc not an issue), but couldn't quite get it to work. And in that setting not worth the time compared to Basic Auth.
spc476 15y ago
I didn't find it being an absolute nightmare, but it wasn't trivial either. Here's the configuration that works for me: http://boston.conman.org/2009/03/02/siteconf.txt http://boston.conman.org/2009/03/02/siteconf.txt I also found that the Firefox Convergence add-on (which itself is a neat concept) breaks client certificates (which I keep forgetting, so when I hit the private areas of my secure server, I keep getting denied until I remember to disable Convergence).

lisper 15y ago

An alternative to browser certificates: http://dswi.net/ http://dswi.net/

SMrF 15y ago
This is indeed very simple. But I'm afraid this will evoke what I call the "crypto gag reflex" which in this case would be, "client-side javascript + crypto === BAD." How do you respond to this criticism? Is it valid in this case?
- lisper 15y ago
  It's a very valid criticism, and it's the main reason that DSSID is not quite ready for prime time. I'm participating in a W3C working group trying to develop new browser standards that would allow secure client-side crypto with a better UI than client certificates. It's a very hard problem. But even in its present state I would argue that DSSID is at least as secure, and probably a great deal more secure, than any other extant authentication scheme out there. If you trust SSL, trust the DSSID server to be secure against write attacks (i.e. attacks that allow a hacker to change the content being served), and pay attention to the URL in your browser bar before entering your pass phrase, then DSSID is secure. (There's actually one other vulnerability, and that is malicious plug-ins, but no software-based security scheme can possibly be secure against that.) By way of contrast, with passwords, you have to trust EVERY SINGLE SITE that you log in to. You have to trust the certificate chain for every single site that you log in to. (With DSSID you only have to trust the certificate chain for your DSSID server.) You have to trust that every single site that you log in to has not had malicious Javascript injected. You have to pay attention to the URL of every single site you log in to, not just one. Most problematically, many HTTPS sites do not have valid certificates, which trains users to ignore warnings about invalid certificates, which essentially undermines ALL of the security of SSL. So having to only ever trust one certificate (which will always be valid) is a huge win. If DSSID were be broadly adopted it would become more secure. Once the code is stable enough, I am going to open-source the DSSID server code so that anyone can run their own DSSID server if they don't trust mine. The Javascript that is served from the DSSID server is static (except for the nonce) so it can be independently audited and verified. The DSSID protocol doesn't have to implemented in Javascript. You could write a plugin that implemented it, or build the capability into a browser. It's a lot easier to plug the holes in DSSID than anything else out there.

sriramk 15y ago

I have a bit of a history with SSL client certs; I'm the reason the Windows Azure management APIs all use SSL client certs for auth/security. Looking back, I think it's a bad idea. - Most developers don't understand them. - Library support for them is wonky - we've run into issues with curl, the PKI infrastructure in Windows and weird bugs up and down the stack - There is a lot of complexity around cert management - how do developers move it around machines, share with their team, etc. We had a lot of good reasons for using it and a lot of scenarios were made much easier still. But if I had to go back and have a do over, I would probably use OAuthv2 (which didn't exist then :) ).

wmf 15y ago
Weren't InfoCards like client certs with better UX? What happened there?
- sriramk 15y ago
  Nobody adopted them (my opinion, not sure what the official take is). Don't think anybody understood them either.
  - ComputerGuru 15y ago
    That was one of the features I was most excited about in Windows Vista, and I was really sad that MS did not push them in way, shape, or form; or even make an effort to use them on their own web properties. I think they could have caught on at least as well as BrowserID will.

throwaway64 15y ago

What is even more baffling to me is many bank cards now incorporate smart card chips on them, yet are never used for online activities. Every desktop browser has decent support for card readers, hand all your customers a $5 card reader, and save millions a year on fraud.

zokier 15y ago
"never" is a strong word. I know at least one (fairly large in it's country) bank that does credit card based auth. And if there is one, there probably are others too.
alexchamberlain 15y ago
Every bank in the UK uses card readers.

recursive 15y ago

Probably because no one understands them. Using myself as an example, any time I've had to do any work with certs, I've had trouble figuring out how to get them to work at all. I'm no security expert, but neither are most devs.

rickette 15y ago

Well I frequently use client certs. My company develops and maintains an web-based application platform. The platform is only accessible using client certs and used daily by a couple of thousand people.

yalogin 15y ago

Usability and cost are the biggest concerns. It might even end up being less secure. You have to carry your key pair with you and import it into the browser anywhere you want to use it. You have to make sure you delete the key (securely, ideally) before leaving the machine. What is the guarantee that the machine you are trying to use is not compromised or holding on to your keys? Even then the website is not sure if its really you. They also need to implement a password based authentication. Some one stealing your keys is more possible (given that you want to login from any machine) than some stealing your password. Of course they can guess your password but I won't get into that. One way to do it would be to build a dongle that has keys and provides the authetication service on behalf of the user. But then we would need multiple identities, which means we need multiple certificates and the cost will multiply. Anonymity is completely gone. Even if the CA grants you an "anonymous" certificate it can always be traced back to you based on the cert parameters. So no.

Joeri 15y ago

IIS 5 used to have issues with client certificates. I remember random php process crashes when we tried using them.

emily37 15y ago

It seems that the only type of client cert we're likely to see in wide use on the web in the near future are origin-bound certificates (Google): http://www.browserauth.net/origin-bound-certificates http://www.browserauth.net/origin-bound-certificates The proposal is to automatically generate a self-signed cert for each origin. This gets rid of many of the UI problems: it eliminates the need to choose which cert to send to each site (which also means the user can't be tracked across sites via OBCs, and thus the user doesn't need to grant permission before sending his cert). On the other hand, it doesn't solve the problem of re-authenticating on different machines. It's not proposed as a primary authentication mechanism, but instead as a means of strengthening ordinary HTTP session cookies (http://www.browserauth.net/channel-bound-cookies http://www.browserauth.net/channel-bound-cookies).

rektide 15y ago
Given all the things the Google Chrome User-Agent does keep in sync across different User-Agent instances, I'd imagine keeping a host of origin-bound certs in sync wouldn't pose too great a challenge. I'd love to see BrowserAuth take off!

soumyadeb 15y ago

I don't necessarily agree with the perceived benefits highlighted in the article. i) No need to enter username and password: Yes, we won't have to enter those but the real problem is keeping track of multiple usernames/passwords, not entering them. Even if we implement certificate based authentication, we will probably need multiple of them. Single identity is unlikely to happen because of (a) Privacy - You won't want to use the same identity (username or certificate) on facebook and a .xxx site. (b) Security - Sites who care about security like banks would want stronger control on identity (e.g. by expiring passwords or certificates periodically) whereas other consumer facing sites would not. Given these reasons, single identity is not going to happen anytime soon. If keeping track of multiple usernames/passwords is a problem, think how hard would it be to keep track of multiple certificates. (ii) Two factor authentication: Well, just storing certificates in the browser/computer doesn't make it two factor authentication. The second factor in 2-factor should include something which is outside your computer such as a hardware token or your mobile phone. If you store your certificate in your laptop, the same malware which steals your password would steal it too. (iii) Delegation and revoking: OAuth already solves this problem. You don't give your facebook username/password to a third party site for it to access your profile. And you can revoke access anytime. Certificate based authentication is useful if you store them on some 3rd device like Smart Card or USB keys. There are a bunch of companies doing that but they mostly sell to enterprises. We don't want to carry multiple cards, right?

joeyh 15y ago

Several openid providers do use them to identify users. For example see link on https://www.myopenid.com/signin_password https://www.myopenid.com/signin_password Also, I've heard mention that Monkeysphere is working on something to generate client SSL certs that are tied to your gpg key. Which would allow logging into a site with one, based on the web of trust.

zorked 15y ago

SSL Client certificates can be easily and completely stolen by worms and botnets. So they can't be used by serious applications like online banking. For everything else, there are much simpler solutions.

augustl 15y ago
The certificate is public anyway, you'd need the private key as well in order to authenticate.
daxelrod 15y ago
Worms and botnets can steal passwords just as easily, and session cookies almost as easily. What do you consider appropriate for online banking?
fl3tch 15y ago
That problem is not specific to SSL client certs. It potentially affects every authentication mechanism (on the same computer). Typing in your passwords? Keylogger. Using a password manager? Stolen passwords. The password database is encrypted and you have to type in a password to decrypt it? Keylogger. If your system is rooted / infected with malware, you lost. The only solution is to format the drive and start over. The alternative is to use a 2 factor authentication mechanism that uses a separate device, like your phone receiving a text message. That's a pain for the average user, and certainly not "simpler".
- 7952 15y ago
  People are very familiar with text messages. Its very easy to explain.

joeblau 15y ago

The U.S. Government is doing it. It's called PKI.

alexchamberlain 15y ago

Hacker News you have let yourself down. Half the comments on here are about moving certicates! YOU NEVER MOVE PRIVATE CRYPTOGRAPHIC CERTIFICCATES!

luser001 15y ago
Can you educate me? Are you saying that using something like 'openssl x509' to export a certificate as PKCS12 to import into my browser is a bad thing?
- alexchamberlain 15y ago
  I'm not sure I fully understand. However, if the private key ever leaves your computer, it's a Bad Thing.
  - luser001 15y ago
    Hmm, what I described above is how a client certificate signed by a certificate authority is created. Random site that describes the procedure is below. What is the right way to do this? Exporting the private key of the certificate Enter the password of the private key, and then export the client key onto the generated client certificate using the following command: openssl pkcs12 -export -out client.pfx -inkey client.key -in client2.pem http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=%2Fcom.ibm.netcool_OMNIbus.doc%2Fprobes%2Fmicrosoft_scom%2Fmicrosoft_scom%2Fwip%2Freference%2Fmsscom_gnrt-clnt-crt.html http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index...
tehmeh 15y ago
Not to be too pedantic here -- but what do you mean by "PRIVATE CRYPTOGRAPHIC CERTIFICATES"? Certificates are intended to be public. Private keys are intended to be private. They are not equivalent although they are certainly related.
- pyre 15y ago
  They work as a pair. If you access from a different machine you need the private key on that machine. You can't just copy the public key over to that machine and expect it to work.

CPlatypus 15y ago

It's the classic chicken and egg problem. Few sites use them because they correctly believe that the browser configuration is too painful for most people. The browser configuration remains painful because users aren't pressuring browser makers, and they're not pressuring browser makers because they don't use any sites that make such configuration necessary. It won't change until (a) enough sites require client certs despite the painful configuration or (b) browser makers take some initiative to make configuring them less painful. Neither seems very likely.

wmf 15y ago
(b) is sort of happening, but with a new protocol (BrowserID).

Duff 15y ago

The process for installing client certs is wonky. We setup a PKI to authenticate computers and allow us to use SCCM inside or outside of the firewall -- it works great. I tried to get other folks to use it, but people equate cert with complexity and money and their eyes roll back into their heads if you mention PKI.

pilif 15y ago

I'm the author of this, now quite dated, article and by now I really don't agree with its contents any more - at least not fully: 1) this is not truly two-factor authentication as the certificate is stored right there on the machine I'm using for authentication. If this would ever get widespread use, we'd have issues with malware extracting the key from the browser. Not even password-protecting the key (giving you something comparable to SSH authentication) would help much as malware presumably has access to your memory anyways. 2) With the problems inherent to the SSL protocol in conjunction with renegotiation (http://www.kb.cert.org/vuls/id/120541 http://www.kb.cert.org/vuls/id/120541), this becomes a bit annoying because you can't safely have resources for which you check a client certificate on the same server as resources where you don't. Remember: The article predates the vulnerability by a year. 3) More and more people are beginning to have multiple devices they use. There's not even a "main" machine any more. Not having access to the client-side certificate is annoying though with the various browser syncing solutions out there, this might become a non-issue over time. None the less. My personal complaint about the overly complicated UI still stands - heck, this is even annoying for me and I would (aside of point 2 above) have good use for this at times - but clicking through this jungle of dialog boxes remains annoying to this date.

jdwhit2 15y ago
Would this be able to handle multiple accounts for the same website? Or would you use a separate browser for each account?
- wmf 15y ago
  The browser could ask you which cert to present, but as the saying goes, now you have N problems.
- oomkiller 15y ago
  Chrome and Safari prompt you (at least on OS X, not sure about others) which certificate you want to use if there are multiple matches.
  - 15y ago

rincewind 15y ago

Can anyone recommend a good smart card device that works with openssl and firefox?

dpratt 15y ago

I've used client certs several times, but not necessarily to authenticate a user. We have a few mobile apps with a public facing HTTPS API endpoint. Currently, we have it set up to use a client cert that we ship with the app itself to 'secure' the connection between the app and the server. In reality, it's no more secure than embedding a username/password in the app itself and using basic auth. It was slightly tricky to get the iOS/Android programmatic HTTP layers to properly format and present the cert to an auth challenge, but since we figured that out, it's been seamless.

augustl 15y ago

Apple uses client certificates for their APNS API (push notifications). Both to verify that you can actually send push, and to identify which app and environment (dev or production) you're sending push for. I have also used client certificates for a number of computer-to-computer systems. So client certificates are being used, even though people aren't using them in their browsers.

trotsky 15y ago

because pki is hard

joeblau 15y ago
LOL, I was going to write this. I worked on Government PKI for 4 years. Most enlightening security course ever.

topbanana 15y ago

We used client certs in my last project, a private cloud document storage API. Big mistake! I probably spent a quarter of my time helping other teams organise their certs.

bonaldi 15y ago

It's bizarre that we're reduced to forms-based authentication. Surely even basic authentication could be improved to include the basic signup/forgotten flows. Odd that this crucial UX is so overlooked by browser devs.

netanimus 15y ago

It is just like signing certificates for servers of any type but the subject is you. I recommend using P12 as most browsers will 'just get it'. With Nginx for example, you can build in SSL support and then configure a directive to request a client cert at which point the web browser will load a relevant certificate to choose to pass along. More so, Nginx can be configured to extract information from the client certificate and use it as variables. http://wiki.nginx.org/HttpSslModule#ssl_client_certificate http://wiki.nginx.org/HttpSslModule#ssl_client_certificate http://wiki.nginx.org/HttpSslModule#Built-in_variables http://wiki.nginx.org/HttpSslModule#Built-in_variables So one can have ssl.awesome.io and extract info to only allow 'Joe231' to see ssl.awesome.io/Joe231. Even better is by serial or what have you. Now my 2 cents on the problem; it confuses people, revocation and issuance. I'm guessing here DoD had certificates built into our ID cards and that was extracted with the reader at a need. Not sure, just a guess. Personally I think the cryptic nature that is command line Openssl is what slows down the mob from pushing new tech unto everyone. Think about it. Some comments present are disappointing for hacker news; you should be playing with cryptic technologies and making them work. Want a startup idea? Plop certs into AXE body spray cans and done. oh looky what Wikipedia cited: http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html

nikcub 15y ago

It creates a support headache. I have rolled out client certs on a number of projects, the first over 10 years ago. I now know the perfect project that suits client certificates: authenticating work computers in high-risk transactions where you have a small base of users (500-5000). In one scenario even with 500 users we would get 2-3 support calls per day regarding the certificates. And having Verisign set us up as an intermediary with an ability to sign client certs was very expensive.

alexchamberlain 15y ago
You could use openssl or openca for free....
- nikcub 15y ago
  customers were banks so they wanted the brand name

wdr1 15y ago

We used SSL client certificates for the 2008 Olympics ticketing systems. What a nightmare. It's hard to know how much to blame on Windows & how much has changed since then, but they were a never ending source of pain. We had to provision & manage 1,000+ workstations, dispersed not only through Beijing, but all of China. We couldn't find a way to install the certs as part of the imaging processing, so we attempted to automate as much as we can. Only on Windows (XP, I believe) you couldn't automate the entire installation. So we had to print up instructions & try to make it understandable to bank tellers. (Olympic point of sales where located at various Bank of China branches.) Additionally, each certificate was store with a specific window account. So either accounts had to be shared, or we had to provision each machine for the dozens of tellers who might use it. (As well as making sure the process was easy when someone new started. And that the certs were revoked when they left. Again ugh.) BTW, did you know that Java on Windows XP w/ the Chinese language pack has a different default classpath than Chinese Window XP? One of the other joys we discovered. Actually, maybe the morale of the story here isn't client certs, but rather that Windows does.

nickzoic 15y ago

I've implemented two projects using SSL Client Certificates in the last few years, and one of them, a B2B kind of thing, has been live for a couple of years with several hundred customers using it day-to-day. Some times it works great, and other times it is an intractable pain, and the browser UI is a pain, and the end user doesn't really understand it at all. These are not high-tech people. They don't put passwords on their keyrings, they forget they're there, they buy new computers and give the old ones away and then their new PC doesn't work and they panic! For a small number of customers (<1%) it never really works on at least one of their PCs and I have no idea why. I think it is a bit of a chicken and egg problem: no-one uses them because no-one understands them, and no-one understands them because no-one uses them. The certificate management UI is also awful, which doesn't help.

seanp2k2 15y ago

I think that we can pretty much all agree that SSL is the new WEP; broken beyond repair. If you don't believe me, try using OpenSSL in C. Very relevant: https://en.wikipedia.org/wiki/X.509#Security https://en.wikipedia.org/wiki/X.509#Security