Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #6928 > unrolled thread

Mailgun kanns nicht

Back to article view | Back to de.comm.software.mailserver

Contents

  Mailgun kanns nicht Tim Ritberg <tim@server.invalid> - 2023-12-28 10:21 +0100
    Re: Mailgun kanns nicht Andreas Metzler <ametzler@bebt.de> - 2023-12-28 12:11 +0100
      Re: Mailgun kanns nicht Tim Ritberg <tim@server.invalid> - 2023-12-28 12:26 +0100
        Re: Mailgun kanns nicht "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2023-12-28 13:23 +0100
          Re: Mailgun kanns nicht Tim Ritberg <tim@server.invalid> - 2023-12-28 14:03 +0100
            Re: Mailgun kanns nicht Arno Welzel <usenet@arnowelzel.de> - 2023-12-28 14:51 +0100
              Re: Mailgun kanns nicht Tim Ritberg <tim@server.invalid> - 2023-12-28 15:22 +0100
                Re: Mailgun kanns nicht Tim Ritberg <tim@server.invalid> - 2023-12-28 15:41 +0100
        Re: Mailgun kanns nicht Andreas Metzler <ametzler@bebt.de> - 2023-12-28 13:34 +0100
          Re: Mailgun kanns nicht Thomas Hochstein <thh@thh.name> - 2023-12-28 23:43 +0100
            Re: Mailgun kanns nicht Andreas Metzler <ametzler@bebt.de> - 2023-12-29 07:52 +0100
              Re: Mailgun kanns nicht Thomas Hochstein <thh@thh.name> - 2023-12-29 11:00 +0100
                Re: Mailgun kanns nicht Andreas Metzler <ametzler@bebt.de> - 2023-12-29 14:37 +0100
                  Re: Mailgun kanns nicht Thomas Hochstein <thh@thh.name> - 2023-12-29 18:29 +0100
                Re: Mailgun kanns nicht Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-12-29 13:35 +0000
                Re: Mailgun kanns nicht Marcel Logen <333200007110-0201@ybtra.de> - 2023-12-29 16:43 +0100
                  Re: Mailgun kanns nicht Thomas Hochstein <thh@thh.name> - 2023-12-29 18:29 +0100
              Re: Mailgun kanns nicht Christian Garbs <mitch@cgarbs.de> - 2024-01-02 21:00 +0000
                Re: Mailgun kanns nicht Thomas Hochstein <thh@thh.name> - 2024-01-02 22:53 +0100

#6928 — Mailgun kanns nicht

Hi!

Ich habe das schon vor ein paar Wochen beobachtet, Mailgun schafft TLS 
nicht:
SSL_accept error from mail-182-211.mailgun.info[23.253.182.211]: -1
warning: TLS library problem: error:14094412:SSL 
routines:ssl3_read_bytes:sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1543:SSL alert number 42:

Kennt jemand das Problem?
Also andere Server machen keine Probleme...

Tim

[toc] | [next] | [standalone]

#6929

Tim Ritberg <tim@server.invalid> wrote:
> Ich habe das schon vor ein paar Wochen beobachtet, Mailgun schafft TLS 
> nicht:
> SSL_accept error from mail-182-211.mailgun.info[23.253.182.211]: -1
> warning: TLS library problem: error:14094412:SSL 
> routines:ssl3_read_bytes:sslv3 alert bad 
> certificate:../ssl/record/rec_layer_s3.c:1543:SSL alert number 42:
[...]

Im Log welchen Rechners findet sich die Fehlermeldung?

lg Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [prev] | [next] | [standalone]

#6930

Am 28.12.23 um 12:11 schrieb Andreas Metzler:
> Tim Ritberg <tim@server.invalid> wrote:
>> Ich habe das schon vor ein paar Wochen beobachtet, Mailgun schafft TLS
>> nicht:
>> SSL_accept error from mail-182-211.mailgun.info[23.253.182.211]: -1
>> warning: TLS library problem: error:14094412:SSL
>> routines:ssl3_read_bytes:sslv3 alert bad
>> certificate:../ssl/record/rec_layer_s3.c:1543:SSL alert number 42:
> [...]
> 
> Im Log welchen Rechners findet sich die Fehlermeldung?
> 
> lg Andreas


