Schlagwort: Selflart

Apache, CentOS 7, gestacktes Zertifikat

Mal wie­der einer aus der Ecke #sel­flart:

Ein Kauf­zer­ti­fi­kat läuft aus und soll durch ein LE-Zer­ti­fi­kat ersetzt wer­den. Kein Ding. Tau­send­mal berührt, tau­send­mal ist nichts pas­siert.
Alt:

  SSLCertificateFile /path/to/certificate.crt
  SSLCertificatekeyFile /path/to/privkey.key
  SSLCertificateChainFile /path/to/chain.crt

SSLCer­ti­fi­ca­teChain­File ist aller­dings depre­ca­ted, man soll Zer­ti­fi­kat und Chain stacken.
Kein Problem!

  SSLCertificateFile /path/to/le/fullchain.pem
  SSLCertificatekeyFile /path/to/le/privkey.pem

Web­ser­ver rel­oa­ded, mit openssl s_client … | openssl x509… gegen­ge­scheckt, alles fein.

Ein Tag spä­ter fällt auf: Builds gehen nicht mehr, Java mault mit kryp­ti­schen Stack­traces über kaput­tes SSL. Pha­se eins Arsch­kar­ten­rou­ting (da bin ich ein eben­bür­ti­ger Mit­spie­ler): Fixt euer gamm­li­ges Java, daß es auch mit LE zuran­de kommt!. Jira-Tickets ent­ste­hen. Man glaubt gar nicht, wie groß ein Jira-Ticket wer­den kann, bevor über­haupt jemand an dem Pro­blem arbeitet!
Jeden­falls, um es abzu­kür­zen: Nach Pha­se n Arsch­kar­ten­rou­ting stellt sich raus: Der Web­ser­ver sen­det nur sein eige­nes Zer­ti­fi­kat, nicht aber das Inter­me­dia­te aus fullchain.pem.
Die Lösung ist damit klar:

  SSLCertificateFile /path/to/le/cert.pem
  SSLCertificateChainFile /path/to/le/chain.pem
  SSLCertificatekeyFile /path/to/le/privkey.pem

Argh!

0

Das Tolle an Linux/postfix

ist ja, daß die Waf­fen gela­den und aus­ge­rich­tet sind.
Und root hat die Macht über den Abzugshahn.

Heu­te also Fol­ge 4711 #Sel­flart.

Da der Exchan­ge hin­ten sowie­so .exe und Co. nicht ent­ge­gen­nimmt, muß mein Post­fix vor­ne das ja auch nicht tun. So dann! Mut!

root@mx1:~# grep ^mime_header_checks /etc/postfix/main.cf
mime_header_checks = regexp:/etc/postfix/mime_header_checks
root@mx1:~# cat /etc/postfix/mime_header_checks
/name=[^>]*\.(bat|com|exe|dll|mht|vbs)/ REJECT
/name=[^>][0-9]+\.docx{,1}/ REJECT
root@mx1:~#

So soll es sein (Die zwei­te Zei­le bezieht sich auf die­se Hei­se-Mel­dung)
Doch was ist das?

root@mx1:~# grep E81BF5FFE3 /var/log/mail.info
May  7 11:04:53 mx1 postfix/smtpd[30608]: E81BF5FFE3: client=sonic328-45.consmr.mail.ne1.yahoo.com[66.163.191.20]
May  7 11:04:54 mx1 postfix/cleanup[30568]: E81BF5FFE3: message-id=<1557213647.728781@dmarc.yahoo.com>
May  7 11:04:54 mx1 postfix/cleanup[30568]: E81BF5FFE3: reject: header Content-Disposition: attachment; filename="aol.com!example.net!1557100800!1557187199.xml.gz" from sonic328-45.consmr.mail.ne1.yahoo.com[66.163.191.20]; from=<noreply@dmarc.yahoo.com> to=<dmarc-report@example.net> proto=ESMTP helo=: 5.7.1 message content rejected
root@mx1:~#

Hä? Wie­so das denn? Ist doch alles in Ordnung?
Kopf­kratz. Nein, es ist nicht alles in Ord­nung. Im Namen des Attach­ments steht aol.com.

Die kor­rek­te Zei­le muß also lau­ten, *trom­mel­wir­bel*

/name=[^>]*\.(bat|com|exe|dll|mht|vbs)$/ REJECT

Und alles ist wie­der schön.

OT: Wür­de post­fix mit­tels jour­nald log­gen, hät­te ich den Feh­ler wohl nie gesehen…

0