Added option to skip smtp/imap server certificate validation

[conFrituur]

First of, thank you for sharing your check script 🙂

I would like to connect to an IP directly instead of using a hostname. This would cause the certificate validation to fail. Just setting the context.check_hostname = False might work in my case, but skipping all validation covers more usecases. I would say that accepting any valid certificate is just as insecure as not checking at all anyhow.

[nitram2342]

Many thanks for your interest in the plugin. As a security company I hesitate to accept the change. While it is sometimes useful to disable cert verification for debugging, the plugin is for monitoring and monitoring only makes sense for infrastructure that has a certain degree of reason for being and I wonder why there is no valid certificate. I assume it is an internal server with a self-signed cert? Is it an option to put an IP address into the subject alternative name? How do other mail clients verify the certificate?

[conFrituur]

Thanks for your reply! My usecase is a little bit more complicated than i let on. In my attempt to keep it simple, i may have created more confusion 😅

Let me try again:

• I have one production server that (among other things) runs icinga2, dovecot & postfix in docker containers on the same docker bridge network.
• I deploy to this server using ansible playbooks
• Before deploying any changes, i test the playbooks by spinning up a testVM on my local machine.

The testVM does have valid certificates. The problem is, if i use the hostname of the certificate (mail.example.org), the check_mail_loop script will connect to the IP behind that DNS name (a.k.a. the production server). Not my local testVM.

This can be overcome in multiple ways:

• Override the DNS (mail.example.org) in /etc/hosts on the testVM.
• Have a separate address and optional vhost (SNI) field in the check (like check_http)
• Disable TLS hostname validation

I was on the fence and figured implementing 'skip TLS validation' would also help out most other people. In my usecase i wasn't worried about the security aspect, because the traffic would stay on the private docker bridge between containers (using the internal containernames as smtp_host/imap_host). I have other checks that monitor the mail certificate.

Giving it a second thought after reading your comment, i think having separate address / SNI fields would be a neater ways to solve this. If you agree, i will refactor my change and make a new PR. The only caveat is that it wont help people with a self-signed certificate.

[nitram2342]

I understand. Would it be an option to have a trustchain configuration on the Icinga plugin side and put the self-signed cert as trust-anchor there? That would work to establish a trust-relationship with a self-signed server cert, when the plugin client expects this. It may not work with prod-cert, when the hostname verification fails, but maybe it is possible to test an image by injecting a self-signed cert.

[conFrituur]

I dont think it would help in my case, i do not have self-signed certs in my setup. Its the mismatch between the docker-container-name (dovecot) i use to connect to versus the common name on the certificate of the mailserver (mail.example.org). Both test and production use a valid certificate (mail.example.org).

host (internal DNS of docker container) allows me to connect from icinga2 directly to the dovecot container. but it does not match the certificate common name (mail.example.org)

To resolve this, i could add an optional field that would hold the SNI name it should when connecting, to match the certificate common name, and TLS validation succeeds

The reason i brought up self-signed certificates was purely for potential other people. You may ignore that.