Today all of a sudden my Icedove mail clients (38.7.0) ceased working using STARTTLS after I renewed the server certificate. Plain text IMAP works fine.

The server logs STARTTLS negotiation failed for each TLS connection attempt. Analyzing the connection with wireshark shows that the client sends a fatal Bad Certificate alert as response to Server Hello.

However, openssl s_client -starttls imap -crlf -connect 'imap.example.com:143'-CAfile /etc/certs/cacert.pem works just fine. The CA is imported into the certificate store of icedove, otherwise icedove closes with Certificate Unknown.

I'm currently looking for means to find out what exactly iceweasel is complaining about.

Update: I had the idea to import the certificate as server certificate immediately. Importing worked without complaints and it is registered in icedove's store. But the error persists.

More Info: I found that thunderbird can generate debugging information. So I tried: NSPR_LOG_MODULES=all:5 NSPR_LOG_FILE=/tmp/icedove-imap.log icedove. The following data is grepped for the thread performing the TLS negotiation and trimmed around the actual negotiation:

2001729280[7f047ae284c0]: ReadNextLine [stream=777e4b00 nb=16 needmore=0]
2001729280[7f047ae284c0]: 784a2000:imap.example.com:NA:CreateNewLineFromSocket: 1 OK Completed
2001729280[7f047ae284c0]: 784a2000:imap.example.com:NA:SendData: 2 STARTTLS
2001729280[7f047ae284c0]: OOO WriteSegments [this=79470ee0 count=12]
2001729280[7f047ae284c0]: OOO rolling back write cursor 14 bytes
2001729280[7f047ae284c0]: OOO advancing write cursor by 12
2001729280[7f047ae284c0]: STS dispatch [7f04777e4f10]
2001729280[7f047ae284c0]: THRD(7f048d802740) Dispatch [7f04777e4f10 0]
2001729280[7f047ae284c0]: EVENTQ(7f048d8027a8): notify
2001729280[7f047ae284c0]: III ReadSegments [this=777e4b00 count=4096]
2001729280[7f047ae284c0]: III pipe input: waiting for data
2001729280[7f047ae284c0]: III pipe input: woke up [status=0 available=32]
2001729280[7f047ae284c0]: III advancing read cursor by 32
2001729280[7f047ae284c0]: ReadNextLine [stream=777e4b00 nb=32 needmore=0]
2001729280[7f047ae284c0]: 784a2000:imap.example.com:NA:CreateNewLineFromSocket: 2 OK Begin TLS negotiation now
2001729280[7f047ae284c0]: 784a2000:imap.example.com:NA:SendData: 3 capability
2001729280[7f047ae284c0]: OOO WriteSegments [this=79470ee0 count=14]
2001729280[7f047ae284c0]: OOO rolling back write cursor 12 bytes
2001729280[7f047ae284c0]: OOO advancing write cursor by 14
2001729280[7f047ae284c0]: STS dispatch [7f04777e4f10]
2001729280[7f047ae284c0]: THRD(7f048d802740) Dispatch [7f04777e4f10 0]
2001729280[7f047ae284c0]: EVENTQ(7f048d8027a8): notify
2001729280[7f047ae284c0]: III ReadSegments [this=777e4b00 count=4096]
2001729280[7f047ae284c0]: III pipe input: waiting for data
2001729280[7f047ae284c0]: III pipe input: woke up [status=805a1f76 available=0]
2001729280[7f047ae284c0]: ReadNextLine [stream=777e4b00 nb=0 needmore=1]
2001729280[7f047ae284c0]: 784a2000:imap.example.com:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1f76
2001729280[7f047ae284c0]: THRD(7f04a30fe690) Dispatch [7f047489c150 0]
2001729280[7f047ae284c0]: EVENTQ(7f04a30fe6f8): notify
2001729280[7f047ae284c0]: THRD(7f04a30fe690) Dispatch [7f0472bf71a0 0]
2001729280[7f047ae284c0]: EVENTQ(7f04a30fe6f8): notify
2001729280[7f047ae284c0]: 784a2000:imap.example.com:NA:TellThreadToDie: close socket connection
2001729280[7f047ae284c0]: 784a2000:imap.example.com:NA:CreateNewLineFromSocket: (null)
2001729280[7f047ae284c0]: destroying nsSocketTransport @7f047a5d4300

Again, it is not exactly informative to me.

openssl log:

