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!
Hozzászólások
Elég beszédes a log pedig
És mit mond neked? Én nem vagyok jártas az ilyesmiben, segíts kérlek.
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)
Új certificate-et kéne generálnom, nem TLSv1.3-at, hanem újabbat?
Off: a cert is el tud avulni erkölcsileg a kriptoalgoritmusok kora miatt (pl. a MD5, SHA1 hash, rövid RSA kulcs), de a TLS-verzióhoz nincs köze; egyébként az 1.3 a legújabb TLS protokollverzió, 2018-as.
Az opensmtpd-nek adott certificate még érvényes. Az esetleg a baj, hogy self-signed? Eddig nem volt gond. Illetve mit értenek intermediate certificate-en? Egyáltalán nem értem, minek kéne nekem még köztes certekkel vacakolni...
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:
És igen, kösz, meglett a megoldás.
>> Kisilabizáltam, hogy snq- a következő parancs kimenetéből idézett (ez nekem új volt):
elnézést, akkor legyen itt a teljes:
openssl s_client -showcerts -starttls smtp -connect mail.t-online.hu:25 -servername mail.t-online.hu
Az annyira közösségépítő amikor nem írják le mi a megoldás! Legalább annyit hozzátehettél volna, hogy: Igen, ez a megoldás.
Még nincs aláírásom.
Frissítette a nyitó posztot:
Vegyük úgy, hogy egy szót sem írtam.
Még nincs aláírásom.
Kérlek: "Valóban, az én Orodroin kliensem nem bízott a szerver [RootCA-jának] cert-jében."