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 allowlists hosts that encounter an SSL error during an SMTP session. The allowlist is reset every hour.
Automatically detect and activate newer certificates
When this option is enabled, the system will perform a check during its nightly maintenance process. For each active certificate, it will check to see: if there's another certificate on the system that expires later, if it is for the same host name, and if it includes all alternative host names. If such a certificate exists, the system will automatically make it the active certificate. This feature is particularly useful when there's a scheduled task on the system that automatically updates the certificate, such as Let's Encrypt. This option is enabled by default.
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.
To support SSL/TLS and HTTPS for SecurityGateway, you need an SSL/TLS Certificate (see below). 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.
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 and Deleting 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 (see below). To delete an existing certificate, select the certificate and then click Delete.
Activating an SSL Certificate
To activate an SSL certificate, click the certificate's Active checkbox and click Save.
Configure Let's Encrypt
If you are using Let's Encrypt as your CA, to automate your certificate management, click Configure Let's Encrypt to open the Let's Encrypt PowerShell Update page, to help you easily configure and run the required PowerShell script included in the "SecurityGateway\LetsEncrypt" folder. For more information, see Using Let's Encrypt to Manage Your Certificate below.
STARTTLS Allowlist
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
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. Click Configure Let's Encrypt on the Encryption page to open the Let's Encrypt PowerShell Update page, to help you easily configure and run the PowerShell script included in the "SecurityGateway\LetsEncrypt" folder.
Let's Encrypt PowerShell Update
To support using Let's Encrypt's automated process to manage a certificate, this page is provided to help you easily configure and run the PowerShell script included in the "SecurityGateway\LetsEncrypt" folder. Using this page to configure and run 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 HTTP Server Host Name as the domain for the certificate (if that option is blank then it uses the Default Domain), retrieves the certificate, imports it into Windows, and configures SecurityGateway to use the certificate using SecurityGateway's XMLRPC API.
NOTE: Using Let's Encrypt requires PowerShell 5.1 or higher and .NET Framework 4.7.2 or higher. Further, SecurityGateway's HTTP ports setting must be set to listen on port 80 or the HTTP challenge cannot be completed and the script will not work.
Automatically update the LetsEncrypt certificate
Click this checkbox if you wish to automatically create and update an SSL/TLS certificate via the Let's Encrypt script. The certificate will be updated every 10-60 days according to your Days between updates setting below.
Current Password
Including your password creates an API token for the script to access the SG XML API. The password is not saved. This is not necessary when just updating settings.
Host names (separate multiple host names with a comma)
If you wish to set up alternate host names in the certificate, specify those host names here, separated by commas. You do not need to include the HTTP Server Host Name in this list. For example, if your Host Name were "mail.example.com" and you wished to use an alternate host name of "imap.example.com," then you would only need to include "imap.example.com" here. If you do not wish to use any alternate host names then leave this option blank. Note: if you include host names, an HTTP challenge from Let's Encrypt must be completed for each one to validate your server's control of that host name. If the challenges are not all completed then the process will fail.
Admin email for notifications
Specify an administrator email address here if you wish to be notified when an error occurs during a Let's Encrypt update.
Use an ECDSA certificate
Check this box if you wish to use an ECDSA-based certificate rather than an RSA certificate.
Use the staging server
Use this when you need to test Let's Encrypt.
Days between updates (10-60)
Use this option to specify how often your certificate should be updated, from 10-60 days. The default setting is 60 days.
Run Now
Click this button to run the script immediately.
Remove old certificates (expired > 30 days ago)
By default SecurityGateway will remove any old certificates that have been expired longer than 30 days. Uncheck this box if you do not wish to remove them automatically.
View the LetsEncrypt script log file
Click this button to view the Let's Encrypt script's log file.
Days until next update
This shows you how many days are remaining until the certificate is automatically updated, according the Days between updates (10-60) setting above.
Command line:
This displays the command line text that will be used when running the script. The text is updated in real time as you make changes on this page.
