Server Name Indication (SNI) extension during a TLS handshake

[info_fx]

Expected behavior

Server Name Indication (SNI) extension during a TLS handshake.

Actual behavior

DeltaChat does not send SNI during TLS handshake, if many domains are hosted on the same server and same ip address, the server does not know which exactly certificate should be replied back. Which causes certificate mismatch error as server replies back with the default certificate.

the server presents a default SSL certificate (often the first certificate configured for that IP address).
the DeltaChat will receives this certificate, notices that the domain name on the certificate does not match the server the user intended to visit, and terminate the connection.

the user will typically see an error message such as “Your connection is not private” or “Certificate does not match the domain”.

Example Images

Dec 13 08:37:31 mail postfix/submission/smtpd[68285]: SSL_accept error from ec2-3-76-78-111.eu-central-1.compute.amazonaws.com[3.76.78.111]: -1
Dec 13 08:37:31 mail postfix/submission/smtpd[68285]: warning: TLS library problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1552:SSL alert number 42:

[link2xt]

Delta Chat sends SNI, but since version 2.30 does not send SNI when using STARTTLS (aka explicit TLS, usually on port 587 for SMTP and port 143 for IMAP), see

Disable SNI when TLS security is set to "STARTTLS" for both IMAP and SMTP ports

Does your server have implicit TLS port (submissions, port 465)? Delta Chat should automatically use it instead in this case and work without showing any warnings.