I've got a comodo signed SSL certificate that I'm trying to use with stunnel4 to allow secure NNTP connections from a wide variety of clients. The certificate at least partially works; if I leave 'verify' off in the stunnel.conf file, then the service runs and users can connect, albeit while still having to verify the cert. But if I turn 'verify' on, then it doesn't work on *either* side.
I've tried playing with CAfile and CApath without much luck. I'll attach my configuration files, the relevant pems, and some debugging information; is there something else I'm missing? I've already contacted comodo, and after several rounds of conversation they suggest I contact the list.
Errors from the client side (note that I'm using a debug port here):
+ openssl s_client -connect news:565 -verify -debug verify depth is 0 CONNECTED(00000003) depth=2 /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 6976:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:951:
...and on the server, I get this:
2008.06.30 14:08:38 LOG7[10039:47679267941088]: nntps accepted FD=7 from 171.64.19.111:56122 2008.06.30 14:08:38 LOG7[10039:1073809760]: nntps started 2008.06.30 14:08:38 LOG7[10039:1073809760]: FD 7 in non-blocking mode 2008.06.30 14:08:38 LOG7[10039:1073809760]: FD 8 in non-blocking mode 2008.06.30 14:08:38 LOG7[10039:1073809760]: FD 9 in non-blocking mode 2008.06.30 14:08:38 LOG7[10039:47679267941088]: Cleaning up the signal pipe 2008.06.30 14:08:38 LOG6[10039:47679267941088]: Child process 10247 finished with code 0 2008.06.30 14:08:38 LOG7[10039:1073809760]: Connection from 171.64.19.111:56122 permitted by libwrap 2008.06.30 14:08:38 LOG5[10039:1073809760]: nntps connected from 171.64.19.111:56122 2008.06.30 14:08:38 LOG7[10039:1073809760]: SSL state (accept): before/accept initialization 2008.06.30 14:08:38 LOG7[10039:1073809760]: SSL state (accept): SSLv3 read client hello A 2008.06.30 14:08:38 LOG7[10039:1073809760]: SSL state (accept): SSLv3 write server hello A 2008.06.30 14:08:38 LOG7[10039:1073809760]: SSL state (accept): SSLv3 write certificate A 2008.06.30 14:08:38 LOG7[10039:1073809760]: SSL state (accept): SSLv3 write certificate request A 2008.06.30 14:08:38 LOG7[10039:1073809760]: SSL state (accept): SSLv3 flush data 2008.06.30 14:08:38 LOG7[10039:1073809760]: SSL alert (read): fatal: unknown CA 2008.06.30 14:08:38 LOG3[10039:1073809760]: SSL_accept: 14094418: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca 2008.06.30 14:08:38 LOG5[10039:1073809760]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2008.06.30 14:08:38 LOG7[10039:1073809760]: nntps finished (0 left)
Basic Requested Information that wasn't supplied above:
* stunnel 4.18-2 on Debian etch (2.6.18-6-686 #1 SMP) * Running standalone with '/usr/bin/stunnel4 /etc/news/stunnel.conf' * libc6, no gcc, OpenSSL 0.9.8c-4etch3 * The log on startup:
2008.06.30 14:00:15 LOG7[26276:3083523776]: Snagged 64 random bytes from /root/.rnd 2008.06.30 14:00:15 LOG7[26276:3083523776]: Wrote 1024 new random bytes to /root/.rnd 2008.06.30 14:00:15 LOG7[26276:3083523776]: RAND_status claims sufficient entropy for the PRNG 2008.06.30 14:00:15 LOG7[26276:3083523776]: PRNG seeded successfully 2008.06.30 14:00:15 LOG7[26276:3083523776]: Configuration SSL options: 0x01000000 2008.06.30 14:00:15 LOG7[26276:3083523776]: SSL options set: 0x01000000 2008.06.30 14:00:15 LOG7[26276:3083523776]: Certificate: /etc/ssl/certs/news-stunnel.pem 2008.06.30 14:00:15 LOG7[26276:3083523776]: Certificate loaded 2008.06.30 14:00:15 LOG7[26276:3083523776]: Key file: /etc/ssl/private/news-stunnel.key 2008.06.30 14:00:15 LOG7[26276:3083523776]: Private key loaded 2008.06.30 14:00:15 LOG7[26276:3083523776]: Loaded verify certificates from /etc/ssl/certs/comodo.cert 2008.06.30 14:00:15 LOG7[26276:3083523776]: SSL context initialized for service nntps
- Tim Skirvin ([email protected])