In a TLS handshake, the server presents the signed public key (certificate from a CA) to the client to use so that it doesn't have to be pre-existing in a file on the arbitrary systems making connections.
Am I correct that stunnel does NOT do this?
It appears stunnel clients MUST have a pre-existing -file- containing the server's signed public key and pointed at in the config file's CAfile setting. Sort of like "authorized_keys" file for ssh, except the certificates have short lifespans before going invalid.
This makes authentication unworkable for services that could have thousands of semi-random people connecting, especially with certificate lifespans creeping down to 1 year and probably months. Even if the certificate was bundled in the initial stunnel set-up, remote clients would have to constantly be updating the file.
If this is correct, I wonder why stunnel doesn't handle the TLS handshake like a browser and supply the current server public certificate for the client to authenticate. It seems like stunnel is presupposing a handful of clients in close contact who can be constantly fed current certificates to place in files on their machine. Really limits usability of the tool.
Or maybe I am missing something (?)