This submenu is called up from Mail System TLS Settings.
Sections on this page:
Parameters |
Description |
||||||||
|---|---|---|---|---|---|---|---|---|---|
The name of the email domain of the communication partner is usually entered here. This setting is only editable when creating a new TLS connection, i.e. when the menu was opened via the Add TLS Domain button. |
|||||||||
|
forwarding server address |
If no entry is made here, the name indicated under Domain name is resolved via MX.
The following is accepted as input:
When specifying an IP address or a hostname, there is the option to additionally enter an individual port. The port is entered directly afterwards, separated by a colon ":", i.e. "[IP address]:port" or "hostname:port". If no port is specified, the standard SMTP port TCP25 is used.
|
The TLS settings are used to set the level of checks for a TLS connection to the target server on the Internet, to the Outgoing server (see Mail System) and/or the corresponding groupware, i.e. Forwarding server (see table under Mail System Managed Domains Column Server IP Address).
|
With this setting, only TLS to the the target domain and/or to TargetServer is configured. Receiving an incoming connection cannot be set. For this reason, TLS often creates a "false" sense of security. The certificate integrated under SSL will be used to accept TLS connections. |
TLS setting |
Description |
||
|---|---|---|---|
No TLS encryption. |
|||
Emails are sent over a TLS-encrypted channel, provided that the receiving email server supports TLS encryption. |
|||
Emails are only sent if a transmission using TLS encryption is possible. |
|||
Emails are only sent if a transmission via TLS encryption is possible and the SSL certificate of the receiving email server is valid (issued by a trustworthy CA and not expired/revoked). |
|||
Emails are only sent if a transmission via TLS encryption is possible, the SSL certificate of the receiving email server is valid, the FQDN of the email server is identical to the name (CN) entered in the certificate (applicant) and the name of the email domain is the same as the domain name of the email server. This prevents MX spoofing. The use of wildcard certificates is not possible at this point.
Example: 1.Sending an email to max.mustermann@partner.tld a.MX lookup results in b.Each of these servers has its FQDN entered as CN in its certificate used for TLS. c.The domain name of all hosts (mail1, mail 2) is partner.ltd and thus corresponds to the domain name of the email domain.
2.Assumption: a.MX lookup results in a.The domain name of the email domain partner.com does not correspond to the mail server – partner.tld –
Conclusion: For the email domain partner.tld, the TLS security level can remain on "secure". If the security level "verify" is insufficient of the mail domain partner.com, the "Fingerprint" level is to be used. For this purpose, the fingerprints of all mail servers (mail1 and mail2.kommunikationspartner.com) are to be entered.
|
|||
Emails are only sent if the counterpart supports TLS and the presented certificate has the fingerprint entered in the input field. If multiple email servers are available for the target domain, their fingerprints can be separated by entering a pipe "|", |
The changes made are saved via the Save changes button.
Check the receiving email server for the use of a wildcard SSL certificate
Whether an email server uses a wildcard SSL certificate can be determined very easily with the command line tool OpenSSL.
Example:
# openssl s_client -starttls smtp -crlf -connect xxx.xxx.xxx.xxx:25
In the example, xxx.xxx.xxx.xxx is the actual IP address of the target server. Alternatively, the hostname of the target server can be used.
# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25
The result of the query will look as shown below. Based on the certificate subject in the parameter (CN), it can be determined whether the certificate is a wildcard SSL certificate. In the example, the value CN=*.psmtp.com was returned in the response. Thus, this is a wildcard certificate "*", which can be used for all hosts of the psmtp.com domain. The Parameter X509v3 Subject Alternative Name:is also interesting. Here, DNS:*.psmtp.com was returned in the response. This field can contain more domains.
# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25 | openssl x509 -text -noout
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
.
.
Certificate:
.
.
Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.psmtp.com
.
.
.
X509v3 Subject Alternative Name:
DNS:*.psmtp.com
The presentation of the output was reduced to the essential information.
Reading the SHA1 fingerprint from the SSL certificate of the receiving email server
Above, it was described how the SSL certificate used by the receiving email server can be read. Here, it is irrelevant whether this is a wildcard certificate or not.
The fingerprint of an SSL certificate can be read out relatively easily with the command line tool OpenSSL.
Example:
# openssl s_client -starttls smtp -crlf -connect xxx.xxx.xxx.xxx:25 | openssl x509 -noout -fingerprint
In this example, xxx.xxx.xxx.xxx again represents the actual IP address of the target server, which can alternatively be replaced by the hostname of the target server.
# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25 | openssl x509 -noout -fingerprint
The resulting output should look as follows:
# openssl s_client -starttls smtp -crlf -connect postini.com.s8a1.psmtp.com:25 | openssl x509 -noout -fingerprint
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
250 HELP
SHA1 Fingerprint=DD:9A:EC:66:E2:43:81:B9:20:2B:75:DB:30:C8:67:CC:9B:B0:D1:99
read:errno=0
The required SHA1 Fingerprint is displayed in the output. This value can now be transferred to the configuration.
