All,
Okay, this turned out to be a "moving too fast" mistake on my part. If I had been reading the signs, I would have noticed that:
1. With the old certificate in the CAfile, I got "expired cert" error when the client attempted to connect
2. With the new certificate in the CAfile (but not the old one), I got "CERT: Pre-verification error: self signed certificate"
Stupid me: the client was still sending the old cert. I confirmed with a tcpdump+Wireshark+export dance.
A couple of things:
1. This error message is wildly misleading. The appropriate error message here should have been "certificate is not trusted". Can we maybe get a patch that provides the operator with a clear error message in this case?
2. When debug=7 (its most chatty), the presented client's certificate is not dumped to the log even though it's pretty important information to debug a failing connection. Can we add that to the debug(7) logging output? I happen to have had tcpdump and Wireshark already installed in the necessary locations, and the expertise to know how to use them (except I had to Google for how to export the cert from the dump to a file to read its contents), but (a) not everyone has that capability and (b) it's a total PITA when it would be trivial to dump the PEM certificate to the log.
Thanks! -chris
On 5/14/22 08:04, Christopher Schultz wrote:
All,
I'm running stunnel 4.56 as a server on Linux, as I have been doing for a while. I require clients to connect using their own client certs and yesterday one of them expired. The client generated a new certificate and sent it to me to install, and I'm getting the error in the subject.
Version details: $ sudo stunnel -help stunnel 4.56 on x86_64-koji-linux-gnu platform Compiled/running with OpenSSL 1.0.2k-fips 26 Jan 2017 Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
I have set verify=4 because I expect to place the exact certificate for every client into my CAFile.
This has been working for years, and when I connect using openssl s_client, I can see which client certificates the server advertises it will allow to connect, and they reflect what I expect.
The server certificate is also self-signed, so I copied that into the CAFile and I'm able to connect with openssl s_client using that certificate. So I think the problem can't be that the client's certificate is self-signed.
So, to recap:
- stunnel in server mode
- CAFile points to a collection of PEM certs
- verify=4
- I can connect with my own valid, trusted, self-signed certificate
- Client cannot connect with their valid, trusted, self-signed cert
Any ideas?
(Note: the client DOES appear to be using their new certificate, though I can only see the subject text which could be the same, yet with a different actual certificate.)
Here is the debug(7) output from an attempted connection:
: Starting certificate verification: depth=0, [subject] : CERT: Pre-verification error: self signed certificate : Certificate check failed: depth=0, [subject] : SSL alert (write): fatal: unknown CA : SSL_accept: 14089086: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed : Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Thanks, -chris