Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

[Andreas Schulze]

Am 17.09.2017 um 16:37 schrieb Friedemann Stoyan:
> Liebe Mailserverbetreiber!
> 
> Ich habe meinen internen Mailserver auf Debian 9.1 geupdatet. Leider ist dabei
> das zertifikatsbasierende Relaying kaputt gegangen.
> 
> Folgendes Setup: Ein Client zeigt sein Zertifikat vor und wird anhand des SHA1
> Fingerprints für das Relaying erlaubt.
> 
> Die relevante Konfiguration:
> 
> # TLS parameters
> # TLS Server
> smtpd_tls_fingerprint_digest = sha1
> smtpd_tls_loglevel = 2
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/postfix/certs/mail-smtpd.crt
> smtpd_tls_key_file = /etc/postfix/certs/mail-smtpd.key
> smtpd_tls_CApath = /etc/ssl/certs
> smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
> smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem
> smtpd_tls_ask_ccert = yes
> smtpd_tls_security_level = may
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
Da Du von Debian 9.1 sprichst, gehe ich von postfix-3.1.4 aus. Und *da* würde ich den Default-Wert (leer) bleiben.
siehe http://marc.info/?l=postfix-users&m=143796843615367

> smtpd_tls_session_cache_timeout = 3600s
Default-Wert, hat eigentlich nichts in der main.cf zu suchen

> smtpd_use_tls=yes
löschen, ab postfix 2.3 wird TLS über smtpd_tls_security_level gesteuert

> 
> # list of clientcerts for the permit_tls_clientcerts feature
> relay_clientcerts = btree:/etc/postfix/relay_clientcerts
> 
> # relay checks
> smtpd_recipient_restrictions =
>   check_recipient_access btree:/etc/postfix/discards
>   permit_mynetworks
>   #permit_tls_clientcerts
>   check_ccert_access btree:/etc/postfix/relay_clientcerts
>   reject_unauth_destination
>   ...
>   permit
> 
> 
> $ cat /etc/postfix/relay_clientcerts
> 86:D8:7D:8E:4F:10:70:43:A1:43:85:F8:E0:A3:5A:34:45:0A:39:91     OK
> E2:10:FB:E7:4A:CA:8D:A5:B6:95:61:E5:28:B0:FD:33:7E:B3:BD:86     OK

Du hast offenbar aus $Verzweiflung? den Fingerprint des Zertifikates und des Öffentlichen Schlüssels in der relay_clientcerts.
( postmap & reload nicht vergessen??? )


> Im Logfile sieht das dann so aus:
> 
> Sep 17 15:55:15 intrepid postfix/smtpd[25651]: excelsior.lab.swapon.de[192.168.19.10]: subject_CN=excelsior.lab.swapon.de, issuer=CA, fingerprint=86:D8:7D:8E:4F:10:70:43:A1:43:85:F8:E0:A3:5A:34:45:0A:39:91, pkey_fingerprint=E2:10:FB:E7:4A:CA:8D:A5:B6:95:61:E5:28:B0:FD:33:7E:B3:BD:86
> Sep 17 15:55:15 intrepid postfix/smtpd[25651]: Trusted TLS connection established from excelsior.lab.swapon.de[192.168.19.10]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Sep 17 15:55:15 intrepid postfix/smtpd[25651]: NOQUEUE: reject: RCPT from excelsior.lab.swapon.de[192.168.19.10]: 454 4.7.1 <echo at tu-berlin.de>: Relay access denied; from=<fstoyan at labbb.swapon.de> to=<echo at tu-berlin.de> proto=ESMTP helo=<excelsior.lab.swapon.de>
> 
> Für mich sieht das so aus, als ob permit_tls_clientcerts oder auch check_ccert_access
> völlig ohne Wirkung bleiben. Obwohl ja der Fingerprint im Logfile korrekt
> angezeigt wird. Manuell kann ich diesen auch finden:
> 
> $ postmap -q E2:10:FB:E7:4A:CA:8D:A5:B6:95:61:E5:28:B0:FD:33:7E:B3:BD:86 /etc/postfix/relay_clientcerts
> OK
> $ postmap -q 86:D8:7D:8E:4F:10:70:43:A1:43:85:F8:E0:A3:5A:34:45:0A:39:91 /etc/postfix/relay_clientcerts
> OK
> 
> Vor dem Upgrade klappe alles wunderbar. Irgendwie bin ich jetzt ratlos. Hat
> jemand eine Idee, oder das selbe Problem?

bis auf die 3 Punkte oben schaut's eigentlich ordentlich aus. Ich habe ein ähnliches Setup (aber halt kein Debian Postfix).

Ansonsten kannst Du mal mit 
# postconf -e "debug_peer_list=192.168.19.10"; postfix reload
debugging für den Client anschalten und schauen, mit welchen Parametern Postfix in welche Map reingeht und was da für Ergebnisse kommen.

Ansonsten ist die inline-map auch schick zum Probieren:
 check_ccert_access inline:{E2:10:FB:E7:4A:CA:8D:A5:B6:95:61:E5:28:B0:FD:33:7E:B3:BD:86=permit_auth_destination}
um testweise Probleme mit btree auszuschließen :-)

> 
> mfg Friedemann
> 

Andreas


-- 
A. Schulze
DATEV eG