Empfänger.
Ich sehe gerade, es sind verschiedene Einlieferer von Mailgun.

Tim

[toc] | [prev] | [next] | [standalone]

#6931

On 2023-12-28 11:26, Tim Ritberg <tim@server.invalid> wrote:
> Am 28.12.23 um 12:11 schrieb Andreas Metzler:
>> Tim Ritberg <tim@server.invalid> wrote:
>>> Ich habe das schon vor ein paar Wochen beobachtet, Mailgun schafft TLS
>>> nicht:
>>> SSL_accept error from mail-182-211.mailgun.info[23.253.182.211]: -1
>>> warning: TLS library problem: error:14094412:SSL
>>> routines:ssl3_read_bytes:sslv3 alert bad
>>> certificate:../ssl/record/rec_layer_s3.c:1543:SSL alert number 42:
>> [...]
>> 
>> Im Log welchen Rechners findet sich die Fehlermeldung?
>
>
> Empfänger.
> Ich sehe gerade, es sind verschiedene Einlieferer von Mailgun.

Die Fehlermeldung klingt, als ob der Empfänger ein Problem mit dem
Zertifikat des Senders hätte, aber wahrscheinlich ist es eher umgekehrt
(ein paar Fundstellen im Netz bestärken mich in dieser Ansicht).

D.h. Mailgun akzeptiert Dein Zertifikat nicht. Was ist das für ein
Zertifikat? Snake Oil von der Distribution? Self-Signed? Von einer CA
ausgestellt? Wenn letzteres: Von welcher und ist die Chain vollständig?

        hp

[toc] | [prev] | [next] | [standalone]

#6933

Am 28.12.23 um 13:23 schrieb Peter J. Holzer:
> Die Fehlermeldung klingt, als ob der Empfänger ein Problem mit dem
> Zertifikat des Senders hätte, aber wahrscheinlich ist es eher umgekehrt
> (ein paar Fundstellen im Netz bestärken mich in dieser Ansicht).
Da hatte ich leider nichts gefunden.

> 
> D.h. Mailgun akzeptiert Dein Zertifikat nicht. Was ist das für ein
> Zertifikat? Snake Oil von der Distribution? Self-Signed? Von einer CA
> ausgestellt? Wenn letzteres: Von welcher und ist die Chain vollständig?
Ein Fehler ist im Setup.
Ich hatte das mal umgebaut, die Zertifikatsverlängerung lief auf einer 
anderen Datei.

Tim

[toc] | [prev] | [next] | [standalone]

#6934

Tim Ritberg, 2023-12-28 14:03:

> Am 28.12.23 um 13:23 schrieb Peter J. Holzer:
>> Die Fehlermeldung klingt, als ob der Empfänger ein Problem mit dem
>> Zertifikat des Senders hätte, aber wahrscheinlich ist es eher umgekehrt
>> (ein paar Fundstellen im Netz bestärken mich in dieser Ansicht).
> Da hatte ich leider nichts gefunden.
> 
>>
>> D.h. Mailgun akzeptiert Dein Zertifikat nicht. Was ist das für ein
>> Zertifikat? Snake Oil von der Distribution? Self-Signed? Von einer CA
>> ausgestellt? Wenn letzteres: Von welcher und ist die Chain vollständig?
> Ein Fehler ist im Setup.
> Ich hatte das mal umgebaut, die Zertifikatsverlängerung lief auf einer 
> anderen Datei.

D.h. der Fehler ist jetzt beseitigt?

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6935

