4 ms·
They are also not trivial for webdevs to implement, since the webapp usually doesn't terminate the TLS connection itself.
by lawl 9y ago
They are also not trivial for webdevs to implement, since the webapp usually doesn't terminate the TLS connection itself.
- gruez 9y agoIs that really an issue? AFAIK on nginx you can have it forward the certificate in a header.
- andrewaylett 9y agoIt's an issue if you use a CDN or other platform-provided TLS terminator; they don't usually support client certificates. And even if you _can_ support it in your reverse proxy and put the certificate details in a header, that's a very different server-side interface from terminating the client TLS connection in the service itself.
- parliament32 9y agoWouldn't that make it easier? In an nginx use case, nginx handles verification and termination, and just passes a user identifier variable back to the origin.
- GordonS 9y agoThe web server usually handles that side of things. The big problems you have are private key generation, certificate distribution, revocation, renewal, and guiding your users on how to install the damn things.
- orf 9y agoSo now your authentication logic lives in your Nginx config. That's not great, and it's not where it should be.
- orf 9y agoSo now your authentication logic lives in your Nginx config, a rather odd language with it's own fair share of quirks. That's not great and it's not where the logic conceptually fits.
- slrz 9y agoYou generally setup the reverse proxy to pass the required information to the backend via some trusted mechanism (e.g. HTTP headers not settable through client requests).