Solved Sendmail process crash as soon as STARTTLS is received after FreeBSD upgrade

I just upgraded my server from FreeBSD 10.3 to 11.1. It's now running Sendmail 8.15.2 and OpenSSL 1.0.2k-freebsd 26 Jan 2017.

Since the upgrade, sending mail to my server is failing: Every time a remote MTA sends a STARTTLS command, the current sendmail instance crashes. I temporarily stopped the server and cranked up the log level to show all incoming and outgoing SMTP commands using /usr/sbin/sendmail -d95.99 -bD -X /tmp/test.log. A typical incoming connection looks like this:
34431 >>> 220 ESMTP Sendmail 8.15.2/8.15.2; Thu, 8 Mar 2018 11:35:32 -0500 (EST)
34431 <<< EHLO []
34431 >>> Hello [], pleased to meet you
34431 >>> 250-PIPELINING
34431 >>> 250-8BITMIME
34431 >>> 250-SIZE
34431 >>> 250-DSN
34431 >>> 250-ETRN
34431 >>> 250-STARTTLS
34431 >>> 250-DELIVERBY
34431 >>> 250 HELP
34431 <<< STARTTLS

and in /var/log/messages I find a corresponding
Mar  8 11:35:32 Dreamer kernel: pid 34431 (sendmail), uid 0: exited on signal 11

I ran find / -name "*.core" -ls to search for core dumps when there wasn't one in /usr/sbin where sendmail is launched from. The search turned up three files created during the upgrade - /usr/ports/distfiles/sh.core, /root/pkg-static.core and /root/pkg.core. All of the ten other core dumps on the system are more than a year old - so none of them are relevant to the current problem where a sendmail process is crashing over a hundred times an hour.

Since my /etc/sysctl.conf is empty, I don't see anything in this answer that would prevent sendmail from creating core dumps.
  1. What would be likely to prevent the .core files from being created?
  2. Is there a crash log somewhere I can look at to figure out what's going on?
  3. What else can I do to debug this problem?
  4. or, better yet, How can I stop sendmail from crashing when a STARTTLS command is received?
Not sure if it's the cause but did you create a /etc/mail/certs/dh.param file?

openssl dhparam -out /etc/mail/certs/dh.param 4096
I re-created the mail-cert.pem yesterday, but the dh.param timestamp is nearly two years ago. I can try regenerating it...
Rebuilding dh.param didn't make a difference.

I'm rather puzzled by there not being any crash dumps resulting from the signal 11 process deaths.
I got it working, I found the answer in DutchDaemon's Dec 12, 2017 reply in the [sendmail] Lots of "did not issue MAIL/EXPN/VRFY/ETRN" logs thread:

A standard install will put something like this in your .mc file:
dnl Enable STARTTLS for receiving email.
define(`CERT_DIR', `/etc/mail/certs')dnl
define(`confSERVER_CERT', `CERT_DIR/host.cert')dnl
define(`confSERVER_KEY', `CERT_DIR/host.key')dnl
define(`confCLIENT_CERT', `CERT_DIR/host.cert')dnl
define(`confCLIENT_KEY', `CERT_DIR/host.key')dnl
define(`confCACERT', `CERT_DIR/cacert.pem')dnl
define(`confCACERT_PATH', `CERT_DIR')dnl
define(`confDH_PARAMETERS', `CERT_DIR/dh.param')dnl

I compared that code block with what was in my server's .mc file, and found it was missing the define(`confDH_PARAMETERS', `CERT_DIR/dh.param')dnl line. I added that, restarted sendmail, and it's working now.

I would still like to know why there were never any .core files generated...
Good find! Odd that it actually crashed though, I would have expected it to produce a failure message and refuse to run, not start and segfault when you try to use it.