Am 28.12.23 um 14:51 schrieb Arno Welzel:
> Tim Ritberg, 2023-12-28 14:03:
> 
>> Am 28.12.23 um 13:23 schrieb Peter J. Holzer:
>>> Die Fehlermeldung klingt, als ob der Empfänger ein Problem mit dem
>>> Zertifikat des Senders hätte, aber wahrscheinlich ist es eher umgekehrt
>>> (ein paar Fundstellen im Netz bestärken mich in dieser Ansicht).
>> Da hatte ich leider nichts gefunden.
>>
>>>
>>> D.h. Mailgun akzeptiert Dein Zertifikat nicht. Was ist das für ein
>>> Zertifikat? Snake Oil von der Distribution? Self-Signed? Von einer CA
>>> ausgestellt? Wenn letzteres: Von welcher und ist die Chain vollständig?
>> Ein Fehler ist im Setup.
>> Ich hatte das mal umgebaut, die Zertifikatsverlängerung lief auf einer
>> anderen Datei.
> 
> D.h. der Fehler ist jetzt beseitigt?
> 
Kann sein sein. Mailgun hat es aber noch nicht wieder versucht.
Mailgun hatte heute 8 Versuche mit 2 Server auf 2 MXer von mir gemacht.
Davor war tagelang nichts. Andere Server haben keine SSL-Fehler verursacht.
Ich bin mal sehr gespannt, ob da überhaupt was eingeliefert wird und für 
wen.

Tim

[toc] | [prev] | [next] | [standalone]

#6936

Am 28.12.23 um 15:22 schrieb Tim Ritberg:

> Ich bin mal sehr gespannt, ob da überhaupt was eingeliefert wird ... 
Von travelsbroker.com und weggefiltert von NiX Spam.

:D

Tim

[toc] | [prev] | [next] | [standalone]

#6932

Tim Ritberg <tim@server.invalid> wrote:
> Am 28.12.23 um 12:11 schrieb Andreas Metzler:
>> [...]
>> Im Log welchen Rechners findet sich die Fehlermeldung?

> Empfänger.
[...]

Das war klar, du bist ja nicht der admin von Mailgun.

Irgendwas mit deinem Zertifikat wird wahrscheinlich nicht stimmen.
Wenn du uns sagen könntet, auf welchem Rechner das Problem auftritt
könnten Hilfewillige diese These testen.

Eine möglichst informative Antwort wäre z.B. "der MX von tota-refugium.de".

lg Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [prev] | [next] | [standalone]

#6937

Andreas Metzler schrieb:

> Eine möglichst informative Antwort wäre z.B. "der MX von tota-refugium.de".

Unwahrscheinlich. :)

[toc] | [prev] | [next] | [standalone]

#6938

Thomas Hochstein <thh@thh.name> wrote:
> Andreas Metzler schrieb:

>> Eine möglichst informative Antwort wäre z.B. "der MX von tota-refugium.de".

> Unwahrscheinlich. :)

Die gute Tat im alten Jahr:

ametzler@argenau:/tmp$ host -t mx thh.name
thh.name mail is handled by 100 mx01.thangorodrim.org.
thh.name mail is handled by 200 mx03.thangorodrim.org.
ametzler@argenau:/tmp$ gnutls-cli --starttls-proto smtp mx01.thangorodrim.org
Processed 140 CA certificate(s).
Resolving 'mx01.thangorodrim.org:smtp'...
Connecting to '2a01:4f8:10b:687::2:25'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=moria.thangorodrim.org', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x039767bdd5c9ecccf5069de4915fb4eabf19, RSA key 2048 bits, signed using RSA-SHA256, activated `2023-11-02 20:00:06 UTC', expires `2024-01-31 20:00:05 UTC', pin-sha256="eloEjDJ0UI7B0HnVQjiCS29+INxuHOw8ujCpY33Qg6o="
        Public Key ID:
                sha1:6665c01b0f7c95bb06bbc5b02fb4232e9b438c18
                sha256:7a5a048c3274508ec1d079d54238824b6f7e20dc6e1cec3cba30a9637dd083aa
        Public Key PIN:
                pin-sha256:eloEjDJ0UI7B0HnVQjiCS29+INxuHOw8ujCpY33Qg6o=
[...]
- Status: The certificate is NOT trusted. The name in the certificate does not match the expected.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
ametzler@argenau:/tmp$ gnutls-cli --starttls-proto smtp mx03.thangorodrim.org
Processed 140 CA certificate(s).
Resolving 'mx03.thangorodrim.org:smtp'...
Connecting to '2a01:4f8:c17:4ed2::2:25'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=weidegrund.szaf.org', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x045cb256b992c71853f4c39f017cfbc5d9fa, RSA key 2048 bits, signed using RSA-SHA256, activated `2023-11-20 01:45:07 UTC', expires `2024-02-18 01:45:06 UTC', pin-sha256="LyK4bbYmJBIlR/4odRNn2UY2aqGG0AxztebdrEVv/io="
        Public Key ID:
                sha1:d5d0495c10cf07e20bbfd75e540acbb41ede6878
                sha256:2f22b86db62624122547fe28751367d946366aa186d00c73b5e6ddac456ffe2a
        Public Key PIN:
                pin-sha256:LyK4bbYmJBIlR/4odRNn2UY2aqGG0AxztebdrEVv/io=
