1452154 - IMAP login fails, self-signed certificate:

Status: RESOLVED DUPLICATE of bug 1178497

(Thunderbird :: Security, defect)

Description

[[e-mail]]

Attachment: certificate_viewer.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20180322140748

Steps to reproduce:

Recently (roughly correlating with the 52.6 update) my user's TB instances started throwing errors on connecting to my server. If a user connects to the mail server with TB, or changes selected folder (instigating an IMAP reconnect).  

Tested with 52.6, 52.7, 58beta (linux) - 60beta (windows) throws a slightly different error but still doesn't connect.  

Server: 
FreeBSD 10.3 release p28
Dovecot 2.3.1
libressl 2.6.4
postfix 3.3.0,1

(Note that K9, Claws, Older TB installs, and Roundcube all connect file)

An initial attempt at resolution is archived at https://support.mozilla.org/en-US/questions/1211806#answer-1097512


Actual results:

Thunderbird throws an "Add Security Exception" window.  It seems a bit broken - 
 - Selecting Get Certificate simply grays out all other options other than Cancel.
 - "View" shows the correct certificate information.
 - Confirm Security Exception does store the certificate in the Certificate Manager (verified with new installs and by deleting and rechecking), but the connection is not completed, and on next check, a request is issued again.

Thunderbird logs:
2018-04-06 15:12:29.327927 UTC - -278927616[7ff3e67be980]: ImapThreadMainLoop entering [this=e47c2000]
2018-04-06 15:12:29.327985 UTC - 847537984[7ff431374100]: e47c2000:.blackrosetech.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2018-04-06 15:12:29.328069 UTC - -278927616[7ff3e67be980]: e47c2000:.blackrosetech.com:NA:ProcessCurrentURL: entering
2018-04-06 15:12:29.328082 UTC - -278927616[7ff3e67be980]: e47c2000:.blackrosetech.com:NA:ProcessCurrentURL:imap://gessel@.blackrosetech.com:993/select%3E.INBOX:  = currentUrl
2018-04-06 15:12:30.027064 UTC - -278927616[7ff3e67be980]: ReadNextLine [stream=f5247d80 nb=0 needmore=1]
2018-04-06 15:12:30.027093 UTC - -278927616[7ff3e67be980]: e47c2000:.blackrosetech.com:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1ff3
2018-04-06 15:12:30.030411 UTC - -278927616[7ff3e67be980]: e47c2000:.blackrosetech.com:NA:TellThreadToDie: close socket connection
2018-04-06 15:12:30.030425 UTC - -278927616[7ff3e67be980]: e47c2000:.blackrosetech.com:NA:CreateNewLineFromSocket: (null)
2018-04-06 15:12:30.034177 UTC - -278927616[7ff3e67be980]: e47c2000:.blackrosetech.com:NA:ProcessCurrentURL: aborting queued urls
2018-04-06 15:12:30.045041 UTC - -278927616[7ff3e67be980]: ImapThreadMainLoop leaving [this=e47c2000]

dovecot-debug.log
TB (failed)
Apr 06 08:45:20 auth: Debug: auth client connected (pid=64928)
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client hello B
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello B
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key exchange A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client certificate A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write session ticket A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully
Apr 06 08:45:20 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully
Apr 06 08:45:20 imap-login: Debug: SSL alert: where=0x4004, ret=560: fatal unknown CA
Apr 06 08:45:20 imap-login: Debug: SSL error: SSL_read failed: error:1404C418:SSL routines:ST_OK:tlsv1 alert unknown ca: SSL alert number 48
Apr 06 08:45:20 imap-login: Debug: SSL alert: close notify 

Claws (succeed)
Apr 06 09:26:54 auth: Debug: auth client connected (pid=67423)
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client hello B
Apr 06 09:26:54 imap-login: Debug: SSL_get_servername() failed
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello B
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key exchange A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client certificate A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client key exchange A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write session ticket A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully
Apr 06 09:26:54 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully
Apr 06 09:26:56 auth: Debug: client in: AUTH	1	PLAIN	service=imap	secured=tls	session=WmtMhjBpsMq5IhEH	lip=10.3.69.135	rip=185.34.17.7	lport=993	rport=51888	ssl_cipher=ECDHE-RSA-AES256-GCM-SHA384	ssl_cipher_bits=256	ssl_pfs=ECDH	ssl_protocol=TLSv1.2	resp=<hidden>

