Re: [SOLVED] Re: STARTTLS negotiation failed
On 13 Jan 2003, Steve Huston writes: > Finally got it! I followed the exact instructions in the manual for > creating a key, and for some reason that worked. Then I realized > one other thing I changed in the /etc/imapd.conf file when I used > that other key, that being "tls_ca_file:" It seems that the program > doesn't like the CA file that comes with RedHat 8.0, and if I > specify that file it chokes and dies *only* on TLS connections, SSL > works fine. This makes perfect sense. Red Hat creates an initial host cert (not CA, I think) that uses "localhost.localdomain" as the host name (CN attribute). That 'works' for HTTPS web browsing, but generally fails for IMAPS and POP3S use. You just need the correct real hostname in your certificate. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
[SOLVED] Re: STARTTLS negotiation failed
On Fri, 10 Jan 2003, Jonathan Marsden wrote: > On 10 Jan 2003, Steve Huston writes: > > Now, our current Cyrus server has a self-signed cert which Pine > > doesn't like unless you add /novalidate-cert to the hostname of the > > server. But this time, that doesn't even help as it just says > > "There was an SSL/TLS failure for the server" "The reason for the > > failure was: SSL Negotiation failed" Cyrus also reports the same > > thing in the logs. I understand the point of '/novalidate-cert', > > meaning don't try to check the signing authority on the cert, and I > > could overlook things if that was the only error. > > Longer term, you might want to create your own CA and sign the server > hot cert with that CA. Then provide your public CA cert to Pine and, > theoretically, you won't need "/novalidate-cert" On Fri, 10 Jan 2003, Ken Murchison wrote: > I just tested Pine 4.44 against my Cyrus 2.1.11 using a self-signed cert > (/novalidate-cert) and it works fine. Below is the output from ssldump > (http://www.rtfm.com/ssldump/) for reference. I'd use ssldump to see > where in the negotiation it fails. Finally got it! I followed the exact instructions in the manual for creating a key, and for some reason that worked. Then I realized one other thing I changed in the /etc/imapd.conf file when I used that other key, that being "tls_ca_file:" It seems that the program doesn't like the CA file that comes with RedHat 8.0, and if I specify that file it chokes and dies *only* on TLS connections, SSL works fine. Now that I know the problem, I can figure out a workaround. Thanks Jonathan and Ken for pointing me in the right direction (and thanks to Dr. Pepper for providing caffeinated support). -- Steve Huston - Unix Systems Administrator, Dept. of Astrophysical Sciences Princeton University | ICBM Address: 40.346525 -74.651285 126 Peyton Hall |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1'
Re: STARTTLS negotiation failed
On Fri, 10 Jan 2003, Ken Murchison wrote: > Steve Huston wrote: > > Now, our current Cyrus server has a self-signed cert which Pine doesn't like > > unless you add /novalidate-cert to the hostname of the server. But this time, > > that doesn't even help as it just says "There was an SSL/TLS failure for the > > server" "The reason for the failure was: SSL Negotiation failed" Cyrus also > > reports the same thing in the logs. I understand the point of > > '/novalidate-cert', meaning don't try to check the signing authority on the > > I just tested Pine 4.44 against my Cyrus 2.1.11 using a self-signed cert > (/novalidate-cert) and it works fine. Below is the output from ssldump > (http://www.rtfm.com/ssldump/) for reference. I'd use ssldump to see > where in the negotiation it fails. Ahh, that's just what I needed. Thanks! Now, armed with something to decode the packets, I may have found at least somewhat closer to what the problem is: > 1 2 0.1424 (0.0016) S>C Handshake > ServerHello > Version 3.1 > session_id[32]= > ce 24 19 9e 16 7a da 4a 2d 2d f7 ef 83 24 ff 55 > 19 3d 31 9b 72 9f b9 57 17 bc 61 4a 38 4c c5 4d > cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA > compressionMethod NULL > 1 3 0.1424 (0.) S>C Handshake > Certificate That's what yours showed... I got up to the same point: 1 2 0.7860 (0.0028) S>C Handshake ServerHello Version 3.1 session_id[32]= d0 7e 52 7d 5e db fe 0f dc 8d de 61 a5 1c 37 00 b2 ec 36 9e 0d 41 cd d0 f8 1d 8c 2b 20 d3 11 ee cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 3 0.7860 (0.) S>C Handshake Certificate ERROR: Length mismatch [root@diomedes root]# Hmm... now I'm completely confused. Now if I try to connect via port 993, it works perfectly fine with the same cert and all. But ... I think I'm more puzzled now than I was before. I'm using the same versions of Cyrus and Pine that you tried it on. -- Steve Huston - Unix Systems Administrator, Dept. of Astrophysical Sciences Princeton University | ICBM Address: 40.346525 -74.651285 126 Peyton Hall |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1'
Re: STARTTLS negotiation failed
Steve Huston wrote: > > This is more of a Pine problem than Cyrus, but I'm hoping someone here might > know what I can do... > [...] > Now, our current Cyrus server has a self-signed cert which Pine doesn't like > unless you add /novalidate-cert to the hostname of the server. But this time, > that doesn't even help as it just says "There was an SSL/TLS failure for the > server" "The reason for the failure was: SSL Negotiation failed" Cyrus also > reports the same thing in the logs. I understand the point of > '/novalidate-cert', meaning don't try to check the signing authority on the I just tested Pine 4.44 against my Cyrus 2.1.11 using a self-signed cert (/novalidate-cert) and it works fine. Below is the output from ssldump (http://www.rtfm.com/ssldump/) for reference. I'd use ssldump to see where in the negotiation it fails. [root@eagle]# ssldump -d -i lo -k /var/imap/certs/mail.oceana.com.key port 143 New TCP connection #1: eagle.oceana.com(38414) <-> eagle.oceana.com(143) 0.0315 (0.0315) S>C --- * OK eagle.oceana.com Cyrus IMAP4 v2.1.11 server ready --- 0.0320 (0.0005) C>S --- CAPABILITY --- 0.0324 (0.0004) S>C --- * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE STARTTLS LOGINDISABLED AUTH=SRP AUTH=OTP AUTH=NTLM AUTH=DIGEST-MD5 AUTH=CRAM-MD5 LISTEXT LIST-SUBSCRIBED ANNOTATEMORE X-NETSCAPE OK Completed --- 0.0327 (0.0002) C>S --- 0001 STARTTLS --- 0.1106 (0.0779) S>C --- 0001 OK Begin TLS negotiation now --- 1 1 0.1408 (0.0301) C>S Handshake ClientHello Version 3.1 cipher suites TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_DHE_DSS_WITH_RC2_56_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5 compression methods NULL 1 2 0.1424 (0.0016) S>C Handshake ServerHello Version 3.1 session_id[32]= ce 24 19 9e 16 7a da 4a 2d 2d f7 ef 83 24 ff 55 19 3d 31 9b 72 9f b9 57 17 bc 61 4a 38 4c c5 4d cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 3 0.1424 (0.) S>C Handshake Certificate 1 4 0.1424 (0.) S>C Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_authority 30 81 a9 31 0b 30 09 06 03 55 04 06 13 02 4e 59 31 11 30 0f 06 03 55 04 08 13 08 4e 65 77 20 59 6f 72 6b 31 15 30 13 06 03 55 04 07 13 0c 4f 72 63 68 61 72 64 20 50 61 72 6b 31 0f 30 0d 06 03 55 04 0a 13 06 4f 63 65 61 6e 61 31 28 30 26 06 03 55 04 0b 13 1f 43 65 72 74 69 66 69 63 61 74 69 6f 6e 20 53 65 72 76 69 63 65 73 20 44 69 76 69 73 69 6f 6e 31 17 30 15 06 03 55 04 03 13 0e 4f 63 65 61 6e 61 20 52 6f 6f 74 20 43 41 31 1c 30 1a 06 09 2a 86 48 86 f7 0d 01 09 01 16 0d 63 61 40 6f 63 65 61 6e 61 2e 63 6f 6d ServerHelloDone 1 5 0.1467 (0.0042) C>S Handshake Certificate 1 6 0.1467 (0.) C>S Handshake ClientKeyExchange 1 7 0.1467 (0.) C>S ChangeCipherSpec 1 8 0.1467 (0.) C>S Handshake Finished 1 9 0.1637 (0.0169) S>C ChangeCipherSpec 1 10 0.1637 (0.) S>C Handshake Finished 1 11 0.1643 (0.0006) C>S application_data --- 0002 CAPABILITY --- 1 12 0.1655 (0.0011) S>C application_data ---
Re: STARTTLS negotiation failed
On Fri, 10 Jan 2003, Jonathan Marsden wrote: > On 10 Jan 2003, Steve Huston writes: > > Now, our current Cyrus server has a self-signed cert which Pine > > doesn't like unless you add /novalidate-cert to the hostname of the > > server. But this time, that doesn't even help as it just says > > "There was an SSL/TLS failure for the server" "The reason for the > > failure was: SSL Negotiation failed" Cyrus also reports the same > > thing in the logs. I understand the point of '/novalidate-cert', > > meaning don't try to check the signing authority on the cert, and I > > could overlook things if that was the only error. > openssl s_client -connect server.your.domain:993 > to see openssl negotiate with your server. The info you see (any > warnings, etc.) may give you clues about what specifically Pine is > complaining about. That works fine; the problem seems to be when connecting to 143 and negotiating up to TLS from there (which Pine now does by default, and puts a nice "(INSECURE)" on the screen if you set /notls). > Alternatively, use > openssl x509 -text for both the server that Pine is happy with, and the one it is unhappy > with, and compare the output by hand... what attributes are different > or missing in your new self-signed cert? > Longer term, you might want to create your own CA and sign the server > hot cert with that CA. Then provide your public CA cert to Pine and, > theoretically, you won't need "/novalidate-cert" I did this with the cert currently in use, just never installed the CA on clients. It wasn't used by more than three people, and they knew what to do, so I wasn't worried about it. Now more are getting into not having to use SSH into the building, and the fact that someone couldn't use Squirrelmail from some set-top box in a hotel due to the cert means the new server gets a real signed one. Whoopee. > If you have it around, connecting with mutt rather than Pine might > also be a useful test? Very useful! Same results, connecting to port 993 and starting with SSL enabled works fine, but connecting to 143 and issuing STARTTLS fails just the same. Now I know better where to look. And come to think of it, I think Mozilla, Netscape and OS X's Mail all were using SSL on 993, not TLS on 143. That explains why they worked fine. I tried signing the cert with my own CA, and installing the CA's cert, and all that did was remove the complaint about not being able to verify the cert. Still get the "SSL negotiation failed" message. -- Steve Huston - Unix Systems Administrator, Dept. of Astrophysical Sciences Princeton University | ICBM Address: 40.346525 -74.651285 126 Peyton Hall |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1'
Re: STARTTLS negotiation failed
On 10 Jan 2003, Steve Huston writes: > Now, our current Cyrus server has a self-signed cert which Pine > doesn't like unless you add /novalidate-cert to the hostname of the > server. But this time, that doesn't even help as it just says > "There was an SSL/TLS failure for the server" "The reason for the > failure was: SSL Negotiation failed" Cyrus also reports the same > thing in the logs. I understand the point of '/novalidate-cert', > meaning don't try to check the signing authority on the cert, and I > could overlook things if that was the only error. Use openssl s_client -connect server.your.domain:993 to see openssl negotiate with your server. The info you see (any warnings, etc.) may give you clues about what specifically Pine is complaining about. Alternatively, use openssl x509 -text http://www.xc.org/jonathan| missions worldwide
