Unknown Failure. Unable to send message. javax.mail.MessagingException: Could not convert socket

Products

• Continuous Delivery Director SAAS

Issue/Introduction

When testing, or using, the CDD SMTP Plugin it returns:

'UNKNOWN' Failure. Unable to Send Test Message to '[email protected]'

When reviewing Tomcat's catalina.out file we can see the following errors:

• javax.mail.MessagingException: Could not convert socket to TLSCaused by:
• javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
• Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Environment

SMTP Plugin Option: Use secure communication = not in use

Component : Continuous Delivery Director

Version 6.x+

 

Cause

SMTP Servers/Relays (or proxies in between) can be setup so that attempts to send mail via, typically insecure, port 25 are converted in the background to use SSL. Java applications will raise these exceptions when it does not have a copy of the certificate (or it's root/intermediate). This is needed for the SSL Handshake to complete successfully. 

Resolution

Add the needed certificates to the java used by the SMTP Plugin. Do this by running the command:

/path/to/keytool -importcert -alias smtpCert -file <new certificate file> -kestore /path/to/java's/lib/security/cacerts

 

Note: See the "Additional Information" section below for more details on how to debug (identify/confirm truststore being used, certificate chain received, certificates in truststore, etc..). 

 

Additional Information

SSL Debug can be enabled by updating the appropriate Tomcat startup file to include the following java argument: -Djavax.net.debug=all

Afterwards you can find the debug output in the catalina.out file. In the debug output you can look for relevant information in the sections:

• The truststore being used by the java managing tomcat can be found by searching for "trustStore is:". Example: trustStore is: /usr/java/jre1.8.0_232/lib/security/cacerts.
  • The "trustStore is:" message typically precedes a list of the certificates in the truststore.
  • Each certificate in the trustStore is typically followed by the string: "adding as trusted cert:"
    • The detail for a given certificate, in the trustStore (prefixed by the "adding a trusted cert" message) includes "Serial number:" information. The syntax of this entry usually follows: Serial number: 0x<serial number>
• Certificate chain: this is the certificate being served by the target host
  This will include a "SerialNumber" for each certificate in the chain.
  • There should be an equivalent version of that certificate's serial number in java's cacerts truststore.
  • The "SerialNumber" here is enclosed in square brackets and does not necessary use the same syntax as the trusted cert's "Serial number:" You should be able to use this version of the "SerialNumber" to search for matches in the trusted certs section of the debug. 
• If the truststore does include a certificate to accommodate the SSL Handshake then the next piece of information after the "Certificate chain" should be the "Found trusted certificate:" section. 
  • This section uses the same "SerialNumber:" syntax as certificates shown in the Certificate chain. 
• Sections in the ssl handshake are separated with three asterisk characters: *** 

Links where additional information is available:

• https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
• https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLOverview
• https://stackoverflow.com/questions/23659564/limiting-java-ssl-debug-logging