(dovecot's logging TLS as "SSLv3" is a known issue)

and in dovecot-info.log

TB (fail)
Apr 06 08:46:53 imap-login: Info: Disconnected (no auth attempts in 2 secs): user=<>, rip=185.34.17.7, lip=10.3.69.135, TLS: SSL_read failed: error:1404C418:SSL routines:ST_OK:tlsv1 alert unknown ca: SSL alert number 48, session=<944V9y9paMi5IhEH>
Claws (works)
Apr 06 08:47:33 imap-login: Info: Login: user=<[e-mail]>, method=PLAIN, rip=185.34.17.7, lip=10.3.69.135, mpid=65037, TLS, session=<J1N4+S9pbsi5IhEH>

Note that the certificate hasn't changed in ~4 years and for multiple users, clients, etc.  Only recently has TB been throwing unknown CA errors.



Expected results:

Connect to the server, start downloading mail, as usual.

Comment 1

[Jorg K (CEST = GMT+2)]

TB uses the underlying Mozilla platform code to check validity of certificates. So it looks like the CA is not accepted any more.

Comment 2

[Matt]

Self signed certificate Jorg.  But I can find no bug where they have been uniformly blocked out.  But my Bugzilla Foo is always questionable.

Comment 3

[Jorg K (CEST = GMT+2)]

I've seen heaps of bugs like this one: Bug 1321977 comment #6. Or bug 1370022, bug 1370559 or bug 1373514.

Comment 4

[Alfred Peters [:infofrommozilla]]

(In reply to [e-mail] from comment #0)

> TB (fail)
> Apr 06 08:46:53 imap-login: Info: Disconnected (no auth attempts in 2 secs):
> user=<>, rip=185.34.17.7, lip=10.3.69.135, TLS: SSL_read failed:
> error:1404C418:SSL routines:ST_OK:tlsv1 alert unknown ca: SSL alert number
> 48, session=<944V9y9paMi5IhEH>

With OpenSSL I also get an error message:

| C:\>openssl s_client -connect shiofuki.blackrosetech.com:993
| CONNECTED(00000278)
| depth=0 C = US, ST = California, L = Oakland, O = BRT, CN = shiofuki.blackrosetech.com, emailAddress = [e-mail]
| verify error:num=20:unable to get local issuer certificate
| verify return:1
| depth=0 C = US, ST = California, L = Oakland, O = BRT, CN = shiofuki.blackrosetech.com, emailAddress = [e-mail]
| verify error:num=21:unable to verify the first certificate
| verify return:1

The certificate could not be verified because the issuer certificate was not found.

| Certificate chain
|  0 s:/C=US/ST=California/L=Oakland/O=BRT/CN=shiofuki.blackrosetech.com/emailAddress=[e-mail]
|    i:/C=US/ST=California/O=BRT/CN=shiofuki.blackrosetech.com/emailAddress=[e-mail]

Are you sure this is a self-signed certificate?
I am not a SSL expert, but I think then the subject and issuer of the certificate must match. That is not the case here.

> Note that the certificate hasn't changed in ~4 years and for multiple users,
> clients, etc.  Only recently has TB been throwing unknown CA errors.

Then the certificate was used to encrypt but never checked for validity.
Now we seem to do that.

Comment 5

[[e-mail]]

It is a self-signed cert.

Some info may help debug:

openssl s_client -showcerts -host mail.blackrosetech.com -port 993 </dev/null
CONNECTED(00000003)
depth=0 C = US, ST = California, L = Oakland, O = BRT, CN = shiofuki.blackrosetech.com, emailAddress = [e-mail]
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = California, L = Oakland, O = BRT, CN = shiofuki.blackrosetech.com, emailAddress = [e-mail]
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Oakland/O=BRT/CN=shiofuki.blackrosetech.com/emailAddress=[e-mail]
   i:/C=US/ST=California/O=BRT/CN=shiofuki.blackrosetech.com/emailAddress=[e-mail]
-----BEGIN CERTIFICATE-----
MIIGDTCCA/WgAwIBAgIJAKt9qno4KXjzMA0GCSqGSIb3DQEBDQUAMH4xCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQwwCgYDVQQKEwNCUlQxIzAhBgNV
BAMTGnNoaW9mdWtpLmJsYWNrcm9zZXRlY2guY29tMScwJQYJKoZIhvcNAQkBFhhn
ZXNzZWxAYmxhY2tyb3NldGVjaC5jb20wHhcNMTQwNDIyMTc1NDIzWhcNMzQwMTA3
MTc1NDIzWjCBkDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEDAO
BgNVBAcTB09ha2xhbmQxDDAKBgNVBAoTA0JSVDEjMCEGA1UEAxMac2hpb2Z1a2ku
YmxhY2tyb3NldGVjaC5jb20xJzAlBgkqhkiG9w0BCQEWGGdlc3NlbEBibGFja3Jv
c2V0ZWNoLmNvbTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALmldwmp
+gTozCNXf13Zd0dwZmSEGMFNJiU80DODWasb5Ap+YNcKXH7Bc313VcdLd3lrxWv5
Ufgz6cXDxl05yg7YrF3os13z0hO3T56/yaRl2s6UZbStWpbbKZs2oEmdQg7BSo+1
AQyMiD24aGvEcvgFXVQ89K+vd51puvmMRuFHKgJwSGm8nj+/KyLnhLsDGpQOBh98
1LJpKZ0zNI0WORqrm6DnMk+yZSJDrmjQgHthxJKt5aM+DVU3AWISbJ0tFh0Sb8s5
h69b5p7ppf6gHcLH3xKj+gy3wKSYvUjMpP+/YKXzzJRae1dptT1DZcbnx/iQnJsA
+8AC8EYcXuOVQ1H1gN7vrmcGo9OUL7/479C+kTbsdvraxF1Vb3YSzZCkGZB8jL+T
tcsFGEZALpHvX1ilvhE2Nvo2UHvGoe87jnKAuqC3/Bi1+MKJFs6b+WFQLdFCipS+
YH2pgTUa9yE74fTVxuBuZJe66l3KSb9oo4u+wZWtWIXdiLUWJmvhVeTvk2MtBiJL
f7EO7qpkmyZ32KAiNiIAsrEseZYIRyupaQgnHKPSrWZIvuv/QARrxjkdc/EpD5jb
YdDVpLewUpkeRhl+SE5pqMxjWWqYqZ0JOE5frHbXT3+Xa0AitO2RIYrrfSXrt7KN
78W96W1zXOvoxj/n8VKoIRWdgxjn8loCHVanAgMBAAGjezB5MAkGA1UdEwQCMAAw
LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G
A1UdDgQWBBQjsnF3OSJo3K9x3TFzF4YC4rOdJzAfBgNVHSMEGDAWgBSZaeaP7f7S
NBs/JnGAUWMwax8pwTANBgkqhkiG9w0BAQ0FAAOCAgEAqTc+/577K/mMernvED+e
2GZjcpiDXVUb0E49JFh1YIb/YZXcow8KJcz2tYTk3wSy0GdkwAXu0hF9cAwRM08k
HIURTPC6676KG3ENkixFutH2c0RXXlYUbaHyiri0hBUk/KGKZgwJd/9kKKdd+M6/
xJy5c5quTX4qhW/aelNisERDfCRaU/LdL5z5fMsxnJ2S/U9MS8U0VQV7UMUNzmTT
mZTfJGs8VxX4DQDwwp02bUpCAtbXuDXXundZKEIAjzkoKrJB7vLfrZvOjZ4W0rXH
ulvthviaCj8h3MJwlGbm6NPmrz89Qd5ZC079VJQxKTlm+L/W5EKTZlFIu/zeDRYq
8lDNV94VB8rVYSptEMgYScsbftoUJCSiI8kbVw44ggwcklcb1fOiwrcB/pIOJAi1
0EB9A4uH+qlqznkRmVD/E4ODsJHIO/XD+bCa5T77IT5tJa2rz2wN7Wfab/nEJ+sB
uIwZb9HO/MSfj7Dc0bizpS+JPVNrGLLcTOBqaN256VikkFS/lnzFYbf4HdVaxgOF
1mrxPpD/6MElio+DOCfumF4qkopXlR2UXLdDidYdurZQmzng3gRyMsrtke/KrA2q
ehcdXdswbjtXf89ph2nVtQQF+oNq4gwuvMfEDDChdlNcQ3s2ONR0TO7/XEqK5kXX
kD88sd76EZc0/lvRrZC9Ujs=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Oakland/O=BRT/CN=shiofuki.blackrosetech.com/emailAddress=[e-mail]
issuer=/C=US/ST=California/O=BRT/CN=shiofuki.blackrosetech.com/emailAddress=[e-mail]
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2461 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 5CF2BD5CE58F396445213B6EAD54662D85AE560D1DA63DBD5395B12DF41467EB
    Session-ID-ctx: 
    Master-Key: 35E30D9C778DF1706B05DDFC427F828355B6B26A184D5F012FE94E20728747E31ED48BCC6BACF95822E724C6C8DD343E
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 0e 1d 9f 60 93 7a 43 b7-f2 3c a3 d5 19 5e a5 61   ...`.zC..<...^.a
    0010 - 75 6a 98 e6 eb 6d 97 38-97 e5 0c 38 0a 67 ee 0e   uj...m.8...8.g..
    0020 - f7 2d 15 4f bc d7 fe 41-36 21 ed 68 5d df f6 27   .-.O...A6!.h]..'
    0030 - fe 2a 27 95 28 ff b8 94-f2 92 d8 1e d0 a4 cf de   .*'.(...........
    0040 - 22 9b 5e 59 d3 21 55 00-8a ac db 80 24 04 33 2d   ".^Y.!U.....$.3-
    0050 - 26 db 47 c3 9c ac 18 fc-c7 18 62 70 09 46 6c 0c   &.G.......bp.Fl.
    0060 - db 98 32 42 f4 22 d6 bd-9f b6 65 73 27 49 bc 33   ..2B."....es'I.3
    0070 - 6b 42 71 75 a5 57 27 5d-74 d1 c7 a0 04 29 d7 f7   kBqu.W']t....)..
    0080 - e7 f7 41 9c 95 8d 0d 37-e9 cf 90 fa 72 9f 06 c4   ..A....7....r...
    0090 - aa e6 a7 e0 45 5e 45 2b-08 02 5f 84 f1 a8 c7 33   ....E^E+.._....3

    Start Time: 1523099812
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

Perhaps this issue is better directed to the appropriate underlying code forum?  

It does seem as if there's a client side problem because:

- "Confirm security exception" actually loads the certificate into the Certificate Manager, but does not permit the certificate to be used.  I expect a warning along the lines of "The certificate is not trusted because it hasn't been verified as issued by a trusted authority using a secure signature."  - that's true and valid, but I expect to be able to "confirm security exception" and "permanently store this exception" and go on to get my mail as always.

- the "Get Certificate" button says only "Unable to obtain identification status for this site" and permits only "Cancel" (I'm pretty sure that used to work, but definitely not positive; this may be normal behavior).

Comment 6

[[e-mail]]

Attachment: screenshot of certificate manager showing certificates loaded

Comment 7

[[e-mail]]

Clients that work with this cert:
K9
Claws
Evolution
Roundcube

Clients that used to work with this cert:
Thunderbird

Comment 8

[[e-mail]]

Perhaps NSS issue?

Comment 9

[[e-mail]]

well... lovely that the user product now requires the certificate product.  I switched the server to LetsEncrypt with a little bit of cludgy scripts to get around not having or wanting a web server externally accessible on the mail server.

Now Thunderbird is happy to implicitly trust the certificates because they're signed by strangers on the internet who are an Approved Authority.    

Note that the ONLY dovecot change was to point to the LE certs.  That is it is not a server configuration error, an SSL error, a TLS error, a client configuration error.  All other mail clients tested were perfectly happy with my self-signed certs, as TB has been for the last 3-4 years.  Now they're all contentedly accepting the Central Authority.  Because what could go wrong trusting strangers on the internet?

My issue is resolved, but the underlying error recently introduced remains.

Comment 10

[[e-mail]]

One last detail: one user kept TB connected and checking mail by not restarting it for the last 3 weeks (the failures started about 3 weeks ago).  Some code update broke TB badly.  It seems to work OK with LE certs (funny that...) but not with self-signed, at least not mine.  

An annoying but not fatal bug.

Comment 12

[bm]

Same here with Thunderbird 52.8.0 (Build ID: 20180522092033) on Linux/Ubuntu 18.04

Comment 13

[Wayne Mery (:wsmwk)]

Do you see this when using version 60?

Comment 14

[[e-mail]]

Sadly, I can't really help debug any more, I set everything up with LetsEncrypt. This bug was incentive to do that.

There's a good argument as to why self-signed certs can be more secure than LE or commercial certs for things like email servers, but with LetsEncrypt it is a less essential argument.

Comment 15

[Wayne Mery (:wsmwk)]

Might this be a duplicate?
(reporter is gone)

Comment 16

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #15)

Might this be a duplicate?
(reporter is gone)

Yes. Looks like a direct duplicate of bug 1178497 and some more might be hiding here: https://mzl.la/34fEEa3