[...]
- Status: The certificate is NOT trusted. The name in the certificate does not match the expected.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

Ich sehe da drei offensichtliche Lösungsmöglichkeiten: Entweder müsste
die MX Einträge auf moria.thangorodrim.org/weidegrund.szaf.org statt
mx*.thangorodrim.org zeigen, oder die Zertifikate der MX bräuchten
entsprechend Subject Alternative Name Einträge oder die MX müssen
SNI-abhängig passende Zertifikate verwenden.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [prev] | [next] | [standalone]

#6939

Andreas Metzler schrieb:

> Die gute Tat im alten Jahr:

Oh. Oh!

Danke.

> ametzler@argenau:/tmp$ gnutls-cli --starttls-proto smtp mx01.thangorodrim.org
> Processed 140 CA certificate(s).
> Resolving 'mx01.thangorodrim.org:smtp'...
> Connecting to '2a01:4f8:10b:687::2:25'...
> - Certificate type: X.509
> - Got a certificate list of 3 certificates.
> - Certificate[0] info:
>  - subject `CN=moria.thangorodrim.org', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x039767bdd5c9ecccf5069de4915fb4eabf19, RSA key 2048 bits, signed using RSA-SHA256, activated `2023-11-02 20:00:06 UTC', expires `2024-01-31 20:00:05 UTC', pin-sha256="eloEjDJ0UI7B0HnVQjiCS29+INxuHOw8ujCpY33Qg6o="
>         Public Key ID:
>                 sha1:6665c01b0f7c95bb06bbc5b02fb4232e9b438c18
>                 sha256:7a5a048c3274508ec1d079d54238824b6f7e20dc6e1cec3cba30a9637dd083aa
>         Public Key PIN:
>                 pin-sha256:eloEjDJ0UI7B0HnVQjiCS29+INxuHOw8ujCpY33Qg6o=
> [...]
> - Status: The certificate is NOT trusted. The name in the certificate does not match the expected.
> *** PKI verification of server certificate failed...
> *** Fatal error: Error in the certificate.

Unfortunate.

> Ich sehe da drei offensichtliche Lösungsmöglichkeiten: Entweder müsste
> die MX Einträge auf moria.thangorodrim.org/weidegrund.szaf.org statt
> mx*.thangorodrim.org zeigen,

Das wäre bei der Pflege der diversen Zonen im Falle einer notwendigen
Änderung eher ... sehr aufwendig. So muss ich nur an einer (naja, zwei)
Stellen die IP(s) ändern statt bei einer größeren Anzahl Domains die
MX-Einträge.

> oder die Zertifikate der MX bräuchten
> entsprechend Subject Alternative Name Einträge

Das ist auch nicht so wirklich schön, weil die Zertifikate natürlich auch
für andere Dienste als SMTP verwendet werden, andererseits aber auch
wieder egal, denn wer schaut schon üblicherweise nach den SANs in einem
Zertifikat?

> oder die MX müssen
> SNI-abhängig passende Zertifikate verwenden.

Das scheint mir nicht sicher unterstützt zu werden, und wenn ich mal zum
Upgrade auf eine aktuelle Debian-Version mit einem aktuellen Exim komme,
wird das eh ein Taint-Alptraum, da will ich mir mit tls_sni_in nicht noch
eine "tainted" Variable ans Bein binden. :)

Danke für den Hinweis, das hatte ich echt nicht auf dem Schirm (vor allem,
dass jemand bei SMTP-Verbindungen das Zertifikat nicht schlicht zur
Transportverschlüsselung nutzt, sondern tatsächlich validiert).

