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?
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.
No.
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
SSL is all about a menage-a-trois between the server, client and certificate authority.
