Hiho! Simon Josefsson schrieb: > Friedrich Delgado Friedrichs <frie...@nomaden.org> writes: > > svn: OPTIONS von »https://my-repo.dom/svn/project/«: SSL negotiation > > failed: SSL error: Key usage violation in certificate has been > > detected. (https://my-repo.dom/svn/project/) > This is often a simple administrator problem: the cert needs to have the > proper key usage bits in order to be useful as a TLS client/server cert. > > Try and reproduce using the gnutls-cli tool, that will help isolate > whether this is a GnuTLS or administrator or svn problem.
Ok, will try. > > Downgrading to libneon24-gnutls 0.28.2-6.1+b1 seemed to fix the > > problem at first, but I discovered today that it fails against a > > different server. > That is odd, but it is possible that earlier versions didn't check the > certs properly, or that it used a non-DHE cipher suite which doesn't > have the same key usage bit requirements. > > > There is an old bug which would explain that behaviour with the old > > version of libneon-gnutls: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474139 > > Which of those problems? Again there seem to be very different problem > reported in that bug report. This has happened for GnuTLS before too, > so I understand and share your pain in trying to sort things out. Err, I'm just talking about the posts relating to "key usage violation" here, which only happened after an upgrade. (from version 0.28.2-2 on) Especially Joe Orton is referring to your post on http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2789 which points to the same administration error you're referring to here. > > Unfortunately I can't provide client certificates for testing. Any > > idea how to make this bug reproducible? > > One first step is to try and reproduce the problem with gnutls-cli > instead of svn/libneon. Try '-d 4711' to get more debug information > from GnuTLS. Ok, here goes nothing: ,---- u...@host:~> gnutls-cli -d 4711 --x509certfile ~/secret/organisation-user-cert.pem --x509keyfile ~/secret/organisation-user-key.pem --x509cafile secret/organisation-user-ca.pem -p 443 intern.organisation.org Processed 2 CA certificate(s). Processed 1 client certificates... |<2>| ASSERT: x509_b64.c:519 |<2>| ASSERT: privkey.c:171 |<2>| ASSERT: privkey.c:388 |<2>| ASSERT: privkey.c:415 *** Error loading key file: ASN1 parser: Error in DER parsing. `---- The .pem keyfile was generated from a .p12 file I got from our CA with ,---- openssl pkcs12 -in organisation-user.p12 -out organisation-user.pem `---- And I split out the {ca,cert,key} parts with a text editor. The resulting certificate works with openssl s_client connect, e.g. with this commandline: ,---- openssl s_client -cert ~/secret/organisation-user-cert.pem -key ~/secret/organisation-user-key-nopassphrase.pem -CAfile ~/secret/organisation-user-ca.pem -host intern.orgnisation.org -port 443 `---- Hm... This reminds me that I've seen this error before, when trying to configure tls in emacs. I had to drop down to the command line to check the correct tls-program value for emacs to use, and noticed that ASN.1 parsing error with gnutls-cli, and resorted to use openssl instead, but forgot about that error. However I've configured the pkcs12 variant of the certificate file for use with subversion. (How) Can I use the pkcs12 file with gnutls-cli? Or can I convert the pkcs12 file with gnutls, in case there's some problem with the converted file from openssl? I think this might be an entirely different issue again, but this makes it hard for me to reproduce the current behaviour on the command line. Alternatively, can I get some more debugging output out of libneon-gnutls pertaining to its use of gnutls? > > I assume you meant 530510 describes a common administrator problem? I > > can't see which you mean. > > Yes. The administror problem is that you are trying to use a server or > client cert with a DHE ciphersuite without having the necessary key > usage bits (i.e., signing_key) asserted in the certificate. Can you > print just the "key usage" portion of the certificates, to confirm this > theory? ---Zitatende--- Ok, this is the key usage portion of my client certificate: Key Usage (not critical): Digital signature. Non repudiation. Key encipherment. Key Purpose (not critical): TLS WWW Client. Email protection. 1.3.6.1.4.1.311.20.2.2 and this the one of the server certificate (the one that fails with the *new* libneon-gnutls versions): Key Usage (not critical): Digital signature. Non repudiation. Key encipherment. Data encipherment. Key Purpose (not critical): TLS WWW Server. I hope that answers at least some of your questions. Kind regards Friedel -- Friedrich Delgado Friedrichs <frie...@nomaden.org> TauPan on Ircnet and Freenode ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