Sollte jetzt passen.

(Hat jemand zufällig einen Tip zur Hand, wie man die Zertifikatskette in
ähnlicher Weise mit OpenSSL statt GnuTLS prüft?)

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

[toc] | [prev] | [next] | [standalone]

#6940

Thomas Hochstein <thh@thh.name> wrote:
> Andreas Metzler schrieb:
[..]
>> ametzler@argenau:/tmp$ gnutls-cli --starttls-proto smtp mx01.thangorodrim.org
[...]
> Sollte jetzt passen.

Hallo Thomas,

ich finde den Fehler jedenfalls nicht. :-)

> (Hat jemand zufällig einen Tip zur Hand, wie man die Zertifikatskette in
> ähnlicher Weise mit OpenSSL statt GnuTLS prüft?)

Ich glaube das hier sollte dasselbe leisten:
openssl s_client  -starttls smtp -connect mx01.thangorodrim.org:25 -verify_hostname mx01.thangorodrim.org

lg Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [prev] | [next] | [standalone]

#6943

Andreas Metzler schrieb:

> Thomas Hochstein <thh@thh.name> wrote:
>> Sollte jetzt passen.
> 
> ich finde den Fehler jedenfalls nicht. :-)

Die webbasierten Tester, die ich angestoßen habe, auch nicht mehr. :)

>> (Hat jemand zufällig einen Tip zur Hand, wie man die Zertifikatskette in
>> ähnlicher Weise mit OpenSSL statt GnuTLS prüft?)
> 
> Ich glaube das hier sollte dasselbe leisten:
> openssl s_client  -starttls smtp -connect mx01.thangorodrim.org:25 -verify_hostname mx01.thangorodrim.org

Sehr schön, herzlichen Dank!

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

[toc] | [prev] | [next] | [standalone]

#6941

Thomas Hochstein <thh@thh.name> wrote:
> 
> Sollte jetzt passen.
> 
> (Hat jemand zufällig einen Tip zur Hand, wie man die Zertifikatskette in
> ähnlicher Weise mit OpenSSL statt GnuTLS prüft?)

Sowas in der Art:

#v+
$ openssl s_client -verify_return_error -starttls smtp -connect mx03.thangorodrim.org:25
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = weidegrund.szaf.org
verify return:1
---
Certificate chain
 0 s:CN = weidegrund.szaf.org
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 29 08:46:55 2023 GMT; NotAfter: Mar 28 08:46:54 2024 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=CN = weidegrund.szaf.org
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4833 bytes and written 440 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 HELP
QUIT
DONE
#v-

Da du es ja gefixt hast, jetzt eben kein Fehler.

openssl s_client hat noch ein paar weitere Optionen zur Verifikation, s.
man page.

Wenn absichtlich einen falschen Hostnamen verlangt, kann man den
Fehlerfall simulieren:

#v+
$ openssl s_client -verify_return_error -verify_hostname blubb -starttls smtp -connect mx03.thangorodrim.org:25
CONNECTED(00000003)
depth=0 CN = weidegrund.szaf.org
verify error:num=62:hostname mismatch
4057FE3C437F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:../openssl-3.0.11/ssl/statem/statem_clnt.c:1889:
---
Certificate chain
 0 s:CN = weidegrund.szaf.org
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 29 08:46:55 2023 GMT; NotAfter: Mar 28 08:46:54 2024 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4473 bytes and written 367 bytes
Verification error: hostname mismatch
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 62 (hostname mismatch)
---
#v-

Gruß,
Enrik

[toc] | [prev] | [next] | [standalone]

#6942

Thomas Hochstein in de.comm.software.mailserver:

>(Hat jemand zufällig einen Tip zur Hand, wie man die Zertifikatskette in
>ähnlicher Weise mit OpenSSL statt GnuTLS prüft?)

Wenn's nur ums Verifizieren der Kette geht (außerhalb von
s_client) und Dir das Serverzertifikat (weidegrund.pem) und
das Intermediate-Zert. (r3.pem) vorliegen, sollte das IMHO
so gehen (hier bei mir noch mit OpenSSL/1.1.1n):

