Unable to send email alert using email connector in kibana

[cuongnp (Phu Cuong Nguyen)]

Hi Community,

After enable TLS connection between kibana and Elasticsearch ,I'm unable to send email alert using email connector. When send test mail, the result is "Error upgrading connection with STARTTLS: 454 4.7.0 TLS not available due to local problem"
Please take a look and give me advice:

[Patrick_Mueller (Patrick Mueller (Kibana Alerting))]

The email connector configuration is documented here: Email connector and action | Kibana Guide [7.13] | Elastic

From the images above, you have Secure off, so Kibana will connect with a plain tcp socket, and then upgrade to TLS via the STARTTLS SMTP command. I'm guessing the message Error upgrading connection ... is probably coming from the nodemailer library we use, indicating it was unsuccessful using the STARTTLS SMTP command.

The other settings indicate the SMTP server is running on 172.19.15.15, port 25, and does not use authentication. Is all that correct?

[cuongnp (Phu Cuong Nguyen)]

@Patrick_Mueller

172.19.15.15

Thanks Patrick,
Yes, the secure is off, SMTP port 25 and does not use authentication . I can telnet to 172.19.15.15:25 on kibana server and send mail through SMTP Commands
So Does that mean I should check the nodemailer library on mail server side?

[Patrick_Mueller (Patrick Mueller (Kibana Alerting))]

If you can telnet, then you likely aren't using the STARTTLS command, so TLS won't even be used. Is TLS available on your SMTP server? Maybe on a different port? Did your SMTP server generate any more specific messages when Kibana tried to connect to send the email? TLS cipher / algorithm / etc requirements? Or is it possible TLS is not configured correctly on your SMTP server?

I believe the way the call to nodemailer is set up is that it may always require a TLS connection inevitably (direct or via STARTTLS), but we do have some special config so that if secure is off and no auth is used, nodemailer will accept a self-signed certificate. There's also a global config option xpack.actions.rejectUnauthorized which will accept self-signed certificates for all connector https requests.

If your SMTP server only supports plain tcp connections, I'm not sure the email connector will work in Kibana 7.13. We have some code currently scheduled to be available in 7.14 (not yet generally available) that allows SMTP connections to be specified with an ignoreTLS option xpack.actions.customHostSettings[n].smtp.ignoreTLS. That should allow a connection over plain tcp sockets.

I suppose another option if your SMTP server can't support TLS is to use an ssh tunnel / terminator in front of your SMTP server, and have the email connector connect to that - in which case you'd need to turn secure on. Not completely positive that would work, but seems like something that could work.

[cuongnp (Phu Cuong Nguyen)]

Thanks for your kind support,

I just checked on SMTP server, looks like it supports STARTLS connection through port 25

This is result when I turn on secure

Action failed to run
The following error was found:
error sending email
Details:
140111650948992:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:332:

My kibana.yml configuration

server.ssl.enabled: false
xpack.security.encryptionKey: "key"
xpack.reporting.encryptionKey: "key"
xpack.encryptedSavedObjects.encryptionKey: ""key
elasticsearch.ssl.certificateAuthorities: "/etc/kibana/elasticsearch-ca.pem"
xpack.security.session.idleTimeout: "1h"
xpack.security.session.lifespan: "30d"
xpack.actions.rejectUnauthorized: false

[Patrick_Mueller (Patrick Mueller (Kibana Alerting))]

Yeah, setting secure: true only works if the port will accept a TLS connection, so for port 25, you'll need to use secure: false.

Interesting that it says it supports STARTTLS. But then using STARTTLS doesn't actually work. Did you see any messages logged from your SMTP server about this connection attempt? I'm not sure if the message "TLS not available due to a local problem" is coming from the SMTP server, or client, but guessing it's the server. Because I've never seen it before, and I'm not sure what kind of "local problem" a client could be having.

If you can't get the STARTTLS command to work, I think you'll need to wait for our release with the ignoreTLS configuration option, or set up an SSH tunnel / terminator (and again, not sure this would really work) in front of your SMTP server.