(Note: Android info here may be dated, as I last tested with 2.0, and applies only to the stock Android distribution not apps or patched versions supplied by vendors.)
- Microsoft Windows: Perfect support, though it requires PKCS#12 (.p12) format certificates. Most 3rd party apps (subversion, mozilla apps, etc) use own cert stores rather than the OS's for no good reason.
- Mac OS X: Limited support in OS keychain. No support in OS services like Apple Mail (IMAP+TLS, IMAPs, SMTP+TLS or SMTPs), WebDAV over HTTPs, etc so I have no idea why they even bothered adding support to keychain. Some apps have their own support, eg Mozilla apps via NSS, but OS has none and most Apple apps have none. No 3rd party apps seem to look in the system keystore for certificates.
- Linux systems: All major SSL/TLS libraries have support, but there's no system-wide or desktop-wide keystore or key management. Netscape security suite apps have good support but certificates must be installed individually in each app - even though the underlying libnss library supports a shared user-account-level security store. GnuTLS- and OpenSSL-using apps must implement their own certificate management but can support client certificates if they provide appropriate callbacks. As a result, support is very app dependent and often buggy or very clumsy. Real-world support is inconsistent - eg Subversion supports client certs, but many svn front ends don't handle the cert prompts; Thunderbird & Firefox support client certs via NSS; Evolution supports via NSS but has broken nss init code that breaks client certificates and is often built with GnuTLS instead of NSS anyway; etc. Overall it's painful but usually usable.
- Symbian (Series 60) phones: Support is perfect in OS and apps. Very smooth.
- Sony Ericsson phones: Seem to have no concept of client certificates, and treat request for client cert by remote mail server as an SSL/TLS error.
- Windows Mobile phones: Basically perfect from all reports. Pity about the rest of the OS.
- Apple iPhone: Decent client cert store support. Unclear how much access 3rd party apps have. It's used for safari. Reported broken in Mail (comment by Martin).
- Android phones: are a near-total information void. Apparently it's just assumed you'll use Google's services, not (say) your own secure mail server with your work. Because, you know, who needs confidentiality anyway? If you download the SDK and phone emulator, you'll quickly find out that not only does the OS lack any way to import a client certificate or use one in negotiation, but it lacks any way to even import new CA certificates. That's stunningly, jaw-droppingly pathetic. Of course, this is a phone with a read-only IMAP client so it's not clear what, exactly, it's meant to do...
Update: It looks like there's half-baked and mostly user-inaccessible support for importing CA certificates in some flavours of Android. This app exploits the facility. Client certificates don't appear to be so blessed.
FYI, client certs have never worked for Mail on the iPhone, including current iOS v4.
ReplyDeleteGlad to see someone who understands at all what a client certificate is. Searches and questions about this in the iPhone universe always come up with countless people who are trying to figure out their puny self-signed server certs.
Still doesn't seem to work for me with iOS 5.1. Furthermore, I can't find any alternative iOS MUA that supports client certs! Exasperating …
DeleteThanks.
ReplyDeleteI'm bewildered by the issue. Client certs are easy to implement support for as all SSL/TLS libraries provide simple routines to use them and/or a full keystore. They're simple to use in apps that don't completely fail to add the few lines of code generally required to turn on pre-existing support for them. They're incredibly flexible. They provide two-factor auth when combined with simple password auth, so they really should be all the rage these days. For bonus points, PKCS#11 smartcards can be used so the key doesn't even live on the host when not in use, and you get to give your employees shiny USB keyring fobs. Or, if you want to keep it simple and cheap, you can just install PKCS#12 certs.
I suspect part of the poor uptake is the insane prices charged by "big" CAs if you want per-user client certs from a widely recognised CA. Don't even think about getting a sub-CA for your business; you can't afford it. And if you want smartcards or USB keystores ... woah.
The lack of good tools for managing private (self-signed) CAs for businesses is another factor. There's OpensSSL and CA.pl or your own hand-rolled shell scripts, but that's not something you can give the average Windows Server sysadmin and expect them to be able to use it. I really should write something, as I've become fairly familiar with the Java crypto APIs and with OpenSSL.
Don't suppose you know of any decent apps for managing private CAs?
You can dramatically simplify and extend the use of X.509 certificates by using them in a decentralised way, ie: without CAs. For this you need to look at WebID http://esw.w3.org/Foaf%2Bssl
ReplyDeleteSee, especially the client section there, and the FAQ
http://esw.w3.org/Foaf%2Bssl/FAQ
There are a number of browser bugs that if fixed would make x.509 even more widely useable. But one can go a long way with what is available now. It just requires a change of perspective...
I can see FOAF being useful for a subset of use cases. It's still a pity that traditional client certs, which are *extremely* useful in controlled environments like company networks, are so poorly supported.
ReplyDelete