tlsv1 alert unknown ca in SSL_accept imaps TLS negotiation failed
Categories
(Thunderbird :: Security, defect)
Tracking
(Not tracked)
People
(Reporter: mozilla, Unassigned)
Details
(Keywords: regression)
|
||
Comment 1•10 years ago
|
||
|
|
||
Comment 3•10 years ago
|
||
|
||
Updated•2 years ago
|
|
||
Comment 5•8 months ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #1)
Does setting security.use_mozillapkix_verification to false make it work?
The setting does not even exist in modern Thunderbird (I'm struggling with 115.9.0), but the problem is here (again?)...
Our private little IMAP-server has its own CA and uses its own certificate. This worked for some years until the server certificate had to be replaced. After the replacement other clients -- iPhones -- continue working fine with the same server, but TB is quietly failing. There are no error messages presented through any GUI on the client-side, but on the server side I see:
imaps TLS negotiation failed: client.example.com [ip.add.res.s]
As the original reporter 10 years ago, I tried importing the private CA's certificate into Thunderbird, but that didn't help. We also tried deleting the account on the client -- and creating it again. Same results:
- no obvious errors, but no e-mails either on the client.
imaps TLS negotiation failedlogged by Cyrus IMAP on the server.
Just for kicks, I tried adding the security.use_mozillapkix_verification to Thunderbird, and it didn't help.
We tried deleting the server's entry from "Certificate Manager" -> Servers, and the entry did not reappear. Testing the server with OpenSSL's s_client works fine:
% openssl s_client -crlf -connect server.example.com:993
CONNECTED(00000003)
depth=1 C = US, ST = Some-State, O = United Marsupials, OU = Wombats, CN = Narawntapu
verify return:1
depth=0 C = US, O = United Marsupials, CN = ..., emailAddress = "mi+cert@...."
verify return:1
---
Certificate chain
0 s:C = US, O = United Marsupials, CN = ..., emailAddress = "mi+cert@..."
i:C = US, ST = Some-State, O = United Marsupials, OU = Wombats, CN = Narawntapu
1 s:C = US, ST = Some-State, O = United Marsupials, OU = Wombats, CN = Narawntapu
i:C = US, ST = Some-State, O = United Marsupials, OU = Wombats, CN = Narawntapu
---
...
read R BLOCK
* OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE] imap.example.net Cyrus IMAP 2.5.17 server ready
Again, the same TB-installation had no problem for a long time -- until the certificate had to be regenerated...
You may suspect, that I messed up the regeneration somehow, but:
a) the iOS devices continue to access the same server without a problem;
b) Thunderbird presents no errors to the user -- which would be a bug, even if something truly was wrong with the service-side.
TB is 115.9.0, linked with nss-3.99 and nspr-4.35 -- using FreeBSD port.
|
|
||
Comment 6•8 months ago
|
||
Tried connecting to the same server from another computer, using the slightly older TB 115.6.0:
- Initially was facing the same symptoms:
a) quiet failure on the client (a bug in its own right);
b)imaps TLS negotiation failedmessage logged on the server. - After importing the private CA's certificate into Thunderbird, all problems went away and the client connected properly.
Seems like a recent regression :(
|
|
||
Comment 7•8 months ago
|
||
Seems like a recent regression :(
Ok, I was able to overcome this by:
- Opening the
cert9.dbunder the Thunderbird's profile:
sqlite3 ~/.thunderbird/...../cert9.db
- Finding the CA's certificate in the database's sole table and deleting it:
select id from nssPublic where a101 like '%MyCA%';
delete from nssPublic where a101 like '%MyCA%';
For this to work, your SQLite3 has to be compiled with the option allowing the application of like to blobs -- -USQLITE_LIKE_DOESNT_MATCH_BLOBS -- because the a101-column, which is supposed to hold the certificates' subjects (great naming, Mozilla!), is a blob. You may be able to do this deletion through the GUI, $username, but I could not.
- Re-importing the CA's certificate again through the Certificate Manager.
After this, Thunderbird finally connected -- and prompted me for password.
So, the bugs are two:
- The error, whatever it is, is not communicated to the user -- if I didn't have access to the logs of the server, I'd have never known, what's wrong.
- The adding of a new CA -- for those, who guessed, that that's, what the problem is, may leave things in such a state, where the cert has to be removed and then re-added.
|
||
Comment 8•4 months ago
|
||
Here dovecot IMAP server on LAN with certificate from self-signed CA. Working fine for all but one user since they did update from 115 to 12X two days ago. Thunderbird does not trust the certificate. The self-signed CA has been re-imported into the users certificate store and given rights to. That did not help.
On the server following error log:
imap-login: Disconnected: Connection closed: SSL_accept() failed: error:14094418:SSL routines:ssl3_read_bytes:
tlsv1 alert unknown ca: SSL alert number 48 (no auth attempts in 0 secs): user=<>, rip=n.n.n.n, lip=n.n.n.n, TLS handshaking: S
SL_accept() failed: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: SSL alert number 48, …
This for a STARTTLS IMAP connection on port 143. I read somewhere that error 48 means client certificate. This server does not prompt to authenticate with client certificate. On wireshark I see that negotiation is called for, then gibberish. Then TCP connection finalized. openssl s_client has no problems negotiating on port 993.
|
|
||
Comment 9•4 months ago
|
||
The problem also affects outbound mail:
postfix/smtpd[…]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../ssl/record/rec_layer_s3.c:1528:SSL alert number 48:
postfix/smtpd[…]: lost connection after STARTTLS from …
Makes me wonder if this is really the same as Mikhail reports? Thunderbird is certain, that the server certificate is not trusted. And that cannot be overridden from preferences. Why does it even start negotiation then?
|
|
||
Comment 10•4 months ago
|
||
Sorry for the noise - on other computers (win10, linux) update from 115 to 128 went flawless. No certificate errors. Only a single workstation is affected. Worked around on this one by creating an exception that now is recorded in cert_override.txt there. When prompted with the warning "invalid certificate" do not try to fetch, this will fail, but just create exception. Further investigations due…
|
||
Comment 11•3 months ago
|
||
Thunderbird had a bug that caused certificate errors to not bring up error messages.
There was recent work in bug 1893899 and bug 1903135 to fix that.
With the current stable version 128.x you should get a notification, and clicking the notification should allow you to add an override.
Please add another comment if you cannot add overrides with 128.x
Description
•