3 ms·
The arguments against client-side TLS certificates boil down to complex UI and maintainability, but it does have its uses. At small to medium sized companies i
by Freak_NL 10y ago
The arguments against client-side TLS certificates boil down to complex UI and maintainability, but it does have its uses.
At small to medium sized companies it isn't uncommon to host a number of self-hosted services, such as GitLab, MatterMost, some wiki, perhaps OwnCloud, the list goes on. Securing all these services takes some non-trivial effort, even if you manage to get all services talking to your local LDAP server (we did!). Only recently GitLab advised users of the self-hosted solution to upgrade ASAP due to a security issue.
To cut ourselves some slack, we placed all these services behind an Nginx proxy. That proxy is secured with client-side TLS certificates. So if you try to access https://chat.example.com https://chat.example.com without it, you just get a friendly error message (actually, you get a picture of Grumpy Cat saying 'no', but you get the idea). With certificate, you get the service you wanted to access. You still need to log on with the service, but that's usually just a matter of doing it once and ticking the 'remember me' checkbox or something similar. For our users it just works.
Generating new certificates and revoking old ones is fairly simple for the administrators (couple of scripts, ample documentation).
The arguments against public use still stand of course, but for this scenario it is a great solution.
- unscaled 10y agoI've made the same set-up us well for private services hosted on public IPs which we couldn't put behind a VPN, but I have to say admit this process is not without its own pains. Nginx for one, didn't have client-certificate support for proxying until fairly recently, and many HTTP proxies and tools still don't. Even when there is support, you might run into some interesting corners cases, since this is a niche functionality, e.g. if you combine an Nginx with an Azure-hosted web app. Both work great in isolation, but not together, do to the strange tricks Azure is doing with TLS renegotiation.
- jdc0589 10y ago> I've made the same set-up us well for private services hosted on public IPs which we couldn't put behind a VPN, but I have to say admit this process is not without its own pains. In the process of doing the exact same thing, and decided on client certs/mutual-auth.
- 234dd57d2c8db 10y agoI do the same thing but with SSH. I like using SSH as the proxy because it supports other protocols besides HTTP and people generally already have SSH keys, and I don't have to manage another daemon just to provide authentication with yet another set of public/private keys. Just have your service listing on 127.0.0.1 and have SSH listening on 0.0.0.0 and proxy in!
- na85 10y agoI had a pgp key years, almost a decade, before I could be arsed to use an ssh key