[MEGOLDVA] t-online smarthost nem fogad levelet

Web, mail, IRC, IM, hálózatok

Van egy saját domainem, az emailt is erről intézem. Az Odroidon futó OpenSMTP-6.8 a T-Online smarthost segítségével küldi ki a leveleket, ez a módszer vált eddig be a legjobban.

Vasárnap (12.01) óta a kimenő leveleim nem mennek el. Az OpenSMTP logban ezt látom:

Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp connected address=192.168.1.1 host=sagemcom
Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp authentication user=transitive result=ok
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp message msgid=14246fd3 size=635 nrcpt=1 proto=ESMTP
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp envelope evpid=14246fd31c10153b from=<transitive@akarmi.hu> to=<transitive@celcim.hu>
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp disconnected reason=quit
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta connecting address=smtp+tls://84.2.46.3:25 host=mail.t-online.hu
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta connected
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta error reason=SSL certificate check failed
Dec 03 06:24:49 486 smtpd[3150]: smtp-out: Disabling route [] <-> 84.2.46.3 (mail.t-online.hu) for 15s
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta connecting address=smtp+tls://84.2.44.3:25 host=mail.t-online.hu
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta connected
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta error reason=SSL certificate check failed
Dec 03 06:24:51 486 smtpd[3150]: smtp-out: Disabling route [] <-> 84.2.44.3 (mail.t-online.hu) for 15s
Dec 03 06:24:53 486 smtpd[3150]: smtp-out: No valid route for [connector:[]->[relay:mail.t-online.hu,port=25,smtp+tls,auth=cred:t-online,mx],0x0]
Dec 03 06:25:00 486 smtpd[3150]: 0000000000000000 mta delivery evpid=14246fd31c10153b from=<transitive@akarmi.hu> to=<transitive@celcim.hu> rcpt=<-> source="-" relay="mail.t-online.hu" delay=12s result="TempFail" stat="Network error on destination MXs"
Dec 03 06:25:04 486 smtpd[3150]: smtp-out: Enabling route [] <-> 84.2.46.3 (mail.t-online.hu)
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp connected address=154.203.197.56 host=<unknown>
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid command: Command not supported"
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp disconnected reason=disconnect
Dec 03 06:25:06 486 smtpd[3150]: smtp-out: Enabling route [] <-> 84.2.44.3 (mail.t-online.hu)

A certificate még évekig jó, nem járt le. Nekem kicsit gyanús, hogy "kerek dátummal" (12.01) leállították a t-online smarthostot, vagy valamit módosítottak rajta. Egyelőre nem tudom kideríteni, mi történt.

Ha valakinek van infója, azt megköszönném, illetve ötleteket is szívesen fogadok, mi mehetett félre. A küldés SMTP+TLS-sel stb megy, nem titkosítatlan 25-ös porton keresztül...

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Kisilabizáltam, hogy snq- a következő parancs kimenetéből idézett (ez nekem új volt):

openssl s_client -host mail.t-online.hu -port 465

és itt valóban benne van a certificate panasz. Ha jól értelmezem, a "chain of trust" sérült meg, mivel nem volt a gépemen root certificate (?), amivel a T-Online certjét verifikálni lehetett volna. 11.30-ig volt, valószínűleg 12.01-én lecseréltek a certet egy Sectigosra.

Debianon az /usr/share/ca-cerificates alatt van egy rakat cert, ide kellett betenni a mail.t-online.hu-hoz tartozó root certet, majd hívni egy update-ca-certificates -et.

Fedorán nem találtam előre telepített certeket, itt az /etc/pki-ca-trust/source/anchors könyvtárba kellett bemásolni a hiányzó certet, majd kiadni az update-ca-trust parancsot.

Ezek után a feljebb leírt openssl s_client ... parancs már nem panaszkodik, és az OpenSMTPd-m is szépen tud küldeni levelet ismét mindenhiova.

Köszönöm a segítséget!

  • 750 megtekintés

( snq- | 2024. 12. 03., k – 11:25 )

SSL handshake has read 3162 bytes and written 415 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 4096 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)

 

The “error:num=21:unable to verify the first certificate” means that chain of trust is broken right from the start. Typically it might happen if the certificate doesn't include intermediate certificates, or if it has the wrong intermediate certificate.

a fentiből én azt gondolnám, hogy a problémát (oldaladon tapasztalt "certificate check failed") az okozza, hogy a mail.t-online.hu certje nem tartalmazza a felmenő intermediate certe(ke)t

 

ha importálod az odoroidodra a SectigoRSADomainValidationSecureServerCA.crt-t (illetve a felmenő láncból esetlegesen hiányzó tanusítványokat), a fenti "Verify return code: 21 (unable to verify the first certificate)" probléma megszűnik:

depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
verify return:1
depth=1 C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN=mail.t-online.hu
verify return:1

---
SSL handshake has read 3162 bytes and written 440 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 4096 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Frissítette a nyitó posztot:

Kisilabizáltam, hogy snq- a következő parancs kimenetéből idézett (ez nekem új volt):

openssl s_client -host mail.t-online.hu -port 465

és itt valóban benne van a certificate panasz. Ha jól értelmezem, a "chain of trust" sérült meg, mivel nem volt a gépemen root certificate (?), amivel a T-Online certjét verifikálni lehetett volna. 11.30-ig volt, valószínűleg 12.01-én lecseréltek a certet egy Sectigosra.

Debianon az /usr/share/ca-cerificates alatt van egy rakat cert, ide kellett betenni a mail.t-online.hu-hoz tartozó root certet, majd hívni egy update-ca-certificates -et.

Fedorán nem találtam előre telepített certeket, itt az /etc/pki-ca-trust/source/anchors könyvtárba kellett bemásolni a hiányzó certet, majd kiadni az update-ca-trust parancsot.

Ezek után a feljebb leírt openssl s_client ... parancs már nem panaszkodik, és az OpenSMTPd-m is szépen tud küldeni levelet ismét mindenhiova.

Köszönöm a segítséget!