openssl s_client -connect imap.mgr:993 -CAfile /etc/certs/cacert.pem 
depth=1 C = DE, ST = NRW, L = Niederkassel, O = \C2\B5AC - Microsystem Accessory Consult, OU = IT, CN = CA
verify return:1
depth=0 C = DE, ST = NRW, L = Niederkassel, O = \C2\B5AC - Microsystem Accessory Consult, OU = IT, CN = imap.uac.microsult.de
verify return:1
Certificate chain
 0 s:/C=DE/ST=NRW/L=Niederkassel/O=\xC2\xB5AC - Microsystem Accessory Consult/OU=IT/CN=imap.uac.microsult.de
   i:/C=DE/ST=NRW/L=Niederkassel/O=\xC2\xB5AC - Microsystem Accessory Consult/OU=IT/CN=CA
 1 s:/C=DE/ST=NRW/L=Niederkassel/O=\xC2\xB5AC - Microsystem Accessory Consult/OU=IT/CN=CA
   i:/C=DE/ST=NRW/L=Niederkassel/O=\xC2\xB5AC - Microsystem Accessory Consult/OU=IT/CN=CA
Server certificate
subject=/C=DE/ST=NRW/L=Niederkassel/O=\xC2\xB5AC - Microsystem Accessory Consult/OU=IT/CN=imap.uac.microsult.de
issuer=/C=DE/ST=NRW/L=Niederkassel/O=\xC2\xB5AC - Microsystem Accessory Consult/OU=IT/CN=CA
No client certificate CA names sent
SSL handshake has read 2967 bytes and written 615 bytes
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 730888566D757F19B38BF3CCD7A55CF44CBCD08B6763262CD36A2AA4230260DC
    Master-Key: 4DA397FA9EFF6EA3F2610291BFC3BDAA69DAA00F3B6787F06635F739A0D99EECCEFF715A3E22D66165E8CAADC968EEFD
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 9d e1 fe 6a cf df 22 86-e8 2e c4 8b 4c 90 49 76   ...j..".....L.Iv
    0010 - e9 49 76 c9 4f 37 12 a3-4f b8 b5 44 18 e1 2b 64   .Iv.O7..O..D..+d
    0020 - af 01 7a 21 c7 b2 f2 84-17 fb a7 4d aa c3 73 dc   ..z!.......M..s.
    0030 - 91 b2 c5 ef d9 d8 2e 0a-bd f8 57 20 da ba bb 02   ..........W ....
    0040 - 1b a8 b1 21 0c f5 39 63-39 8c 90 51 48 3c 82 f2   ...!..9c9..QH<..
    0050 - a5 33 21 2e 23 f8 99 9c-0e 6f d0 67 99 8c 52 7b   .3!.#....o.g..R{
    0060 - 23 7a 13 45 5a 68 63 51-e3 e0 b6 ce fb 19 fa b4   #z.EZhcQ........
    0070 - 4b 6b 74 76 7d 5c 3d 55-83 a9 be 5a 11 46 65 14   Kktv}\=U...Z.Fe.
    0080 - dc de 9b ae ce 45 5e d8-eb 46 83 b2 a5 7b f0 ae   .....E^..F...{..
    0090 - f3 fe 2f a5 e4 8c 71 fa-6f 3f 10 61 7e f0 45 c5   ../...q.o?.a~.E.

    Start Time: 1459405125
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
* OK hermod Cyrus IMAP4 v2.2.13-Debian-2.2.13-14+lenny3 server ready
* BYE LOGOUT received
a1 OK Completed

For STARTTLS on 143 the log is not different.

  • can you try the following and paste the output openssl s_client -connect yourserver.com:993 – Izac Mar 30 '16 at 17:11
  • was there any change in the infrastructure? I had a similar problem where a cisco asa filtered out the starttls command – Izac Mar 31 '16 at 10:52
  • @Izac: no change, and openssl connects flawlessly, so there shouldn't be any problems in the transport layer. – Lars Hanke Apr 1 '16 at 18:01
  • Can you try a different mail client, maybe there is a Problem with some static linked ssl libraries that can't handle e.g SHA2. If that works we can narrow down the problem to your MUA – Izac Apr 3 '16 at 7:28
  • Using openssl s_client on port 143 I have a simple MUA. So it's obviously the MUA. The question is, whether it is probably less permissive for some good reason. – Lars Hanke Apr 5 '16 at 6:23

Check the domain in the client's configuration.

  • It needs to match the domain on the certificate.
  • Check DNS resolution of the domain on the client.

There are a number of recent changes to both server and client software designed to resolve issues with SSL/TLS vulnerabilities. It is possible one of these is causing an issue. If your certificate has only a SHA-1 signature this may cause it to be rejected.

  • Signature is sha256withRSA. The server name matches CN. Well, the DN of both CA and server has a proper UTF8STRING, but AFAIK this should be compliant. – Lars Hanke Mar 29 '16 at 6:24
  • @Lars Hanke Thuderbird works will with my Dovecot/Exim4 servers. I have reduced the available protocols, and have SMTP issues with some servers connecting from the Internet. I've setup a blacklist to prevent advertising TLS to the problem domains. You could try checking for protocol incompatibilities. – BillThor Mar 31 '16 at 3:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.