How to setup Enforced TLS Encryption on SBS 2011 when using a Mail Filter service
Our customer has a standard out of the box Small Business Server 2011 and uses Fusemail e-mail filtering services, between the mail server that is SBS 2011 and the recipients (the Internet). Fusemail will scan and filter e-mail both inbound and outbound.
In the Fusemail configuration there is a PUBLIC LEG and a PRIVATE LEG to configure TLS Encryption for e-mail if required. So we have enabled the PUBLIC LEG and set up a destination DOMAIN so that e-mails between our customer and this 3rd party would always be TLS Encrypted - Enforced. In actual fact the PUBLIC LEG only enforces TLS encryption between FUSEMAIL (for the customer) and the 3rd party e-mail DOMAIN.
The PRIVATE LEF will only TLS Encrypt e-mail between FUSEMAIL and the customer mail server, this completing the journey between the customer and this 3rd party. That should all work, however while the PUBLIC LEG is testing as being O.K., the PRIVATE LEG is NOT!
Every time we enable the PRIVATE LEG on the FUSEMAIL configuration, the inbound mail does not get delivered and just queues up at Fusemail. When we disable it again, the inbound mail flows as normal, but not encrypted. Fusemal report that our SBS 2001 is not sending out the STARTTLS command, however we think it is.
In SBS 2011 we have Exchange 2010, and we have ticked the box in the EMC for Enable Domain Security (Mutual Auth TLS) - see attached. We also have a secure certificate for the customer domain and it is enabled for SMTP.
When we do our test :- telnet mail.domainname.com 25 followed by ehlo we do see a 250 STARTTLS in the listing.
Can someone advise what we might be doing wrong here.
Thanks,
Netopa Team
TLS.JPG
In the Fusemail configuration there is a PUBLIC LEG and a PRIVATE LEG to configure TLS Encryption for e-mail if required. So we have enabled the PUBLIC LEG and set up a destination DOMAIN so that e-mails between our customer and this 3rd party would always be TLS Encrypted - Enforced. In actual fact the PUBLIC LEG only enforces TLS encryption between FUSEMAIL (for the customer) and the 3rd party e-mail DOMAIN.
The PRIVATE LEF will only TLS Encrypt e-mail between FUSEMAIL and the customer mail server, this completing the journey between the customer and this 3rd party. That should all work, however while the PUBLIC LEG is testing as being O.K., the PRIVATE LEG is NOT!
Every time we enable the PRIVATE LEG on the FUSEMAIL configuration, the inbound mail does not get delivered and just queues up at Fusemail. When we disable it again, the inbound mail flows as normal, but not encrypted. Fusemal report that our SBS 2001 is not sending out the STARTTLS command, however we think it is.
In SBS 2011 we have Exchange 2010, and we have ticked the box in the EMC for Enable Domain Security (Mutual Auth TLS) - see attached. We also have a secure certificate for the customer domain and it is enabled for SMTP.
When we do our test :- telnet mail.domainname.com 25 followed by ehlo we do see a 250 STARTTLS in the listing.
Can someone advise what we might be doing wrong here.
Thanks,
Netopa Team
TLS.JPG
ASKER
Simon,
Thanks for the response.
We have been doing our testing both inside the Firewall and also outside the Firewall. According to our results we see 250 STARTTLS in the list of commands after ehlo. It is our mail filter Fusemail who are testing outside the firewall who say that the mail server is not sending a STARTTLS command.
We are just using the built in SA certificate from within SBS 2011 - We have not purchased am SSL from a CA.
Regards,
Netopa Team
Thanks for the response.
We have been doing our testing both inside the Firewall and also outside the Firewall. According to our results we see 250 STARTTLS in the list of commands after ehlo. It is our mail filter Fusemail who are testing outside the firewall who say that the mail server is not sending a STARTTLS command.
We are just using the built in SA certificate from within SBS 2011 - We have not purchased am SSL from a CA.
Regards,
Netopa Team
This technet article should help get you started
http://technet.microsoft.com/en-us/library/aa998662.aspx
http://technet.microsoft.com/en-us/library/aa998662.aspx
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Simon,
We investigated the firewall rule and discovered an issue with ESMTP - we unticked that box on the Cisco Firewall, and the STARTTLS was acknowledged by the 3rd party. All is now encrypted as it should be.
Many Thanks
Netopa Team
We investigated the firewall rule and discovered an issue with ESMTP - we unticked that box on the Cisco Firewall, and the STARTTLS was acknowledged by the 3rd party. All is now encrypted as it should be.
Many Thanks
Netopa Team
Are you using a trusted SSL certificate?
SBS presents different information depending on whether you are inside or outside. If you look at the Receive Connector configuration you can see the remote networks configuration is different.
Simon.