Well, apparently whatever I did to shoehorn that svn 1.8.5 into macports
broke some things, but after just cleaning everything out and starting
from scratch...
I can confirm that subversion 1.8.8 + serf 1.3.4 works with no errors (I
can permanently accept the certificate and life goes on.)
Thanks all for the help (and the patience).
On 3/4/14, 1:17 AM, Lieven Govaerts wrote:
Hi Daniel.
On Tue, Mar 4, 2014 at 1:46 AM, Daniel Widdis <wid...@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 <wid...@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
