Mozilla Thunderbird 78.4.0 - Tanúsítványkezelés hiba

Microsoft Windows

Sziasztok!

A mai napon több Windows 10 kliensen frissült a Mozilla Thunderbird 68.12 verziója a 78.4.0 verzióra.

A frissítés rendben lezajlott, minden gépen egy általam üzemeltetett mail szerveren lévő postafiókok vannak beállítva.

A mail szerver let's encrypt által kreált tanúsítvánnyal dolgozik , amit majd 2 hónap múlva kell újra érvényesítenem.

A 78.4.0 Thunderbird valamiért nem hajlandó együtt dolgozni sem ezzel a tanúsítvánnyal, sem pedig másik , a mail szerver által generált tanúsítvánnyal, csak akkor, ha az imap fiókokat eltávolítom a thunderbirddel együtt a kliensről , majd a thunderbirdot újratelepítem és újra felveszem a fiókokat.

A hibaüzenet a következő, amely küldéskor jelentkezik:

A tanúsítvány kulcs használata nem megfelelő a megkísérelt művelethez.

A kiszolgálóhoz kapcsolódó tanúsítvány beállításait javítani kell.

Ha kikapcsolom a titkosított üzenetküldést a kliensben, akkor is ugyanez a hibaüzenet, illetve ha generálok egy OpenGP kulcsot akkor is jelentkezik a hiba.

Alapvetően nem szeretnénk használni végpontok közötti titkosítást, mert csak bonyolítja a dolgokat, bőven elég, a STARTTLS alapú kommunikáció, de a Thunderbird mégis csak akkor javul meg, ha újratelepítem mindegyik kliensen és újra felveszem a fiókokat kliensenként.

 

Google mail, illetve iCloud fiókokkal rendben működik.

Az lenne a gond, hogy ingyenes tanúsítványt használunk, vagy esetlegesen csak egy "bug", amit remélhetőleg javítani fognak?

Valaki esetleg futott bele hasonló problémába, lehet orvosolni a problémát anélkül, hogy a fiókokat és a thunderbirdot újrahúznám a klienseken?

 

A választ és a segítséget előre is köszönöm!

  • 1820 megtekintés

( dcsaba v | 2020. 10. 30., p – 15:51 )

Saját domain postafiók levelek letöltése -> fel fog dobni egy ablakot, ott kiválasztani a kivétel megerősítése.

Nagyjából így oldottam meg, hasonlóan  let's encrypt  et használunk.

Ezt próbáltam legelőször, mert ez van akkor is, amikor tanúsítványt újítok, de sajnos nem jött be.

Imap login valamelyik gépen működött, valahol nem, de smtp akkor sem működött, amikor a gmailes smtp fiókot tettem alapértelmezettre.

