SecurityGateway incorporates the latest in encryption technology to protect your data. The Secure Sockets Layer (SSL) protocol—also known as Transport Layer Security (TLS)—with the STARTTLS SMTP extension prevent others from being able to intercept and read your email. HTTPS in SecurityGateway offers this same protection for the web interface.
The SSL protocol, developed by Netscape Communications Corporation, is the standard method for securing server/client Internet communications. It provides server authentication, data encryption, and optional client authentication for TCP/IP connections. Further, because SSL is built into all current major browsers, simply installing a valid digital certificate on your server will activate the connecting browser's SSL capabilities when connecting to SecurityGateway. If you connect using a mail client, SecurityGateway supports the STARTTLS SMTP extension over SSL/TLS. However, you must first have your client configured to use SSL, and it must support that extension—not all mail clients support it, though most do.
Email and HTTPS Encryption
Enable SSL and STARTTLS support for SMTP and HTTPS
Click this check box to activate support for the SSL/TLS protocol and the STARTTLS extension, using the "Active" certificate in the Select Certificate box below. This option must be enabled and a valid certificate must be active if you wish to log in to SecurityGateway's web interface using HTTPS. This option is disabled by default.
Send messages with STARTTLS whenever possible
Click this option if you want SecurityGateway to attempt to use the STARTTLS extension for every SMTP message it sends. If a server to which SecurityGateway is connecting doesn't support STARTTLS then the message will be delivered normally without using SSL. This option is disabled by default.
SSL negotiation failures will retry without SSL for up to one hour
This option temporarily white lists hosts that encounter an SSL error during an SMTP session. The white list is reset every hour.
RequireTLS allows you to flag messages that must be sent using TLS. If TLS is not possible (or if the parameters of the TLS certificate exchange are unacceptable) messages will be bounced rather than delivered insecurely. For a complete description of RequireTLS, see: RFC 8689: SMTP Require TLS Option.
RequireTLS is enabled by default, but the only messages that will be subject to the RequireTLS process are messages specifically flagged by a Content Filter rule using the new Content Filter action, "Flag message for REQUIRETLS...", or messages sent to <local-part>+requiretls@domain.tld (for example, arvel+requiretls@mdaemon.com). All other messages are treated as if the service is disabled. Several requirements must be met in order for a message to be sent using RequireTLS. If any of them fail, the message will bounce back rather than be sent in the clear. The requirements are:
•RequireTLS must be enabled.
•The message must be flagged as needing the RequireTLS treatment, via the Content Filter action or the "<localpart>+requiretls@..." address.
•The MX record of the recipient's domain must be validated by MTA-STS.
•The connection to the receiving host must use SSL (STARTTLS).
•The SSL certificate of the receiving host must match the MX host name and chain to a trusted CA.
•The receiving mail server must support REQUIRETLS and say so in the EHLO response.
•If any of these requirements fail, the message is not delivered and bounced back to the sender.
MTA-STS support is enabled by default and is described in RFC 8461: SMTP MTA Strict Transport Security (MTA-STS).
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
To set up MTA-STS for your own domain, you will need to create an MTA-STS policy file that can be downloaded via HTTPS from the URL https://mta-sts.domain.tld/.well-known/mta-sts.txt, where "domain.tld" is your domain name. The policy text file should contain lines in the following format:
version: STSv1
mode: testing
mx: mail.domain.tld
max_age: 86400
Mode can be "none", "testing", or "enforce". There should be an "mx" line for each of your MX hostnames. A wildcard can be used for subdomains, such as "*.domain.tld". Max age is in seconds. Common values are 86400 (1 day) and 604800 (1 week).
Also needed is a DNS TXT record at _mta-sts.domain.tld, where "domain.tld" is your domain name. It must have a value in the format:
v=STSv1; id=20200206T010101;
The value for "id" must be changed every time the policy file is changed. It is common to use a timestamp for the id.
Enable TLS Reporting (RFC 8460)
TLS Reporting is disabled by default and discussed in RFC 8460: SMTP TLS Reporting.
TLS Reporting allows domains using MTA-STS to be notified about any failures to retrieve the MTA-STS policy or negotiate a secure channel using STARTTLS. When enabled, SecurityGateway will send a report daily to each STS-enabled domain that it has sent (or attempted to send) mail to that day. There are several options provided for configuring the information that your reports will contain.
To set up TLS Reporting for your domain, enable DKIM signing, and create a DNS TXT record at _smtp._tls.domain.tld, where "domain.tld" is your domain name, with a value in the format:
v=TLSRPTv1; rua=mailto:mailbox@domain.tld
Where mailbox@domain.tld is the email address where you want reports for your domain to be sent.
Select Certificate
This box lists all SSL certificates that you have created. SecurityGateway generates certificates that are self-signed, meaning that the Issuer of the certificate, or Certificate Authority (CA), is the same as the owner of the certificate. This is perfectly valid and allowed, but it is possible that some users may be asked whether or not they wish to proceed to the site and/or install the certificate whenever they connect to SecurityGateway's HTTPS URL, because the CA won't already be listed in your their list of trusted CAs. When they agree to install the certificate and trust your SecurityGateway domain as a valid CA they will no longer have to see the security alert message when connecting. Whether or not they have to go through that procedure at all depends on what browser they are using, what security restrictions they have in place, and so on.
Creating SSL Certificates
To create a new certificate, click New on the toolbar at the top of the Select Certificate box. This will open the SSL Certificate screen. To delete an existing certificate, select the certificate and then click Delete.
Activating a SSL Certificate
To activate a SSL certificate, click the "Make Active" link in the desired entry.
STARTTLS Whitelist
Use this option to designate any IP addresses, hosts, or domains that you wish to be exempt from STARTTLS. STARTTLS will never be used when sending to any entry listed, and STARTTLS will never be advertised to any connecting hosts or IPs on the list.
STARTTLS Required List
SMTP connections to hosts or IP addresses on the STARTTLS Required list must use STARTTLS. If STARTTLS is not available or fails, the message will not be sent.
SSL Certificate
This screen is used to create new SSL certificates. To create a new certificate, click New on the Select Certificate toolbar on the Encryption page and then enter your certificate's information. After you are finished, click Save and Close to create the certificate.
Create Certificate
Host Name
Enter the host name to which your users will connect (for example, "mail.example.com").
Organization/Company Name
Enter the organization or company that "owns" the certificate here.
Alternative Host Names (separate multiple entries with a comma)
SecurityGateway does not support separate certificates for each domain—all domains must share a single certificate. If there are alternative host names to which users may be connecting, and you want this certificate to apply to those names as well, then enter those domain names here separated by commas. Wildcards are permitted, such as "*.example.com".
Encryption Key Length
Choose the desired bit-length of the encryption key for this certificate. The longer the encryption key the more secure the transferred data will be. Note, however, that not all applications support key lengths longer than 512.
Country/Region
Choose the country or region in which your server resides.
Using Certificates Issued by a Third-party CA
If you have purchased or otherwise generated a certificate from some source other than SecurityGateway, you can still use that certificate by using the Microsoft Management Console to import it into the certificate store that SecurityGateway uses. Once the certificate has been imported into Windows, it should appear in SecurityGateway so that it can be used. To import the certificate:
1.On your Windows toolbar, click Start » Run... and then type "mmc /a" into the text box.
2.Click OK or press Enter.
3.In the Microsoft Management Console, click File » Add/Remove Snap-in... on the menu bar (or press Ctrl+M on your keyboard).
4.On the Add or Remove Snap-ins dialog, click Certificates, and then click Add.
5.On the Certificates snap-in dialog, choose Computer account, and then click Next.
6.On the Select Computer dialog, choose Local computer, and then click Finish.
7.Click OK.
| 9. | Under Certificates (Local Computer) in the left pane, if the certificate that you are importing is self-signed, click Trusted Root Certification Authorities and then Certificates. If it is not self-signed then click Personal. |
| 10. | On the menu bar, click Action » All Tasks » Import..., and click Next. |
| 11. | Enter the file path to the certificate that you wish to import (using the Browse button if necessary), and click Next. |
| 12. | Click Next, and click Finish. |
Using Let's Encrypt to Manage Your Certificate
To support SSL/TLS and HTTPS for SecurityGateway, you need an SSL/TLS Certificate. Certificates are small files issued by a Certificate Authority (CA) that are used to verify to a client or browser that it is connected to its intended server, and that enable SSL/TLS/HTTPS to secure the connection to that server. Let's Encrypt is a CA that provides free certificates via an automated process designed to eliminate the currently complex process of manual creation, validation, signing, installation, and renewal of certificates for secure websites.
To support using Let's Encrypt's automated process to manage a certificate, SecurityGateway includes a PowerShell script in the "SecurityGateway\LetsEncrypt" folder. A dependency of the script, the ACMESharp module, requires PowerShell 3.0, which means the script will not work on Windows 2003. Additionally, the SecurityGateway HTTP service must be listening on port 80 or the HTTP challenge cannot be completed and the script will not work. You will need to correctly set the execution policy for PowerShell before it will allow you to run this script. Running the script will set up everything for Let's Encrypt, including putting the necessary files in the SecurityGateway HTTP (templates) folder to complete the http-01 challenge. It uses the FQDN configured in SecurityGateway for the default domain as the domain for the certificate, retrieves the certificate, imports it into Windows, and configures SecurityGateway to use the certificate using SecurityGateway's XMLRPC API.
If you have an FQDN setup for your default domain that does not point to the SecurityGateway server, this script will not work. If you want to setup alternate host names in the certificate you can do so. You need to pass the alternate host names on the command line.
Example usage:
.\SGLetsEncrypt.ps1 -UserName admin@domain.com -Password Password1 -AlternateHostNames mail.domain.com,imap.domain.com,wc.domain.com -ErrorEmailTo admin@domain.com
You do not need to include the FQDN for the default domain in the AlternateHostNames list. For example, suppose your default domain is "example.com" configured with an FQDN of "mail.example.com", and you want to use an alternate host name of "imap.example.com". When you run the script, you will only pass "imap.example.com" as an alternate host name. Further, if you pass alternate host names, an HTTP challenge will need to be completed for each one. If the challenges are not all completed then the process will not complete correctly.
If you do not want to use any alternate host names then do not include the –AlternateHostNames parameter in the command line. If you do not want to have email notifications sent when an error occurs do not include the –ErrorEmailTo parameter in the command line.
