TLS not available, sending between ME servers

Discussion regarding the Standard version.
Post Reply
JessicaRabbit
Posts: 2
Joined: Mon Feb 12, 2018 10:04 pm

TLS not available, sending between ME servers

Post by JessicaRabbit »

I am trying to set up a secure test mail environment, but having trouble (this is a proof-of-concept test). I have two MailEnable servers on two separate domains. They can identify and communicate between themselves and successfully exchange email using clear text SMTP. I need this to be encrypted SMTP traffic between the servers -- and message transfer needs to fail if encryption is not active on the connection.

Here's what I did:
1. Installed the machine certificate (smtp0x.mycopr0x.com.crt) from our CA (machine already trusts the CA) into the ME "Local Machine/Personal/Certificates" store.
2. Used MEAdmin to set-up:
a. MEManagement\Servers\localhost right-click Properties\SSL to select the certificate for SSL.
b. On the MEManagement\Servers\localhost\Services and Connectors\SMTP right-click Properties\Inbound tab -- set "submission port, Alternate port" to 465 and checked "Requires SSL".
3. I've got Wireshark set up and it shows the failure to connect securely, and then a successful plain text transfer.
4. The history debug log shows:
02/12/18 15:47:07 ME-I0018: [D19D4EF7572147A5A2EC5F060B07D846.MAI] Outbound message from ([SMTP:Debbie@mycorp01.com]) requeued as [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] to the target domain [mycorp02.com]
02/12/18 15:47:07 ME-I0123: Domain [capaqa.com] has MX list [smtp02.mycorp02.com]
02/12/18 15:47:07 ME-I0026: [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] Sending message
02/12/18 15:47:07 ME-IXXXX: [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] DNS resolved to the following record: IP Address=10.104.10.5, Family=2, Type=1, Protocol=6
02/12/18 15:47:07 ME-IXXXX: [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] Remote server returned a response indicating a temporary failure. Server Response: (454 TLS not available due to temporary reason**)
02/12/18 15:47:07 ME-E0037: [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] Failed to create outbound TLS connection. Message will be retried without TLS.
02/12/18 15:47:10 ME-I0123: Domain [mycorp02.com] has MX list [smtp02.mycorp02.com]
02/12/18 15:47:10 ME-I0026: [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] Sending message
02/12/18 15:47:10 ME-IXXXX: [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] DNS resolved to the following record: IP Address=10.104.10.5, Family=2, Type=1, Protocol=6
02/12/18 15:47:10 ME-I0049: [E9502CE8A0934B6CBB42A1B85C2548ED.MAI] Send Completed Successfully (0.031s).

I have tried multiple different port and check-box settings, restarting between each change, and having no luck.

I am completely new to MailEnable, so the documentation is really difficult to follow. There is a lot of knowledge assumed by the authors. I've tried to follow their guide as closely as possible, but most of their items seems to refer to clients connecting to the IIS server. This is NOT about client connectivity. I am trying to get servers exchanging mail, securely.

Does anyone have any ideas that might help? Thank you so much for any help you can offer.

JessicaRabbit
Posts: 2
Joined: Mon Feb 12, 2018 10:04 pm

Re: TLS not available, sending between ME servers

Post by JessicaRabbit »

This is working now -- the problem appears to be that ME only works with Microsoft certificates (?I didn't know there was a difference?).

If you'd like more detail:

We use OpenSSL to generate the Certificate Signing Request, before passing it to our CA. Apparently, that causes a certificate to be generated that ME cannot use. We also use MMC, "Certificates" to import the certificate we receive from our CA. I am not sure if that was significant, but once I caught an inkling that MS was suspect, I switched to IIS Manager for CSR generation and Cert importing.

I used IIS Manager's Certificate Request feature to generate the CSR, sent it off to our CA, received the Cert, imported it using IIS Manager, and everything just started working... Bugger of a problem.

Thanks for taking the time to, but this hurdle has been hopped. :)

Post Reply