Offenbar bleibt das SBRS auf einer Ironport gelegentlich „stecken“:
Die Abhilfe ist ein manuelles Update durchzuführen:

(Machine ironport-mail1.mediaprint.co.at)> senderbasestatus

SenderBase Host Status
Status as of:                    Thu Mar 17 12:51:51 2016 CET
Host success/fail:               fail

SBRS Status
Status as of:                    Thu Mar 17 12:51:51 2016 CET
Host success/fail:               fail

SenderBase Network Participation Status
Time of last SenderBase upload:  never

(Machine ironport-mail1.mediaprint.co.at)> repengstatus

  Component                   Last Update                     Version
  Reputation Engine           15 Jun 2015 01:38 (GMT +00:00)  1.2.0-079
  Reputation Engine Tools     15 Jun 2015 01:38 (GMT +00:00)  1.2.0-079

(Machine ironport-mail1.mediaprint.co.at)> repengupdate force


tail updater_logs

Press Ctrl-C to stop.
Thu Mar 17 12:52:00 2016 Info: case beginning download of remote file "http://updates.ironport.com/case/2.0/dfa_updates/default/1458215477813444"
Thu Mar 17 12:52:00 2016 Info: case released download lock
Thu Mar 17 12:52:00 2016 Info: case successfully downloaded

…

Thu Mar 17 12:53:53 2016 Info: repeng cleaning up base dir [bindir]
Thu Mar 17 12:53:53 2016 Info: repeng verifying applied files
Thu Mar 17 12:53:53 2016 Info: repeng updating the client manifest
Thu Mar 17 12:53:53 2016 Info: repeng update completed
Thu Mar 17 12:53:53 2016 Info: repeng waiting for new updates

(Machine ironport-mail1.mediaprint.co.at)> senderbasestatus

SenderBase Host Status
Status as of:                    Thu Mar 17 12:54:23 2016 CET
Host success/fail:               success

SBRS Status
Status as of:                    Thu Mar 17 12:54:24 2016 CET
Host success/fail:               success

SenderBase Network Participation Status
Time of last SenderBase upload:  never

(Machine ironport-mail1.mediaprint.co.at)> repengstatus

  Component                   Last Update                     Version
  Reputation Engine           17 Mar 2016 11:53 (GMT +00:00)  1.2.0-079
  Reputation Engine Tools     17 Mar 2016 11:53 (GMT +00:00)  1.2.0-079

Abschließend kann man testen, ob die Updater-Seite überhaupt erreichbar ist:

(Machine ironport-mail1.mediaprint.co.at)> telnet phonehome.senderbase.org 443

Trying 208.90.58.115...
Connected to phonehome.senderbase.org.
Escape character is '^]'.
quit

Normalerweise verwendet der Courier-Server für seine SSL-verschlüsselten Verbindungen (pop3-ssl und imap-ssl) selbstsignierte Zertifikate. Will man eigene offizielle Zertifikate verwenden, so müssen das Zertifikat und der private Schlüssel in einer Datei vorliegen.
Privater Schlüssel: /etc/ssl/example.com.key
Zertifikat: /etc/ssl/example.com.crt

cat /etc/ssl/example.com.key /etc/ssl/example.com.crt >> /etc/courier/imapd.pem

Ein zweiter Schritt ist ein starker DH-Schlüssel. Ich habe einen mit 4096 bits erstellt:

openssl dhparam -out /etc/courier/dhparams.pem 4096

Hintergrund für den starken Schlüssel: defaultmäßig wird ein DH-Schlüssel mit 768 bit ausgestellt. Dieser wird für z.B. von Thunderbird als (zu Recht) zu schwach empfunden und die Verbindung zum Courier-Server nicht aufgebaut.

Laut dem Wiki von Monit Enable SSL in Monit sind folgende Einträge in der Konfigurationsdatei /etc/monit/monitrc notwendig:

set httpd port 2812 and
    use address servername
    ssl enable
    PEMFILE /path_to_certificate/monit.pem
    allow user:passwort

Die PEM-Datei enthält dem privaten Schlüssel und das Zertifikat. Erzeugt habe ich die Datei mit:

cat domain.key domain.crt > monit.pem

Die Datei domain.key beinhaltet den privaten Schlüssel, die Datei domain.crt die komplette Zertifikatskette Server-Zertifikat – Intermidiate-Zertifikat – Root-Zertifikat.

Danach den Monit-Prozess neu starten (Befehl für systemd-Systeme):

systemctl restart monit.service

Befehl für SysV-Systeme unter Debian:

service monit restart

Der Monitserver ist jetzt mit https://servername:2812 erreichbar.