Best practices for implementing SSL on web and connections

Question asked by Jaime - 9/19/2014 at 11:35 AM

Answered

So I undertstand SSL/TLS implementations are different for webmail and connections and I've gone through many articles here and the past forums, but I want to understand how its best to configure give the following scenario:

a) Webmail.

I have a specific IP for all the MX of all my clients.

x.x.x.49

The webmail is accessed via my own domain mail.mydomain.com and the domains of every client mail.cust1.com, mail.cust2.com

I purchased a SSL for MY domain specifically and installed it so now I can access https://mail.mydomain.com

Its not necessary that all do the same, but if they want a secure connection they need to log in with my domain, not theirs, right?

So for this part, I think Im pretty much set up well.

------------

b) Email Connections (POP, SMTP, etc.)

I am using the same SSL cert on the same IP that everyone points to: x.x.x.49

And I binded the TLS/SSL ports to that address.

So now, my clients complain that when connecting, their outlooks and other software say its an unvalid certificate, since they are using mail.cust1.com, mail.cust2.com and not using mail.mydomain.com (and telling them to change their POP and SMTP server on their configs will take forever)

Then my question is:

Should I bind the SSL/TLS to a different IP than the normal IP that everyone has their MX records pointing to? (ie. x.x.x.50) so that if someone wants to send/receive SSL/TLS mail, they use that IP? Therefore, I would need to have some sort of subdomain like secure.mydomain.com on that ip?

If that is the case... do I need to create also MX records for that IP for each client or only for my domain? Or what is necessary in order for them to send /receive email on a new IP (ending in 50) if all the MX records point to the first ip (ending in 49). If they connect to SSL new IP and send email, then will it be tagged as spam since its not coming from the MX record IP that everyone has?

As you see, I am confused about all this config.

Thanks in advance.

6 Replies

Reply to Thread

Jaime Replied

9/24/2014 at 6:13 PM

So anyone wants to share some ideas? :)

Bruce Barnes Replied

9/24/2014 at 6:39 PM

Marked As Answer

Use the primary web interface for everyone to login.

mail.yourprimarydomainname.com can be used for all of your hosted domains. Their domain information will be picked up from their username and everything will work properly, whether they are sending and receiving via a client, or logging into SmarterMail's webmail interface via a web browser.

http:// will connect on port 80

https:// will connect on port 443

If desired, you can build IIS redirects for all of your hosted domains, IE:

mail.customer1.tld
mail.customer2.tld
mail.customer3.tld
etc

and have them redirect to https://mail.yourprimarydomainname.com

The same is true for SSL/TLS. Unless you want to purchase a certificate for each domain, or a server-wide wildcard certificate, all you need to do is use the FQDN of your primary e-mail server and have them use that information for their logins.

This is all predicated on how your DNS is setup. The PRIMARY MX server for each hosted domain will be the FQDN of your SmarterMail server. This will function for non-SSL as well as SSL. It will function for the web interface. It will function for MX to MX TLS encryption.

Setting up any MX server will require a solid knowledge of DNS and IIS HOST HEADERS. It will also require that SmarterMail's webserver is disabled, forcing all access via the IIS interface, whether you are working at the server or remotely.

The ports will all have to be setup and bound to the SSL certificates, for both SSL and TLS. The ports will all have to be the standard ports used by all MX servers for POP, IMAP, SMTP, etc:

They will have to be bound to the FQDN of the PRIMARY server IP ADDRESS:

and you will have to bind your PUBLIC IP ADDRESS to the FQDN of the HOSTNAME of the SmarterMail server:

*SmarterMail HOSTNAME to PUBLIC IP ADDRESS Mapping*

this will be the same hostname which is used in the GENERAL ====> SERVER INFO ====> HOSTNAME box.

While there will be some work involved in setting this up, it will provide a much more secure connection for all of your hosted customers.

An added benefit of going "full enforced SSL/TLS" is that you can DISABLE PLAIN TEXT LOGINS and that will force all transactions between clients and desktops to be fully encrypted - no more plain text passwords traveling over the internet, susceptible to interception and capture by hackers.

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting

Jaime Replied

9/24/2014 at 10:13 PM

Thanks Bruce.

On the first part, I totally get it what you say. Each one uses mail.customer1.tld, etc. so I guess I will redirect them to SSL.

But on the second part:

The same is true for SSL/TLS. Unless you want to purchase a certificate for each domain, or a server-wide wildcard certificate, all you need to do is use the FQDN of your primary e-mail server and have them use that information for their logins.

This is all predicated on how your DNS is setup. The PRIMARY MX server for each hosted domain will be the FQDN of your SmarterMail server. This will function for non-SSL as well as SSL. It will function for the web interface. It will function for MX to MX TLS encryption.

Right now, each client has their own MX records with their domain name, example: mail.customer1.tld and that is what they use as SMTP and POP server.

