Warning: this is a salty message. You have been warned.
While FMC 7.0.0 had a lot of nice and needed features, it went backwards in many others - including basic system functionality. Today’s case in point, the FMC internal email notification system (System > Configuration > “Email notification”). While up to FMC 6.7.x it used TLS with a good certificate (perhaps the same as configured for HTTPS), fresh on 7.0.0 it is now using an on-the-fly, self signed certificate, and as such, another Cisco security appliance joins ISE 1.x/2.x as unable to use proper configured secure communications channels for email delivery.
The open source MSMTP client[1] deployed at FMC 7.0.0 does have support for TLS and certificates, providing it is configured to do so[2]. When the SMTP process is spawned via mojo_server.pl helper, however, the live configuration does not contain a valid client certificate:
tail: '/tmp/msmtprc' has appeared; following new file
==> /tmp/msmtprc <==
account default
host aaa.bbb.ccc.ddd
auto_from off
domain host name.fullyqualified.dom
syslog LOG_MAIL
port 25
auth off
tls on
tls_certcheck off
tail: '/tmp/msmtprc' has become inaccessible: No such file or directory
And just like that, a live, real world SMTP server errors out, and to the limbo it goes your notification.
mta[85847]: STARTTLS: write error=syscall error (-1), errno=32, get_error=error:00000000:lib(0):func(0):reason(0), retry=99, ssl_err=5
So if you, unlike Cisco, has your core infrastructure systems configured as per standards, including making use of email cryptography with usage/verification of valid certificates, save yourself the hassle: add a bypass rule on your mail server to *not* use TLS communications for Cisco products. They can write standards/RFC, but they don’t know how to follow them.
Bug report filled with TAC.
[1] https://marlam.de/msmtp/
[2] https://marlam.de/msmtp/msmtp.html#Transport-Layer-Security
