Re: svn ls https://... results in "The certificate has an unknown error"

On Monday 07 December 2009 13:55:49 Joe Orton wrote:

> The neon builds can be configured in various different ways, so, it
> could easily be a difference in the builds. If you run:
>
> $ strings /usr/lib/libneon.so.27 | grep Library
>
> (if that is the correct location of the neon library on your box)

Yes, that's the correct location (on both machines):

machine1 % strings /usr/lib/libneon.so.27 | grep Library
neon 0.29.0: Library build, IPv6, libxml 2.7.3, zlib 1.2.3, GNU TLS 2.8.4.

machine2 % strings /usr/lib/libneon.so.27 | grep Library
neon 0.29.0: Library build, IPv6, libxml 2.7.3, zlib 1.2.3, GNU TLS 2.8.4.

> are they both built against GnuTLS or OpenSSL?
>
> If GnuTLS, are the versions of GnuTLS on both machines also the same?

Both have "gnutls-2.8.4" installed and neon is linked against it.

> The stderr output with
>
> neon-debug-mask = 258
>
> configured in ~/.subversion/servers might be useful.

Good call, here's the output (I've replaced the TLD with 'company.invalid'):

------------------------------------------------------------------------

% svn up
Running pre_send hooks
compress: Initialization.
compress: Initialization.
Sending request headers:
OPTIONS /svn/company.invalid/bin HTTP/1.1
User-Agent: SVN/1.6.6 (r40053) neon/0.29.0
Keep-Alive:
Connection: TE, Keep-Alive
TE: trailers
Host: dev.int.company.invalid
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Content-Length: 104
Accept-Encoding: gzip

Sending request-line and headers:
Doing DNS lookup on dev.int.company.invalid...
Connecting to 10.20.11.17
Negotiating SSL connection.
ssl: Got 3 certs in peer chain.
ssl: Match common name '*.company.invalid' against ''
ssl: Match common name 'PositiveSSL CA' against ''
ssl: Match common name 'UTN-USERFirst-Hardware' against ''
ssl: Match common name 'AddTrust External CA Root' against ''
ssl: Match common name 'AddTrust External CA Root' against ''
ssl: Match common name '*.company.invalid' against 'dev.int.company.invalid'
ssl: Identity match for 'dev.int.company.invalid': bad
ssl: Verify peers returned 0, status=0
ssl: Verification failures = -1213934396 (status = 0).
Error validating server certificate for 'https://dev.int.company.invalid:443':
 - The certificate hostname does not match.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: *.company.invalid
 - Valid: from Mon, 11 Jun 2007 00:00:00 GMT until Wed, 15 Sep 2010 23:59:59
GMT
 - Issuer: Comodo CA Limited, Salford, Greater Manchester, GB
 - Fingerprint: d2:d6:76:ee:7c:b1:87:ce:28:6a:0e:eb:c5:03:87:30:cf:1d:a7:b9
(R)eject or accept (t)emporarily? ^CRequest ends, status 0 class 0xx, error
line:
Server certificate verification failed: certificate issued for a different
hostname, certificate has been revoked
Running destroy hooks.
Request ends.
svn: OPTIONS of 'https://dev.int.company.invalid/svn/company.invalid/bin':
Server certificate verification failed: certificate issued for a different
hostname, certificate has been revoked (https://dev.int.company.invalid)
sess: Destroying session.
sess: Destroying session.

------------------------------------------------------------------------

I think here lies the key:

ssl: Match common name '*.company.invalid' against 'dev.int.company.invalid'
ssl: Identity match for 'dev.int.company.invalid': bad

Maybe wildcards are not correctly supported?

Funny detail (maybe this helps), putting the line "neon-debug-mask = 258" into
"~/.subversion/servers" converts the working machine into a non working
machine. Now I got here the question too:

[...]
Error validating server certificate for 'https://dev.int.company.invalid:443':
 - The certificate hostname does not match.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: *.company.invalid
 - Valid: from Mon, 11 Jun 2007 00:00:00 GMT until Wed, 15 Sep 2010 23:59:59
GMT
 - Issuer: Comodo CA Limited, Salford, Greater Manchester, GB
 - Fingerprint: d2:d6:76:ee:7c:b1:87:ce:28:6a:0e:eb:c5:03:87:30:cf:1d:a7:b9
(R)eject or accept (t)emporarily?

That's very strange. Removing the line again and everything is working just
like before. One working machine and one non-working machine. Strange! B-)

-- 
So long... Erik
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428161
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.