| user15@o15:/tmp$ openssl version 
| OpenSSL 1.1.1n  15 Mar 2022

| user15@o15:/tmp$ cat /etc/debian_version 
| 10.13

| user15@o15:/tmp$ openssl verify -show_chain -x509_strict -purpose sslserver -verify_hostname weidegrund.szaf.org -no-CApath -untrusted r3.pem weidegrund.pem 
| C = US, O = Let's Encrypt, CN = R3
| error 20 at 1 depth lookup: unable to get local issuer certificate
| error weidegrund.pem: verification failed

Da wurde wegen "-no-CApath" das Root-Zertifikat aus dem
lokalen trust store nicht gefunden.

| user15@o15:/tmp$ openssl verify -show_chain -x509_strict -purpose sslserver -verify_hostname weidegrund.szaf.org            -untrusted r3.pem weidegrund.pem 
| weidegrund.pem: OK
| Chain:
| depth=0: CN = weidegrund.szaf.org (untrusted)
| depth=1: C = US, O = Let's Encrypt, CN = R3 (untrusted)
| depth=2: C = US, O = Internet Security Research Group, CN = ISRG Root X1

| user15@o15:/tmp$ openssl verify -show_chain -x509_strict -purpose sslserver -verify_hostname weidegrund.zzaf.org            -untrusted r3.pem weidegrund.pem 
| CN = weidegrund.szaf.org
| error 62 at 0 depth lookup: Hostname mismatch
| error weidegrund.pem: verification failed
| user15@o15:/tmp$ 

Marcel
-- 
───╮      ╭───────────╮     ╭────╮  ╭───╮              ..56..╭─────╮ ╭─╯
 ╭─╯ ╭─╮  ╰────────╮  ╰─────╯  ╭─╯  ╰─╮ ╰─╮            ..56..╰──╮  ╰─╯  
 ╰─╮ │ │   ╭──╮  ╭─╯           │ ╭─╮  ╰─╮ ╰──╮ ╭────╮   ╭──╮ ╭──╯ ..67..
   ╰─╯ ╰───╯  ╰──╯             ╰─╯ ╰────╯    ╰─╯    ╰───╯  ╰─╯    ..67..

[toc] | [prev] | [next] | [standalone]

#6944

Marcel Logen schrieb:

> Wenn's nur ums Verifizieren der Kette geht (außerhalb von
> s_client) und Dir das Serverzertifikat (weidegrund.pem) und
> das Intermediate-Zert. (r3.pem) vorliegen, sollte das IMHO
> so gehen (hier bei mir noch mit OpenSSL/1.1.1n):

Danke, aber mir ging es weniger um die Zertifikate an sich, sondern ob
Exim das Zertifikat auch gefressen hat und es tatsächlich bei
TLS-Verbindungen jetzt positiv prüfbar ist.

-thh

[toc] | [prev] | [next] | [standalone]

#6948

Frohes Neues!

Andreas Metzler <ametzler@bebt.de> wrote:

> Die gute Tat im alten Jahr:
> 
> ametzler@argenau:/tmp$ host -t mx thh.name
> thh.name mail is handled by 100 mx01.thangorodrim.org.
> thh.name mail is handled by 200 mx03.thangorodrim.org.
> ametzler@argenau:/tmp$ gnutls-cli --starttls-proto smtp mx01.thangorodrim.org

Och Jungs, nein, was soll denn das!  Ich hab doch schon genug zu tun.
HTTPS passt, aber IMAP, NNTPS, SMTP und SUBMISSION sind bei mir vergurkt :/

Flugs ins Nomitoring mit aufgenommen (openssl-Style)
https://github.com/mmitch/nomd/commit/e3bafbac88db28eed3fad2312e3dcc83091c4888
und jetzt lasse ich mich solange annölen, bis ich dazu komme, dazu
bereinigen :)


Vielen Dank für den Hinweis!
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Error: missing signature

[toc] | [prev] | [next] | [standalone]

#6949

Christian Garbs schrieb:

> Och Jungs, nein, was soll denn das!  Ich hab doch schon genug zu tun.

Ja, das kenne ich. :-/

-thh

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web