Description of problem: After upgrading to Fedora 19, authentication starts failing on svn https connections. No changes were made to the configuration that was working on Fedora 18 before the upgrade. Certificates are still valid - connecting to the same server using the same certificates from a CentOS 6 machine still works. Version-Release number of selected component (if applicable): subversion-1.7.10-1.fc19.x86_64 neon-0.29.6-6.fc19.x86_64 gnutls-3.1.11-1.fc19.x86_64 How reproducible: Always: Steps to Reproduce: 1. Upgrade to Fedora 19 2. svn update 3. watch it fail Actual results: $ svn update Updating '.': Passphrase for '/home/ellert/.globus/usercert.p12': svn: E175002: Unable to connect to a repository at URL 'https://svn.nordugrid.org/repos/nordugrid/arc1/trunk' svn: E175002: OPTIONS of 'https://svn.nordugrid.org/repos/nordugrid/arc1/trunk': SSL handshake failed, client certificate was requested: SSL alert received: Handshake failed (https://svn.nordugrid.org) Expected results: $ svn update Passphrase for '/home/ellert/.globus/usercert.p12': At revision 27886.
I've also seen this. I've been trying to get to the bottom of it using neon-debug-mask. This gives: req: Connecting to 192.168.11.112:443 Negotiating SSL connection. ssl: Client cert provider callback; 1 CA names. ssl: Mapped 1 CA names to 1 DN objects. Passphrase for '/home/sah29/simon.harvey.p12': ssl: Match common name 'Simon Harvey' against '' No client certificate supplied. TLS fatal alert: Handshake failed On a working Fedora 16, I get: req: Connecting to 192.168.11.112:443 Negotiating SSL connection. ssl: Client cert provider callback; 1 CA names. ssl: Mapped 1 CA names to 1 DN objects. ssl: Match common name 'Simon Harvey' against '' ssl: Match common name 'Simon Harvey' against '' Supplying client certificate. Looking at the neon sources, the client certificate is not being provided by the callback function in Subversion which neon is calling (from ne_gnutls.c). I can't yet figure out why. The "gnutls-cli" utility can connect to this server fine if I provide it with the certificate and unencrypted public key from the p12 file.
Having patched neon to enable GNUTLS logging, I see: ssl: Client cert provider callback; 1 CA names. ssl: Mapped 1 CA names to 1 DN objects. 002 ASSERT: pkcs12.c:1091 Passphrase for '/home/sah29/simon.harvey.p12': 009 salt.size: 8 009 iterationCount: 2048 002 ASSERT: pkcs12_bag.c:709 009 salt.size: 8 009 iterationCount: 2048 002 ASSERT: common.c:1848 002 ASSERT: dn.c:307 002 ASSERT: dn.c:409 002 ASSERT: x509.c:521 ssl: Match common name 'Simon Harvey' against '' No client certificate supplied.
Created attachment 772216 [details] Patch against neon-0.29.6 to fix use of uninitialised size_t I've tracked this down to the x509_crt_copy function which is used to duplicate the client certificate. This make two calls to gnutls_x509_crt_export, the first supposedly to evaluate how large to make a memory buffer. Unfortunately, gnutls_x509_crt_export only returns GNUTLS_E_SHORT_MEMORY_BUFFER after first dereferencing the uninitialised size_t argument "output_data_size". This patch correctly initializes size to 0 before calling gnutls_x509_crt_export which appears to fix the problem.
Reported as a neon-specific bug 983563
This was also reported back in November by someone else: http://lists.manyfish.co.uk/pipermail/neon/2012-November/001518.html
*** This bug has been marked as a duplicate of bug 983563 ***