Friedrich Delgado Friedrichs <[email protected]> writes:
>> > 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.
Right, and the problem there was a bug in the server cert.
>> > 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...
I suspect your key file is encrypted. The key file should contain a
header like this:
-----BEGIN RSA PRIVATE KEY-----
Does it? If not, try adding '-nodes' to your 'openssl pkcs12' command
line, and retry the gnutls-cli command.
By default OpenSSL is using a non-standardized way to encrypt private
keys that GnuTLS doesn't support.
> 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.
If you can reproduce that, I can help debug it.
> 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?
Not right now, although the library has functions for doing that so
adding the functionality shouldn't be too difficult.
> Or can I convert the pkcs12 file with gnutls, in case there's some
> problem with the converted file from openssl?
Try 'certtool --p12-info'
> 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 don't know -- that is a question for the libneon people.
>> > 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.
The bits looks fine (both digital signature and key encipherment),
although the Key Usage extension itself SHOULD be marked critical
according to the specifications.
Maybe the problem is with the key usage bits in some other certificate
in the chain. Can you post the same info for the other certs too?
/Simon
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