And changing them to use the FQDN or my SM server ie. mail.yourprimarydomainname.com might be very complicated and time consuming, so this is why I was wondering if I should just leave the current setup with no SSL and then, for clients who want to use SSL, use a different IP with a name like securemail.yourprimarydomainname.com

But then I am not sure how to implement this scenario with a secondary IP using the SSL. Do I need to create also MX records for that IP for each client or only for my domain? Or what is necessary in order for them to send /receive email on a new IP (ending in 50) if all the MX records point to the first ip (ending in 49). If they connect to SSL new IP and send email, then will it be tagged as spam since its not coming from the MX record IP that everyone has?

Or if this scenario is not recommended, then I guess I will have to use your initial suggestion of having all change their MX records to mail.myprimarydomainname.com

What do you think?

Bruce Barnes Replied

9/24/2014 at 11:24 PM

Answered slightly out of order.

In order to not confuse yourself, don't think about your current configuration as you read this because full SSL/TLS means a lot of changes, but they will be worth it.

Once you convert everything to FULL SSL/TLS you can eliminate plain text passwords completely. That's a very weak link and allows anyone who might be monitoring the traffic between your MX server and your users to capture whatever they require to access their login data and take over their accounts.

NO SSL:

1. If you leave some domains without SSL/TLS and give the ability to others, you are creating a weak link in your hosted e-mail services. We automatically provide 100% SSL/TLS for all hosted accounts.
2. Then all domains use their current IP addresses.

SSL/TLS:

To provide full SSL security, then the POP / IMAP / SMTP must be on the same IP address and under SSL/TLS.

If you begin to use the FQDN of the primary domain, then the following changes will have to be made to each hosted domain:

the MX records of each of the hosted customers will have to be updated to reflect the MX SERVER of the PRIMARY DOMAIN as the LOWEST numbered MX server [becoming the highest priority]

MX server of SECUREMAIL.CHICAGONETTECH.COM
as PRIMARY MX SERVER for each hosted domain
- in the case of non-chicagonettech.com domains, then the secondary MX server is shown as the mail server for that domain, IE
- for echicago.com, the primary MX server is securemail.chicagonettech.com and the secondary MX server is mail.echicago.com
each domain will have to use the same OUTBOUND IP ADDRESS as the primary domain SMTP OUTBOUND
- remember to DISABLE IPV6 if you are not using IPV6
- remember to ADDrDNS for IPV6 if you are using IPV6
each user will have to use the same SMTP server as the PRIMARY DOMAIN for their SMTP, POP, or IMAP server
for an example of how that is configured for Outlook 2010, see:
Configure Outlook 2010 for an IMAP or POP Account
the IP ADDRESS of the FQDN will become the primary IP address for MX for the SPF record
each domain's DomainKey and DKIM records will be established independently, just as they were previously
if you are using DMARC, then each domain's DMARC record will point to, and send reports to, the customer's domain - no change from previously
each domain must have it's own POSTMASTER and ABUSE accounts. Communications sent to those accounts must be responded to. It is strongly recommended that they point to an alias which points to an account under your control as you are the e-mail service provider and responsible for abuse complaints filed against all domains.

Jaime Replied

9/25/2014 at 11:27 AM

Thanks for all the info, its clearer now... and I think we will go into that direction. Everything TLS/SSL.

One more question... in your experience, will SSL/TLS connections use more bandwidth? Or its not something noticeable?

Bruce Barnes Replied

9/25/2014 at 4:54 PM

While the actual encryption / transmission / decryption process may use more bandwidth and resources, I believe the increase in bandwidth is negligible.

Additionally, it is possible that and an actual bandwidth, and processor, savings is accomplished by the fact that the data, network, and sever, is more secure.

As I previously indicated, by disabling "plain text passwords," which themselves will become encrypted, as part of the SSL/TLS process, once the full process of configuring and transitioning users to SSL/TLS has been completed, any attackers would probably be further thwarted by the fact that they will no longer be able to attempt password brute force attacks in plain text.

Password brute force attempts would then have to use a suitable encryption technology to even begin to mount a password brute force attack.

Disabling plain text passwords is accomplished, once full SSL/TLS has been configured, and ALL user accounts have been transitioned to the SSL/TLS encryption scheme, by ENABLING the check box for "Disable AUTH LOGIN method for SMTP authentication," under SETTINGS ===> PROTOCAL SETTINGS ===> SMTP IN.

PLAIN TEXT PASSWORD's disabled by ENABLING the "Disable AUTH LOGIN method for SMTP authentication." — PLAIN TEXT PASSWORD's disabled by ENABLING the
"Disable AUTH LOGIN method for SMTP authentication."

as stipulated in a previous post, DO NOT enable this feature unless you have both SmarterMail, and all users, configured to use SSL/TLS, of you will be deluged with complaints about not being able to send and receive e-mail.

Back to Community Threads

Please leave this box unchecked

6 Replies

Reply to Thread

Tags

Related Knowledge Base Articles