You are here: Foswiki>Tasks Web>Item14205 (18 Feb 2017, GeorgeClark)Edit Attach

Item14205: Autoconfig Email failing with recent versions of IO::Socket::SSL.

pencil
Priority: Urgent
Current State: Closed
Released In: 2.1.3
Target Release: patch
Applies To: Engine
Component: Configure, FoswikiNet
Branches: Item14205 Release02x01 master
Reported By: GeorgeClark
Waiting For:
Last Change By: GeorgeClark
If tested with the normal STARTTLS, TLS, SMTP sequence, the wizard decides on TLS. It should be selecting STARTTLS. Below debug log is reported only if modifying the wizard to ONLY attempt STARTTLS.

IO::Socket::SSL 2.019 Works IO::Socket::SSL 2.024 fails, and the latest - IO::Socket::SSL 2.038 also fails.

It seems to be performing hostname verification even when verification is disabled.

Testing STARTTLS with NO host verification on smtp port (25) Net::SMTP>>> SSL peer verification: off
Net::SMTP>>> Provide Client Certificate: off
Net::SMTP<<< Connected with 192.168.1.8:25 using no encryption
Net::SMTP<<< 220 myserver ESMTP Postfix
Net::SMTP>>> EHLO myhost
Net::SMTP<<< 250-myserver
Net::SMTP<<< 250-PIPELINING
Net::SMTP<<< 250-SIZE 24480000
Net::SMTP<<< 250-ETRN
Net::SMTP<<< 250-STARTTLS
Net::SMTP<<< 250-AUTH PLAIN xxxxxxxxxxxxxxxx
Net::SMTP<<< 250-AUTH=PLAIN LOGIN
Net::SMTP<<< 250-ENHANCEDSTATUSCODES
Net::SMTP<<< 250-8BITMIME
Net::SMTP<<< 250 DSN
Net::SMTP>>> STARTTLS
Net::SMTP<<< 220 2.0.0 Ready to start TLS
DEBUG: .../IO/Socket/SSL.pm:1460: start handshake 
DEBUG: .../IO/Socket/SSL.pm:649: ssl handshake not started 
DEBUG: .../IO/Socket/SSL.pm:682: using SNI with hostname 192.168.1.8 
DEBUG: .../IO/Socket/SSL.pm:717: request OCSP stapling 
DEBUG: .../IO/Socket/SSL.pm:738: set socket to non-blocking to enforce timeout=30 
DEBUG: .../IO/Socket/SSL.pm:764: ssl handshake in progress 
DEBUG: .../IO/Socket/SSL.pm:774: waiting for fd to become ready: SSL wants a read first 
DEBUG: .../IO/Socket/SSL.pm:794: socket ready, retrying connect 
DEBUG: .../IO/Socket/SSL.pm:2615: local error: hostname verification failed 
DEBUG: .../IO/Socket/SSL.pm:757: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:757: ignoring less severe local error 'SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed', keep 'hostname verification failed' DEBUG: .../IO/Socket/SSL.pm:760: fatal SSL error: hostname verification failed

Although all connections were successful, the service is not speaking SMTP.
The most likely causes are that the server uses a non-standard port for SMTP, or your configuration erroneously specifies a non-SMTP port. Check your configuration; then check with your server support.
-- GeorgeClark - 02 Nov 2016

VadimBelman found the issue. It appears that in addition to setting SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_NONE(), you also have to set verify_hostname => 0 in the socket options. This also applies to Net.pm.

Also discovered while testing, that it was not possible to run the wizard from the tools/configure and get any output. For some reason the capture of STDERR is not being released.
  • Changed AutoconfigureEmail.pm to bypass capture for CLI and undefined engine. No real need to capture STDERR anyway, just let it go to the console.
  • Changed tools/configure to use STDOUT instead of STDERR. The output from the configure tool is not error output.

-- GeorgeClark - 03 Nov 2016

And now that I've locally fixed it and done further testing, fix doesn't work. STARTTLS still fails on recent IO::Socket::SSL.

-- GeorgeClark - 03 Nov 2016

And it seems to be more than just the hostname verification. Even with that code in SSL.pm commented out, it fails with the other connection errors. This does seem to be specific to the autoconfig code though, as a manually configured STARTSSL connection seems to work.

-- GeorgeClark - 03 Nov 2016

There are several things going on here:
  • The capture code for some reason doesn't release the capture. Resolved it by implementing the MuteExec code written by VadimBelman in his branch.
  • In recent versions of IO::Socket::SSL, it seems to always attempt validation, even when configured to not validate. No solution to that yet, but there were two issues contributing to the validation failures:
    • The Host IP was used instead of hostname in the test. IP addresses won't pass certificate hostname validation.
    • There was no code to guess the SSL CA certificate bundle or path. (Resolved by invoking the SSLCertificates Wizard to guess the paths when necessary.)
  • The code was resetting the captured debug log for each try, so it was impossible to see why earlier attempts failed.

In investigating the SSLCertificates wizard, it was broken as well. Didn't really look in the right places, and depended upon env variables that were not set. Got that resolved so that it can be used by the autoconfigEmail wizard.

-- GeorgeClark - 07 Nov 2016
 
Topic revision: r23 - 18 Feb 2017, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy