4 ms·
They're used in a whole bunch of industries, but not in the sexy ones. Renewal is the most important issue. Certificate stores often suck and for tokens there
by jeroenhd 1y ago
They're used in a whole bunch of industries, but not in the sexy ones.
Renewal is the most important issue. Certificate stores often suck and for tokens there are various existing protocols for re-issuing expiring ones. For certificates, you're stuck doing your own thing.
For local applications, UI/UX of the system supposedly in charge of certs is often absolutely terrible. I've had the displeasure of working with Java key stores and I'd rather rewrite the auth mechanism than deal with that bullshit again.
The use case they would perform excellently in (centrally managed corporate networks) are also the places where you will find terrible middleboxes that will kill any protocol they don't understand.
TLS client certificates could've been what passkeys are today, and they could've been what OAuth2 tokens have become, but the terrible development experience killed them off before they could bloom. I mostly blame web browsers, who didn't bother improving their UI for certificates after the day they first implemented them. Hacking OAuth2 on top of HTTPS calls is pretty easy compared to figuring out how to refresh a user certificate.
- pixl97 1y agoJava keystores for user clients are just a nightmare. So much if my time is used up helping customers that don't understand how they work.
- thayne 1y agoIt's a nightmare for using a custom CA for server certs too. You can't just add a new CA, you have to rebuild the entire keystore. And then you need to do it again every time you update the JVM, or risk missing updates to the default keystore. For some reason the keystore is required to be protected by a password, even if it doesn't contain any secret keys. The documentation for the tools that manage keystores is incomplete and sometimes out of date. The whole thing is a relic from another time and could really use some modernization.
- jeroenhd 1y agoThere are workarounds for that, by specifying a custom key store file and overriding the socket factory to force it to load your keys. Unfortunately, most example code for SSL socket factories just disable TLS validation entirely. So yes, your custom CA now works reliably, but unfortunately so do self-signed certificates if you're not careful. Luckily, modern Java doesn't need keystores anymore. Unfortunately, half the world seems stuck on Java 8.
- pixl97 1y ago>most example code for SSL socket factories just disable TLS validation entirely. I see this happen in large enterprise far more often than it should, like the kind of business where disabling SSL is a baaaad idea for the kind of attacks they're apt to get.
- benced 1y agoJava KeyStore is so awful, I cannot believe it became a thing. It single-handedly disqualified Spinnaker (the Netflix K8s deployment thing) for me.
- ojhughes 1y agonetty-tcnative can remove the need for a Java keystore in Netty based applications https://netty.io/wiki/forked-tomcat-native.html https://netty.io/wiki/forked-tomcat-native.html
- aragilar 1y agoThe other challenge is proxies. When the backend that cares about client cert is behind a proxy you need to dig into the less-familiar parts of the proxy and try to work out either how to pass the certificate on or extract the information from it.
- jeroenhd 1y agoThe typical solution for reverse proxies is to extract the relevant information and pass it on as either custom headers or environment variables. That works fine, assuming you make sure to ignore the headers the client might send to take that information, of course. It's pretty easy to set up in Apache and Nginx at least. For forward proxies, the only option is to either accept the connection unaltered or to drop the connection entirely.
- aragilar 1y agoYeah, it's not bad when the backend will accept headers (e.g. remote_user), it's when it wants the actual certificate to check against a CA when it becomes an issue.