Remélem mostantól nem kell majd minden egyes frissítésnél újra húznom a thunderbirdet, illetve a fiókokat, mert akkor nagy eséllyel új mail kliens után kell néznem :(

A tanusítvány neve : mail.zentyal-domain.lan, a kiszolgáló pedig mail.cegnev.hu.

Ezt viszont nem tudom átiírni, mert beírja az LDAP configba, és ha átírom, akkor sérül a vmail tartomány.

Érdekes állatfaj ez a zentyal, de sajnos ezzel kell együttélnem, mert az előző informatikus ezt hagyta rám, és ha módosítok, akkor a leveleket nem tudom átvinni működőképesen másik szolgáltatás alá.

Igaz, azt sem tudom, hogy fogom átvinni, ha bérelt szerverre akarom majd átköltöztetni, mivel oda már valószínűleg nem ilyen instabil rendszer, hanem egy Debian kerülne telepítésre, nem vmail fiókokkal.

Én a következőt csinálnám. A gép mail.cegnev.hu nevére vagy egy NetLock DV certet vetetnék/vennék, és azt pakolnám fel a selfsigned helyett (ezt egyszer bekalapálod a zentyal-ba, aztán amíg le nem jár, jó lesz, az előtt meg kell venni újat, és azt berakni, és így tovább), vagy megpróbálnám összereszelni a motyót Let's Encrypt-es certtel úgy, hoyg menjen az automatikus megújítás.

es a zentyal alatt levo IMAP/SMTP szerver tanusitvanyat nem tudod felulcsapni a let's encryptes tanusitvannyal?

en debian alatt ugy oldottam meg hogy a tanusitvanyt rsync-el atmasolom a levelezo szerverre, modositom a tulajdonost es a jogokat majd reloadolom az IMAP es SMTP szervert is

neked aztan fura humorod van...

( mauzi v | 2020. 10. 30., p – 17:13 )

Ezt a problémát én nem tudom reprodukálni Windows 10 Enterprise 2004 / Thunderbird 78.4.0 x64 környezetben.
Ha jól értem, a probléma nálad IMAP-nál nem, csak SMTP-nél jelentkezik? Nálam SMTP oldalon egyébként Postfix 3.4.14 (Debian) van, a teszt kedvéért Let's Encrypt tanúsítvánnyal.

Nálam egy Zentyal szerveren fut a mail szolgáltatás, ráadásul ősrégi 3.4.8-as verzió.

Igen, tudom frissíteni kellene, próbáltam is virtuális környezetben először teszt jelleggel, de 4. nekifutásra futott le a frissítés, és valamiért nem volt hajlandó beolvasni a virtual mail fiókokat sajnos, amit meg beolvasott az sérült volt.

Szóval így marad most ez a verzió, amíg a vezetőség úgy nem dönt, hogy elvisszük az egész mail szolgáltatást egy szerverteremben bérelt szerverre, normális publikus ip-vel, szervezett környezetbe.

( elod v | 2020. 10. 30., p – 20:31 )

Szerkesztve: 2020. 10. 30., p – 20:32

Nálam ez jött szembe: https://support.mozilla.org/en-US/questions/1306588

Meg egy idétlen hiba amivel nem lehet a self-signed cert-eket (igen, ok, ne mondjátok...) trusted-re állítani. Ki tudja még hány bugot palántáltak el a megújított részre. Ezt is sikeresen elbaltázzák...

( csp | 2020. 11. 01., v – 12:52 )

A hibaüzenet a SEC_ERROR_INADEQUATE_KEY_USAGE NSS hibakódnak a szöveges megfelelője. A TLS verzió hibát ki lehet zárni, mivel a hibaüzenet már a TLS ServerHello után történik. Gyanítom ez inkább egy trust chain ellenőrzés probléma lesz.

A tanusítvány neve : mail.zentyal-domain.lan, a kiszolgáló pedig mail.cegnev.hu.

Ezt érdemes volna konkretizálni azzal, hogy milyen kiszolgáló címhez/porthoz akar csatlakozni a TB, illetve mi van a tanúsítvány Subject és Subject Alternative Name mezőiben. Pl.:

$ openssl s_client -showcerts -connect mail.zentyal-domain.lan:465 </dev/null | openssl x509 -text -noout

vagy ha StartTLS submission porton, akkor:

$ openssl s_client -showcerts -connect mail.zentyal-domain.lan:587 -starttls smtp </dev/null | openssl x509 -text -noout

Feltételezve persze, hogy a TB a mail.zentyal-domain.lan címhez akar csatlakozni.

A 78.4.0 Thunderbird valamiért nem hajlandó együtt dolgozni sem ezzel a tanúsítvánnyal, sem pedig másik , a mail szerver által generált tanúsítvánnyal

Ez alapján a viselkedés nekem valami ilyesmit sejtet: https://bugzilla.mozilla.org/show_bug.cgi?id=1590217#c31

A ticket ugyan FF, de gyanítom ugyanez a TB hitelesítési logikája is.

( uid_395 v | 2020. 11. 02., h – 18:44 )

btw, nem biztos hogy releváns, de valami nagyon "hasonló" gondokat tapasztaltam egyik cégnél. Csak TB kliens van, a szerver egy "eccccerű" postfix/dovecot páros.

Letsencryptes certtel, megfeleltetve mindennek is. Túzfalból meg van oldva hogy a mail.fudejooo.hu az belülről belső IP-t adjon, kívülről külsőt, stb...

Viszont minden féle szerver oldali konfig varia nélkül a STARTTLS / SSL -es TB kliensek (local hálón) elkezdtek köhögni..
Itt ami észrevétel volt,  hogy TB kiírta hogy a szerver "lehetőségeinek" lekérdezése. Azt ennyi. Szerver oldalon logba semmi nem látszott.

Futottam is pár kört, hogy wtf, eddig ment most nem megy, mi lehet. Ha átállítottam 143-as -ra simán (starttls nélkül) + smtp-nek is megmondtam  hogy már pedig nem kell neked starttls, kliens szinten, akkor megjavult..

Csoda. De ez csak belülről. Az Android és egyéb kliensek ugyan úgy mentek tovább.

Még nem jöttem rá a teljes megoldásra, de amit változtattam a dovecot ssl confban az kb ennyi:

ssl_dh_parameters_length = 2048

ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

ssl_prefer_server_ciphers = yes

ssl_min_protocol = TLSv1.2

Eddig a min protocol nem volt benne, ez egy dovecot 2.3.10 + az extra chiper list se.

(A dh_param az régebbi cucc asszem)

Azóta egy frissen "sütött" usernél megfelelő mail.foodejooo.hu host-al megy STARTTLS is / SSL is. Mind imap mind smtp szinten.

Bár lehet ezt csak a friss telepítés okozta... ~Évek óta használjuk itt a letsencryptes tanusítványt erre az egy domainre belőve, ha az automatika nem cseszi el a frissítést, akkor a TB minden további nélkül elfogadja a certet validnak.

Egészen mostanáig.. most a certig se jut el.. logba se nagyon akar velem kommmunikálni hogy mér nem .. 

( mickeyratt | 2020. 11. 03., k – 15:30 )

Nálunk is gond van a saját generálású, csak intranetes levelezésre használt cert-el. Számos esetben nem jön fel a "Biztonsági kivétel hozzáadása" ablak, így nem is lehet megerősíteni a kivételt. Ezekben az esetekben törlöm a user profil könyvtárból a:
-cert_override.txt
-cert8.db
-cert9.db

fájlokat, és ezek után rendben feljön az ablak, el is lehet fogadtatni a kivételt és látszólag rendben működik.
Nálunk Let's encrypt-es tanúsítványokkal nem produkálja a hibát szerencsére.