Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

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
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls=yes

# 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

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 <[hidden email]>: Relay access denied; from=<[hidden email]> to=<[hidden email]> 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?

mfg Friedemann
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>: Relay access denied; from=<[hidden email]> to=<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

Stefan Förster-4
In reply to this post by Friedemann Stoyan
* Friedemann Stoyan <[hidden email]>:
> 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:

Ist da evt. der "compatibility level" hoch gesetzt worden und Du hast
jetzt ein nicht-leeres "smtpd_relay_restrictions"-Setting?


Ciao,
Stefan
Reply | Threaded
Open this post in threaded view
|

Re: Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

Friedemann Stoyan
In reply to this post by Andreas Schulze
On 18.09.17 09:19, Andreas Schulze wrote:

> 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

OK. Alles angepasst.

> > $ 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??? )

Woher weisst Du…?

> 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 :-)

Ein bisschen rumdebugt. Es entwickelt sich eher in Richtung
smtpd_relay_restrictions.

mfg Friedemann
Reply | Threaded
Open this post in threaded view
|

Re: Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

Friedemann Stoyan
In reply to this post by Stefan Förster-4
On 18.09.17 09:45, Stefan Förster wrote:
> * Friedemann Stoyan <[hidden email]>:
> > 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:
>
> Ist da evt. der "compatibility level" hoch gesetzt worden und Du hast
> jetzt ein nicht-leeres "smtpd_relay_restrictions"-Setting?

Ja. Genau das scheint es zu sein. Setze ich smtpd_relay_restrictions auf einen
leeren Wert, klappt alles wieder wie früher.

Ich habe spasseshalber versucht, die Zertifikatschecks in
smtpd_relay_restrictions unterzubringen, so:

smtpd_relay_restrictions =
  permit_mynetworks
  #check_ccert_access btree:/etc/postfix/relay_clientcerts
  permit_tls_clientcerts
  permit_sasl_authenticated
  defer_unauth_destination

Leider klappt das nicht (beide Varianten: check_ccert_access als auch
permit_tls_clientcerts). Wieso eigentlich nicht?

mfg Friedemann
Reply | Threaded
Open this post in threaded view
|

Re: Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

Stefan Förster-4
* Friedemann Stoyan <[hidden email]>:
> smtpd_relay_restrictions =
>   permit_mynetworks
>   #check_ccert_access btree:/etc/postfix/relay_clientcerts
>   permit_tls_clientcerts
>   permit_sasl_authenticated
>   defer_unauth_destination

Hast Du parallel dazu die für Relaying relevanten Restriktionen aus
smtpd_recipient_restrictions entfernt?


Ciao,
Stefan
Reply | Threaded
Open this post in threaded view
|

Re: Debian9 postfix 3.1.4-7: Zertifikatsbasierendes Relaying defekt

Friedemann Stoyan
On 19.09.17 11:47, Stefan Förster wrote:

> Hast Du parallel dazu die für Relaying relevanten Restriktionen aus
> smtpd_recipient_restrictions entfernt?

Das war wohl der Fehler. Ich habe jetzt eine Konfiguration, die
zufriedenstellend läuft:

# Relay control (Postfix 2.10 and later): local clients and
# authenticated clients may specify any destination domain.
smtpd_relay_restrictions =
  permit_mynetworks
  check_ccert_access btree:/etc/postfix/relay_clientcerts
  permit_sasl_authenticated
  defer_unauth_destination

# Spam control: exclude local clients and authenticated clients
smtpd_recipient_restrictions =
  check_recipient_access btree:/etc/postfix/discards
  permit_mynetworks
  check_ccert_access btree:/etc/postfix/relay_clientcerts
  check_recipient_access btree:/etc/postfix/postmaster
  check_sender_access btree:/etc/postfix/sender_checks
  check_helo_access btree:/etc/postfix/helo_access
  reject_unknown_reverse_client_hostname
  reject_non_fqdn_recipient
  reject_non_fqdn_sender
  permit


Vielen Dank allen hefenden!

mfg Friedemann