Hi Daniel. On Tue, Mar 4, 2014 at 1:46 AM, Daniel Widdis <[email protected]> wrote: > Hi, Lieven. No worries about sending the key... I can generate a new one > if/when this gets resolved! > > In regard to the serf1 conversation, I'm using the latest version on > macports, 1.3.2. I can work to try to get 1.3.4 loaded somehow but > understand that may not be required.
Yes it is, I think upgrading to serf >1.3.3 will solve this problem for you. Also, I can confirm that macports has serf 1.3.4: http://www.macports.org/ports.php?by=library&substr=serf1 > > Here's the output of the openssl command you requested. This is using a > self-signed cert that works with 1.8.5 and fails with 1.8.8. > > <danielwiddis> ~ $ openssl s_client -connect 192.168.100.59:443 > CONNECTED(00000003) > depth=0 CN = 192.168.100.59 > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 CN = 192.168.100.59 > verify error:num=21:unable to verify the first certificate > verify return:1 Interesting. I was convinced you could only get the second error with chains of length > 1, but that assumption is clearly invalid. This does point in the direction of the two issues Bert fixed in serf 1.3.3 + svn 1.8.8: 1. The second error is error X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE. Before serf 1.3.3 this code wasn't recognized, so serf returned it as "unknown cert error". Svn doesn't allow a user to permanently trust a cert with unknown errors. 2. You get two verification errors at depth 0, which means the svn server credentials callback is called twice. Since svn 1.8.8, you'll get two prompts: - the first allows you to permanently accept the "unable to get local issuer certificate", - the second prompt's behaviour will depend on svn/serf version - svn 1.8.8 with serf <1.3.3: you can temporarily accept the "unknown error" - svn 1.8.8 with serf > 1.3.3: you should be able to permanently accept the ""issuer is not trusted" error So in summary, try upgrading to serf > 1.3.3, it should solve your issue. Lieven > --- > Certificate chain > 0 s:/CN=192.168.100.59 > i:/CN=192.168.100.59 > --- > Server certificate > -----BEGIN CERTIFICATE----- > MIIC2TCCAcGgAwIBAgIJAPKhN26bz/IrMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNV > BAMTDjE5Mi4xNjguMTAwLjU5MB4XDTE0MDMwMTAyMjExNloXDTI0MDIyNzAyMjEx > NlowGTEXMBUGA1UEAxMOMTkyLjE2OC4xMDAuNTkwggEiMA0GCSqGSIb3DQEBAQUA > A4IBDwAwggEKAoIBAQDhpux+KA5HmT78yVFLiasC87R/TelmFlm64UimUllPJuQ/ > n8Hwf+2Zinju675LZByPzAnV7qBhJa17o6RO73alUM1zBdK2Aow4TbJR7hbs5iaa > 6W8z8GeCL4vo8pg7RHaTtiLu8+fiSgtR9A7+pSl7v91NhpEC9amd5HT95HQnJrD6 > QssZEboKSqzWetR/uKjtG9/7VvIQW/kg4GLPHGC4uvQEbQhvClDDaIQ2b6Oxr6Zy > JTxjuzGh+GlewUOVfT0P6LphFVFZj5Q4XgnhUQcOp4dG2w7B+MokwDksHq/g0Mfy > tdPuZs+DxrB3NmTDV2yUK/CMjaf391VVGnf0zq7zAgMBAAGjJDAiMAsGA1UdDwQE > AwIEMDATBgNVHSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQUFAAOCAQEAEor/ > UEO6OKabsQhcAqi6cyjhbEbiDAM78IAQYD6HdY1+XQWNb3P+JxBoojKLJfcC5Lgf > 7kvwWj3F0jeByxsHxcaNGmwEAnr1apuDZNb9o6++oHsMI5Cb8CznSjEUgsKhk8cK > dfH66dd2wHuPyrNVrKrkDFexvwuZ92NkT/WhCZkrWPUXz+F4dolAiIxvgNQkGSgc > aSUA/f9owl0/PJYOV542etU/fPTlwvAklsE8wMFPXwOyzWr/kueAYUSkKgN9/Vv4 > 2cw7VXXQmQjUGaKW2XQ12TIhtP5jRSpLevT9Dwp9LoCl5aq49gz+aUEWtRt0Vobm > U2pyvf2Ke++z7j+eBA== > -----END CERTIFICATE----- > subject=/CN=192.168.100.59 > issuer=/CN=192.168.100.59 > --- > No client certificate CA names sent > --- > SSL handshake has read 1611 bytes and written 518 bytes > --- > New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1 > Cipher : DHE-RSA-AES256-SHA > Session-ID: > 004AEB4377EDD3362C1D36B88B51B21F6033065CDEBBC5EA78D0575242CDF6C3 > Session-ID-ctx: > Master-Key: > 68784FE78DC7C4374FF2CEF0EC59AF4B8570EB75DC62806F987863DA4771C4D86D5ADCA9A7D112C51B403202BA26029A > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket: > 0000 - d8 1e ea f1 26 96 70 cc-02 37 2c 9d df 47 0d 8a ....&.p..7,..G.. > 0010 - b5 4d 77 32 3c 7a e7 21-fc eb 3e 8f e9 da 36 d2 .Mw2<z.!..>...6. > 0020 - 1a da cb 52 64 92 ff f4-f5 54 7d e0 82 13 f4 b1 ...Rd....T}..... > 0030 - 74 77 3d 41 98 a5 38 a8-2a 9a 77 e4 ed 74 38 78 tw=A..8.*.w..t8x > 0040 - ff f6 36 55 75 5c 07 4c-c8 58 bd ea cc 31 09 72 ..6Uu\.L.X...1.r > 0050 - c3 b5 6d 65 fa a0 64 7a-f9 e0 dd c1 9f a4 f2 f8 ..me..dz........ > 0060 - 9f e6 38 08 22 af 37 23-ca c5 1a d9 9b dd 9b 24 ..8.".7#.......$ > 0070 - 19 77 c0 83 f8 a5 cc 70-fa c6 9d d9 da 67 9e 9a .w.....p.....g.. > 0080 - 48 43 93 a0 86 1a 95 8d-f1 f5 a8 5e 23 07 16 41 HC.........^#..A > 0090 - 49 99 c9 e1 5e c3 fa 70-71 bb d8 16 2d 61 01 ab I...^..pq...-a.. > 00a0 - 2e 8d a5 eb 2e 31 f7 81-61 6f ab ee 39 2c e4 12 .....1..ao..9,.. > 00b0 - b3 46 b2 8c 9a dc a7 3d-2e a2 64 48 2b 14 b1 5e .F.....=..dH+..^ > > Start Time: 1393893584 > Timeout : 300 (sec) > Verify return code: 21 (unable to verify the first certificate) > --- > closed > > > > > On 3/3/14, 4:48 PM, Lieven Govaerts wrote: >> >> Hi Daniel, >> >> On Sat, Mar 1, 2014 at 5:06 AM, Daniel Widdis <[email protected]> wrote: >>> >>> I recently upgraded from 1.8.5 to 1.8.8 via macports. The new version >>> refused to permanently accept my self-signed certificate, citing an >>> "unknown >>> error". >>> >>> Certificates generated on Windows 2008 Server using VisualSVN 2.7.4. >>> >>> Hostname is a numeric IP on a VPN (192.168.100.59) >>> >>> Client is Mac OS X 10.9.1 (Mavericks) with svn installed via Macports: >>> subversion @1.8.5_1+universal (active) <---- this setup works >>> subversion @1.8.8_0+no_bdb+universal <---- this setup fails >>> >>> Under 1.8.8: >>> $ svn update >>> Updating '.': >>> Error validating server certificate for 'https://192.168.100.59:443': >>> - The certificate has an unknown error. >>> Certificate information: >>> - Hostname: 192.168.100.59 >>> - Valid: from Mar 1 02:21:16 2014 GMT until Feb 27 02:21:16 2024 GMT >>> - Issuer: >>> - Fingerprint: >>> BE:C4:65:B6:0E:BD:5C:EE:F4:DB:A9:E1:EB:AE:B6:BC:43:F2:E7:5E >>> (R)eject or accept (t)emporarily? t >>> At revision 46. >> >> Could you send: >> - the output of: >> $ openssl s_client -connect 192.168.100.59:443 >> - and/or create a self signed key + cert using your method that fails >> with svn 1.8.8 ? >> >> This should give us the necessary extra info to simulate your issue. >> >> Note: since you're using a self signed certificate this log/key-cert >> pair shouldn't contain any private info, but if you prefer you can >> send them to me privately. >> >> >>> Under 1.8.5 with no other changes: >>> $ svn update >>> Updating '.': >>> At revision 46. >>> >> regards, >> >> Lieven > >
