Hi Daniel.
On Tue, Mar 4, 2014 at 1:46 AM, Daniel Widdis <widdis_at_gmail.com> 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 <widdis_at_gmail.com> 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
>
>
Received on 2014-03-04 08:18:21 CET