[pimlottc]

I feel your pain. Two-way TLS is a funny thing, it's supported by the standards and even most implementations but its actual use is minuscule compared to "normal" one-way TLS, so much so that it's hard to find documentation even acknowledging two-way TLS exists, let alone how to use it.

And don't get me started about the hassles of obtaining signed certificates that are actually usable for client auth...

[tetha]

Would you be interested in some articles about his? A lot of our infrastructure bases trust around self-signed CA chains and mutual TLS authentication in different configurations, mostly involving elastic stacks, vault, nomad, consul - and we're migrating a lot of the cert handling to be fully automated. We're also extending this to a number of our java applications as well.

I might be able to shed some light on there, as this topic isn't actually that hard. It just requires some very careful thinking.

[tialaramex]

> And don't get me started about the hassles of obtaining signed certificates that are actually usable for client auth...

What sort of clients were you authenticating? The Web PKI needs to be trusted by random people from the whole world, but most mutually authenticated systems have a relatively small number of clients which are known to the server operator out-of-band. So probably the Web PKI is not the right choice. Instead you (the server operator or some neutral facilitator if it's a group of providers operating services for the same clients) should operate a CA for this purpose, not piggyback on the Web PKI.

One reason not to use the Web PKI if you aren't actually part of the public Internet is that we, to put it bluntly, don't give a shit about people who do that. Running a PKI is expensive (not just in dollar terms, it needs a bunch of smart, motivated people who are morally upright or it's worthless), and this one is ours, so it obeys our rules.

If you have your own PKI (or just one CA) you set the rules. Fifty year certificates for 1024-bit RSA? Why not. A current passport photograph baked into every certificate? Sure. Want the issuer to mint the keys and keep a copy? Do as you please. All those things are prohibited in the Web PKI.

[richardwhiuk]

Ignoring the Web PKI defaults though is probably a silly idea - e.g. long lived certificates with rubbish hash algorithms, huge certificates, and issuer kept keys are all really bad ideas, in almost any scenario.

[taftster]

Most two-way implementations are generally privately controlled. You can act as your own certification authority and sign both the client and server certificates for a private communication.

Totally curious, it sounds like you were going for a traditionally signed certificate approach. So you had clients that you didn't "own" -- normal Joe Public -- using your service? If so, that is definitely way outside the norm. If not, why didn't you just sign your own certs?

[the_clarence]

That's what the Noise protocol framework is for.

[munchbunny]

For client auth, assuming you control the server, would it be easier to just issue your own and install the root on the server?