AP9631 v6.5.0 will not send email with SSL/TLS enabled

[pgpc_apc]

We have an AP9631 NMC installed on a SMX2200RMLV2U.  The NMC successfully authenticates and sends emails through Rackspaces's SMTP relay at secure.emailsrvr.com, port 587, with SSL/TLS set to Never.  When SSL/TLS is set to If Supported or Always, no email is sent and the NMC GUI shows the Last Server Response as 220 2.0.0 Start TLS.  Wireshark, however, shows that the SMTP relay and the NMC continue communicating after the relay sends the Start TLS command.  Specifically, the NMC sends a TLSv1.2 Client Hello, the relay responds with a TLCv1.2 Server Hello and then the relay and the NMC exchange about 10 tcp packets before their communications cease.  Scanning the relay and the NMC with NMAP shows they both support TLS 1.0/1.1/1.2 and they have 10 ciphers in common.  I would be grateful if someone could help me get the NMC to send emails through the Rackspace relay with SSL/TLS enabled. 

[Anonymous user]

Hi,

Can you please share the solution, how did you made it to work ?

I am having similar issue.

[Anonymous user · Accepted solution]

I would be very much interested in a solution, too.

[Jerry95]

As would I!

[Shaun]

Hi All,

I've seen an issue where the NMC2 (AP9630,31,etc and embedded relatives.  Firmware 5.x.x - 7.x.x) doesn't have enough memory to reassemble larger certificate chains - where the server presents not only its own certificate, but also that of its CA, and sometimes an intermediary CA or two.  The trend towards larger (4096bit) RSA keys exacerbates this behavior as it leads to larger certificates - so the less certificates we can fit in the chain before we exhaust the space.

The symptom for this is that in Wireshark we can see see the client hello, then the server hello, and then when we expect the server to send its certificate, we see an exchange of TCP Window Full (or ZeroWindow) messages.

The last message logged by the card is less useful for this, as any errors in establishing a TLS session will result in the same last message - the card sends STARTTLS, the server replies 220 Start TLS (or Proceed TLS, or similar - the server can put any text after 220, but it'll usually hint at TLS).  For Implicit TLS (port 465), TLS is established before any SMTP traffic, so no last message is logged.  So these particular messages don't really narrow down why TLS failed - making the Wireshark steps incredibly useful.

There's no real resolution available for this, as we can't add more memory to the card.  A common workaround is to relay via an intermediary mailserver which presents a certificate without a CA chain (or with a simpler chain).  Alternatively, the newer AP9640/41 have more hardware resources so shouldn't hit this issue.