Hello, we were using Stunnel 4.25 for a long time without any problems.
We used "verify=3". Our client config file:
service = stunnel-client cert = client.pem socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 verify = 3 CApath = certificates CAfile = CAcert.pem client = yes [rdp] accept = 3398 connect = XX.XX.XX.XX:3398
But after switching to Stunnel 4.34 (preserving configuration) we started to get errors:
2010.11.25 13:13:30 LOG5[8332:5336]: Service rdp-database accepted connection from 127.0.0.1:30082 2010.11.25 13:13:30 LOG5[8332:5336]: connect_blocking: connected 95.130.236.42:3398 2010.11.25 13:13:30 LOG5[8332:5336]: Service rdp-database connected remote server from XX.XX.XX.XX:30083 2010.11.25 13:13:30 LOG5[8332:5336]: Certificate accepted: depth=1, /C=UA/ST=Lviv/L=Lviv region/O=ROSS/OU=IT/emailAddress=bla@bla.com 2010.11.25 13:13:30 LOG4[8332:5336]: CERT: Certificate not found in local repository 2010.11.25 13:13:30 LOG4[8332:5336]: Certificate check failed: depth=0, /C=UA/ST=Lviv/L=Lviv region/O=ROSS/OU=IT/CN=OURSERVER/emailAddress=bala@bla.com 2010.11.25 13:13:30 LOG3[8332:5336]: SSL_connect: 14090086: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 2010.11.25 13:13:30 LOG5[8332:5336]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
Main error is: CERT: Certificate not found in local repository
Looks like stunnel cannot find the hashed server's certificate in C:\Program Files\stunnel\certificates (CApath = certificates)
We tried specifying full paths, but it does not help. Switching to "verify=2" (do not check server's cert) works ok. Also stunnel 4.25 (with verify=3) works ok on this configuration.
Could you help? Ross
Ross wrote:
Hello, we were using Stunnel 4.25 for a long time without any problems.
[cut]
But after switching to Stunnel 4.34 (preserving configuration) we started to get errors:
Did you upgrade OpenSSL as well?
http://www.openssl.org/news/changelog.html
*) Enhance the hash format used for certificate directory links. The new form uses the canonical encoding (meaning equivalent names will work even if they aren't identical) and uses SHA1 instead of MD5. This form is incompatible with the older format and as a result c_rehash should be used to rebuild symbolic links. [Steve Henson]
Mike