SSL problems with 2.3 and trunk under Debian
I'm wondering if anyone else is seeing problems with SSL working? I can connect fine via HTTP to the default test port of 8008. But trying to connect to 8443 in a browser gives me repeated "connection reset" or "connection was interrupted" errors. I've tried using the certificate and key which come via the subversion checkout, the default Debian snakeoil certificate and key, and a valid, CA signed certificate (and corresponding key). I've tried with both the downloaded version of PyOpenSSL and the system installed version of python-openssl in Debian. All of these combinations yield the same results. Is there a good way to enable some kind of debugging related to the HTTPS server? I've tried changing info to debug in my configuration file, but this doesn't really yield any additional information. -- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - "A good traveller has no fixed plans and is not intent on arriving." -- Lao Tzu (570-490 BC)
I would test the certs on a apache web server and check that they work. There is plenty of logging and documentation to work with. Also have you tried with a web browser to access port 8443. That might provide some debugging insight. Oh and also check DNS. You need to have A and PTR records set correctly for your server. ---Guy (via iPhone) On 5 Jan 2010, at 12:43, Mark Nipper <nipsy@bitgnome.net> wrote:
I'm wondering if anyone else is seeing problems with SSL working? I can connect fine via HTTP to the default test port of 8008. But trying to connect to 8443 in a browser gives me repeated "connection reset" or "connection was interrupted" errors.
I've tried using the certificate and key which come via the subversion checkout, the default Debian snakeoil certificate and key, and a valid, CA signed certificate (and corresponding key). I've tried with both the downloaded version of PyOpenSSL and the system installed version of python-openssl in Debian. All of these combinations yield the same results.
Is there a good way to enable some kind of debugging related to the HTTPS server? I've tried changing info to debug in my configuration file, but this doesn't really yield any additional information.
-- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - "A good traveller has no fixed plans and is not intent on arriving." -- Lao Tzu (570-490 BC) _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
On 05 Jan 2010, Guy wrote:
I would test the certs on a apache web server and check that they work. There is plenty of logging and documentation to work with.
Well, any of them work fine elsewhere. The Apple cert supplied in the checkout itself is expired, but is valid otherwise, yet yields the same broken results. The snakeoil cert is an automatically generated, self-signed certificate which a Debian package has provided at some point. While not ideal, it's a valid certificate otherwise. And my preferred certificate is my actual GoDaddy certificate which is currently in use by my Apache server. It requires an intermediate bundle, but even with all of that defined correctly in my configuration file, I still get the same broken behavior. The question is, where is this logging and documentation? Specifically, what command line options or configuration file options would enable the right kind of debugging as to see what might be going wrong with the HTTPS side of things (since HTTP works fine)?
Also have you tried with a web browser to access port 8443. That might provide some debugging insight.
Yes, that's where I was seeing the connection reset and connection was interrupted messages.
Oh and also check DNS. You need to have A and PTR records set correctly for your server.
All of this is fine. Everything works via HTTP. And none of this would matter anyway with HTTPS. You would simply get warnings from the client (Firefox for example) if the host name didn't match what was in the certificate presented. But it's not even getting that far. -- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - Do daemons dream of electric sleep()?
Hi Mark, --On January 5, 2010 7:14:19 AM -0600 Mark Nipper <nipsy@bitgnome.net> wrote:
Oh and also check DNS. You need to have A and PTR records set correctly for your server.
All of this is fine. Everything works via HTTP. And none of this would matter anyway with HTTPS. You would simply get warnings from the client (Firefox for example) if the host name didn't match what was in the certificate presented. But it's not even getting that far.
Try using the openssl command line tool from a shell to connect to your server. That can print out lots of useful debugging information:
openssl s_client -connect host.example.com:8443 -debug
Also note that the server is explicitly set to use SSLv3_METHOD protocol rather than SSLv23_METHOD. It maybe your client cannot cope with that, in which case you will need to adjust the value in the caldavd.plist (or update the client). -- Cyrus Daboo
On 05 Jan 2010, Cyrus Daboo wrote:
Try using the openssl command line tool from a shell to connect to your server. That can print out lots of useful debugging information:
openssl s_client -connect host.example.com:8443 -debug
Like I said, it's not getting very far in the conversation: --- CONNECTED(00000003) write to 0x1a0a0d0 [0x1a0b740] (118 bytes => 118 (0x76)) 0000 - 80 74 01 03 01 00 4b 00-00 00 20 00 00 39 00 00 .t....K... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............ 0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00 ..3..2../....... 0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00 ................ 0040 - 40 00 00 14 00 00 11 00-00 08 00 00 06 04 00 80 @............... 0050 - 00 00 03 02 00 80 9e 32-f3 6f ad 39 54 50 e4 83 .......2.o.9TP.. 0060 - bd e3 a7 df 2f a3 84 ac-90 5f ca 48 a1 71 e6 d7 ..../...._.H.q.. 0070 - 95 87 f2 e2 f1 29 .....) read from 0x1a0a0d0 [0x1a10ca0] (7 bytes => 0 (0x0)) 26527:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: ---
Also note that the server is explicitly set to use SSLv3_METHOD protocol rather than SSLv23_METHOD. It maybe your client cannot cope with that, in which case you will need to adjust the value in the caldavd.plist (or update the client).
Well, given the above, I don't think we're getting that far. -- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - "Suppose you were an idiot and suppose you were a member of Congress. But I repeat myself." -- Mark Twain
Hi Mark, --On January 5, 2010 10:11:43 AM -0600 Mark Nipper <nipsy@bitgnome.net> wrote:
Try using the openssl command line tool from a shell to connect to your server. That can print out lots of useful debugging information:
openssl s_client -connect host.example.com:8443 -debug
Like I said, it's not getting very far in the conversation: --- CONNECTED(00000003) write to 0x1a0a0d0 [0x1a0b740] (118 bytes => 118 (0x76)) 0000 - 80 74 01 03 01 00 4b 00-00 00 20 00 00 39 00 00 .t....K... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............ 0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00 ..3..2../....... 0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00 ................ 0040 - 40 00 00 14 00 00 11 00-00 08 00 00 06 04 00 80 @............... 0050 - 00 00 03 02 00 80 9e 32-f3 6f ad 39 54 50 e4 83 .......2.o.9TP.. 0060 - bd e3 a7 df 2f a3 84 ac-90 5f ca 48 a1 71 e6 d7 ..../...._.H.q.. 0070 - 95 87 f2 e2 f1 29 .....) read from 0x1a0a0d0 [0x1a10ca0] (7 bytes => 0 (0x0)) 26527:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: ---
Also note that the server is explicitly set to use SSLv3_METHOD protocol rather than SSLv23_METHOD. It maybe your client cannot cope with that, in which case you will need to adjust the value in the caldavd.plist (or update the client).
Well, given the above, I don't think we're getting that far.
So openssl was trying the v23 handshake and failing because the server only does v3. Try this:
openssl s_client -connect host.example.com:8443 -debug -ssl3
-- Cyrus Daboo
On 05 Jan 2010, Cyrus Daboo wrote:
So openssl was trying the v23 handshake and failing because the server only does v3. Try this:
openssl s_client -connect host.example.com:8443 -debug -ssl3
A little further: --- CONNECTED(00000003) write to 0xa870f0 [0xa92490] (87 bytes => 87 (0x57)) 0000 - 16 03 00 00 52 01 00 00-4e 03 00 4b 43 65 e8 5d ....R...N..KCe.] 0010 - aa 9a 76 51 60 a4 3a 24-27 a4 0f a3 0d 69 ed a9 ..vQ`.:$'....i.. 0020 - a7 1d df 33 c1 40 3e 2d-bc 6d c6 00 00 26 00 39 ...3.@>-.m...&.9 0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f .8.5.......3.2./ 0040 - 00 05 00 04 00 15 00 12-00 09 00 14 00 11 00 08 ................ 0050 - 00 06 00 03 02 01 ...... 0057 - <SPACES/NULS> read from 0xa870f0 [0xa8dc80] (5 bytes => 5 (0x5)) 0000 - 15 03 00 00 02 ..... read from 0xa870f0 [0xa8dc85] (2 bytes => 2 (0x2)) 0000 - 02 28 .( 27443:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1061:SSL alert number 40 27443:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: --- -- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - Generalizations are usually flawed by exceptions. -- seen at http://wunderland.com/
And you have in your caldavd.plist the following plist keys? <key>SSLAuthorityChain</key> <key>SSLCertificate</key> <key>SSLPrivateKey</key> On Jan 5, 2010, at 8:17 AM, Mark Nipper wrote:
On 05 Jan 2010, Cyrus Daboo wrote:
So openssl was trying the v23 handshake and failing because the server only does v3. Try this:
openssl s_client -connect host.example.com:8443 -debug -ssl3
A little further: --- CONNECTED(00000003) write to 0xa870f0 [0xa92490] (87 bytes => 87 (0x57)) 0000 - 16 03 00 00 52 01 00 00-4e 03 00 4b 43 65 e8 5d ....R...N..KCe.] 0010 - aa 9a 76 51 60 a4 3a 24-27 a4 0f a3 0d 69 ed a9 ..vQ`.:$'....i.. 0020 - a7 1d df 33 c1 40 3e 2d-bc 6d c6 00 00 26 00 39 ...3.@>-.m...&.9 0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f .8.5.......3.2./ 0040 - 00 05 00 04 00 15 00 12-00 09 00 14 00 11 00 08 ................ 0050 - 00 06 00 03 02 01 ...... 0057 - <SPACES/NULS> read from 0xa870f0 [0xa8dc80] (5 bytes => 5 (0x5)) 0000 - 15 03 00 00 02 ..... read from 0xa870f0 [0xa8dc85] (2 bytes => 2 (0x2)) 0000 - 02 28 .( 27443:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1061:SSL alert number 40 27443:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: ---
-- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - Generalizations are usually flawed by exceptions. -- seen at http://wunderland.com/ _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
On 05 Jan 2010, Morgen Sagen wrote:
And you have in your caldavd.plist the following plist keys?
<key>SSLAuthorityChain</key> <key>SSLCertificate</key> <key>SSLPrivateKey</key>
Yep. All three are set to something (and those files are readable by the user running the server). At various times I've had SSLAuthorityChain set to an empty string when testing something other than my GoDaddy certificate (so, using the SVN supplied certificate and key or the Debian snakeoil certificate and key for example). -- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - "Human sacrifice, dogs and cats, living together... mass hysteria!" -- Dr. Peter Venkman (Bill Murray in "Ghostbusters", 1984)
As a follow up, I was thinking this might be related to the recent switch Debian which enabled IPV6_V6ONLY on all sockets by default (through sysctl's net.ipv6.bindv6only). However, disabling this feature is still resulting in an inoperable SSL connection. So my next inclination is that this might be related to the recent SSL/TLS protocol vulnerability (CVE-2009-3555), and sure enough, it is. Here's something that finally worked for me when connecting to the server on port 8443: --- openssl s_client -connect localhost:8443 -prexit -state -debug -msg -no_tls1 -no_ssl2 Completely disabling any possibility of renegotiation on the client side suddenly gave me a working connection to the server. Now, I assume this is related to changes in Debian's currently packaged OpenSSL library to try to work around the aforementioned vulnerability. The current version is 0.9.8k-7, which according to: --- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562746 is really just 0.9.8l backported to the local version of 0.9.8k in Debian itself. Point being, this is going to start biting people I think as people upgrade. Since I think the ultimate fix is still pending at the moment, I'm not sure if you want to address the issue at all for the time being. I don't even know if Apple has addressed this issue yet or not in Mac OS X. If anyone has any suggestions on how to work around the issue on the client side (specifically Sunbird/Lightning), I'd love to hear them. -- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - And if I close my mind in fear, please pry it open.
If anyone has any suggestions on how to work around the issue on the client side (specifically Sunbird/Lightning), I'd love to hear them.
Edit -> Preferences -> Advanced -> General -> Config Editor (in Sunbird at least): --- security.enable_tls = false security.enable_ssl2 = false (default apparently) Now if I could only figure out how to get my actual GoDaddy certificate to work this way and not just the self-signed, expired certificate provided with the source. For some reason, the SSL3 handshake can't complete successfully with my GoDaddy certificate in place. But this will work for now anyway. -- Mark Nipper nipsy@bitgnome.net (XMPP) +1 979 575 3193 - As a computer, I find your faith in technology amusing.
HI All, is it possible to change the defaults for the iCal web client? I know LA is great and all but it would make my life easier if i could fource the local info. thanks in advance for any suggestions of assistance... Pete OS X server 10.6.2 PS I don't know if anyone else needs this but for my PC users I got eM Client working perfectly. :-)
participants (5)
-
Cyrus Daboo
-
Guy
-
Mark Nipper
-
Morgen Sagen
-
Peter S. Easton Jr.