All of the sTunnel guides and implementations at work do the same thing, they say once the private key and the public cert are created on the server, you need to cat them together and then share with the client host.

While this makes perfect sense to me with the public cert (as client will encrypt data using it) surely sharing the private key goes against the whole SSL ethos?

  • You're deriving the server's public/private key pair or signing a client's public key?
    – RoraΖ
    Feb 3 '16 at 15:49
  • sorry, what do you mean? could you rephrase?
    – Jamie
    Feb 3 '16 at 16:30
  • 1
    Please give us a link to one of those sTunnel guides. Feb 3 '16 at 16:32
  • see the heading "Combining the two files" and then "Copy the certificate file from server to client" @ bencane.com/2014/02/18/…
    – Jamie
    Feb 3 '16 at 16:34
  • Are you generating a server's SSL certificate, or are you generating a client's SSL certificate?
    – RoraΖ
    Feb 3 '16 at 16:35

Stunnel is SSL and, in SSL, private keys never need to travel. The "SSL ethos" is that X.509 certificates are used to authenticate peers without a pre-distributed shared secret. For example, when you connect your Web browser to https://example.com, the SSL layer recognizes the server certificate and can make sure that it talks to the real "example.com" without needing prior knowledge about that specific site.

Stunnel is out of this model, since it is typically used between two machines that already know each other. This allows lighter models to be used.

By default, stunnel does not validate certificates. This is stated as so in the HOWTO page (in the "How does stunnel check certificates?" section). If you did not change that setting, then it does not matter at all what certificates you use. Of course, not validating certificates leaves the tunnel vulnerable to Man-in-the-Middle attacks. This can still be acceptable, from a security point of view, if the tunnel is meant to convey only an underlying protocol that already includes cryptographic protection; typically, you use stunnel to get through a school/company firewall, but inside you just run some SSH. The stunnel is there only to keep the firewall unwary of the SSHish nature of the communication. In that specific case, not validating certificates is fine. (Well, fine with regards to your security. You are still circumventing your school/company firewall, which is morally and legally questionable.)

Most stunnel guides explain how to configure stunnel in that no-verification mode, and copying the certificate on both client and server is the most expedient way to keep things running.

If you configure stunnel to validate certificates, then:

  • The client must be able to check that the server's certificate (the certificate is the public part, NOT the private key), which entails either knowing it beforehand, or verifying its signature with regards to a known CA.

  • When the client has verified that the server's certificate is genuine, it must still check that it is the certificate of the intended server.

  • If the server requests a certificate from the client, it must similarly be able to verify it, and check that it corresponds to an allowed client.

There is no code in stunnel that compares the client and server certificates with each other. They really live in distinct worlds; the client certificate is validated on the server, the server certificate is validated on the client. Having the same certificate on both systems has no influence whatsoever on the behaviour of either.

In a certificate-check system, if both the client and server use the same certificate, then the client may impersonate the server, and vice versa. If there are only two machines, then this does not matter much. If there are more machines (e.g. two clients to connect on the same server) then this can matter a lot (you do not necessarily want to allow a client to frame another client with a fake server). And, of course, sharing the private key implies that the private key travelled from one machine to the other, which either used a preexisting tunnel (e.g. SSH), or was a risky operation. Private keys should remain private, and the more a private key travels, the less private it becomes.

  • thank you for this response - i still dont understand why the private key is shared though. If all the client needs to do is verify the server identity and encrypt the handshake data using the servers public key/certificate, why share the private key in the pem file? whether you trust the client or not, it seems unnecessary
    – Jamie
    Feb 5 '16 at 9:53
  • What I want to setup is a configuration where: 1) each client that connects to my sTunnel server will use its own unique certificate, I will have put these in the trusted path of my sTunnel server and the sTunnel server .conf will have: verify = 3 and CAfile=/trustedpath containing the various client certificates 2) the server will also have a certificate ( i believe this is required in server mode ) that each client will need to save to their CAfile trusted location in order to verify i am the intended server)
    – Jamie
    Feb 5 '16 at 10:16
  • questions: am I correct with my logic? will this provide two-way identification? what is to stop one client or someone who obtains my server public certificate from posing as the server once it has it? (not sharing the private key is surely the only protection here?). When i copy the certificate from client to server and vice versa in order to place in CAfile trusted path, according to all guides, it is concatenated into a PEM file with the private key ( hence my original question ) - surely I shouldnt be sharing this private key with the client? ( for reasons above)
    – Jamie
    Feb 5 '16 at 10:23


If you want to use client certificate authentication, then you need to copy the client's private key and certificate to the client from the certificate authority.

If you want to allow clients to authenticate a server, then you need to copy the server's private key and certificate from the certificate authority to the server.

Exactly how you want to authenticate the remote end impacts on what other resources are needed where. Taking the simplest case of a client connecting anonymously (i.e. no client certificate) to a server, the client can

  • not require any validation of the servers credentials
  • validate that the servers certificate was signed by CA the client already knows about (i.e. for which it has the CA certificate)
  • validate that the presented certificate matches a locally stored copy

SSL is all about a menage-a-trois between the server, client and certificate authority.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.