On Thu, Aug 22, 2024 at 08:21:30AM -0000, atritium--- via stunnel-users wrote:

In a TLS handshake, the server presents the signed public key (certificate from a CA) to the client...

...usually that's not exactly what happens. In the vast majority of cases (mostly excluding self-signed certificates) the server presents several things: - its own public key, signed by the CA (or, more often, by an intermediate key that the CA rotates every now and then) - the public key that the CA used to sign the server's key (usually that is the intermediate key mentioned above) - the public key that the CA used to sign that public key in its turn - etc...

So what is usually presented is a so-called "certificate chain", something like: - server.example.com - CA intermediate cert rotated every year or so - CA root cert that is valid for a period of ten years or more

The most important part here is the CA root certificate: it is something that the CA presents to the world, hoping that OS and browser vendors will include it in their list of trusted root certificates. That certificate's private key is usually kept somewhere really secure, and it is not used in day-to-day operations - it is only taken out to sign a new intermediate certificate.

The CA intermediate certificate is the one that the CA uses in day-to-day operations like "let's sign the certificate of this new customer" or "let's revoke that certificate, the customer said it's no longer valid". Hence, it usually has a much shorter validitiy period, since there is a higher (still low, but higher) probability of its being compromised. Since it has a shorter lifetime, OS and browser vendors do not feel the need to include it in their trusted store, and neither do they need to.

The idea here is that a TLS client (be it a browser or stunnel) will have some way to know that the CA's root certificate is indeed a trusted one. Once that has been established, the TLS client will verify the signature on the intermediate certificate, and then it will verify the signature on the server's certificate, and it will know that everything is well since all this starts from a known-good certificate.

The most often encountered exception to this scenario is the case when an organization (or a government, or whatever) does not want to trust any of the "well-established" CAs (sometimes for good reasons, sometimes merely for convenience which may be a good reason in itself - up to a point). So that organization sets its own CA up: - they create a public/private keypair - they create a certificate containing that public key - they sign that certificate *using its own private key*, thus making what is known as a self-signed certificate - that signed certificate is now the organization CA's root certificate: it may be used to sign an intermediate one, or it may be used to sign server (or client) certificates directly - the organization now has to ensure that all the TLS clients that will connect to its servers have that root certificate in their trusted CA store

Once that final step has been done, all TLS clients will trust all certificates signed by the organization's root one, so they will be able to use its resources.

...to use so that it doesn't have to be pre-existing in a file on the arbitrary systems making connections.

You are correct that the server's own certificate does not need to be stored on a client's system. However, the client should have *something* to start from when determining whether to trust the server's certificate; that something is the root certificate of the CA. Sometimes you may not notice this, since your OS and your browser and sometimes other applications carry their own list of trusted root CA certificates, and TLS libraries (e.g. OpenSSL) may be configured to look at that list automatically. If you have access to a Linux system, it will most probably have a package called "ca-certificates" installed - take a look at the files that it contains; that's the list of the root CA certificates that most programs running on that system will trust automatically.

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.

Well... not exactly. The name of the "CAfile" option (and the related "CApath" and "CAengine" options) itself suggests that this is the path to the CA's root certificate, not the server's certificate itself. The point is that stunnel expects the server to provide a so-called "certificate bundle" containing the certificate chain - its own, the one that signed its own, the one that signed that latter one, etc, all the way up to the CA's root certificate... which stunnel can check is the same as the one in the CAfile (or one of those in the CApath directory), so it knows it can trust the whole thing.

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 (?)

If you are trying to set up a new service and you find that stunnel does not trust the certificate that it provides, I'm going to take a guess and say that your server only provides its own certificate, not the whole bundle. If the certificates are stored in the PEM format, then making the bundle is a simple matter of concatenating them - making one file that contains all of the other files, one after the other. However, you may need to check the documentation of your server software and your CA to figure out which certificates to put in the bundle and how to tell the server to send that.

...wait, are you trying to use stunnel as the server itself? Argh, okay, well, most of what I wrote above also pertains to that case, but if we're talking about stunnel sending the certificate bundle to the client, that's not a matter of CAfile, CApath, or CAengine; take a look at the documentation of the "cert" option:

cert = CERT_FILE certificate chain file name

The parameter specifies the file containing certificates used by stunnel to authenticate itself against the remote client or server. The file should contain the whole certificate chain starting from the actual server/client certificate, and ending with the self-signed root CA certificate. The file must be either in PEM or P12 format.

A certificate chain is required in server mode, and optional in client mode.

...and there you go: you must build a certificate bundle and specify its path using the "cert" option for your service; then stunnel will send that whole bundle to the client, so that the latter is able to verify everything along the chain.

Hope that helps!

G'luck, Peter

Please read the stunnel documentation at stunnel.org. The HOWTO will mostly solve your doubts, but take kook at the examples and read the manual page if you want to fo do something more advanced.

In summary, in server mode stunnel will present it’s server certificate to the client and the process will work just like in a browser, as long as the server cert is signed by a certificate authority trusted by the client the process will work. Actually, the client does not need a certificate, unless you want the server to authenticate the client, and in this case the server only need to know the CAs that signed the client cert, not the specific cert that the client have.

Regards Jose

On 22/08/2024, at 4:00 AM, atritium--- via stunnel-users stunnel-users@stunnel.org wrote:

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 (?) _______________________________________________ stunnel-users mailing list -- stunnel-users@stunnel.org To unsubscribe send an email to stunnel-users-leave@stunnel.org