Friedrich Delgado Friedrichs <[email protected]> writes: > Ok, it's getting really interesting now, I've spotted an important > difference: > > Simon Josefsson schrieb: >> Friedrich Delgado Friedrichs <[email protected]> writes: >> > I did that, and re-tried the gnutls-cli line, with a different result: >> > >> > ,---- >> > Processed 3 CA certificate(s). >> > Processed 3 client certificates... >> > Processed 3 client X.509 certificates... >> > Resolving 'intern.organisation.org'... >> > Connecting to 'NNN.NNN.NN.NNN:443'... >> > *** Fatal error: Key usage violation in certificate has been detected. >> > *** Handshake has failed >> > GNUTLS ERROR: Key usage violation in certificate has been detected. >> > `---- >> > >> > Looks like I can reproduce the problem with gnutls-cli. > > The interesting parts is: > > I could not reproduce this any more, because I had re-exported (and > overwritten) the files with certtool. So I deleted the pem files and > re-exported with openssl x509 -nodes ... > > Sometimes I could connect to the server now, with slight variations of > the command line, and I figured out why: > > I was lazy and gave the same file as x509 cert, ca and keyfile. The > important difference is that gnutls-cli does not like it if the key is > in the same file as the cert.
I don't think so -- the problem is more likely to be that you are telling gnutls-cli to use the CA cert as the client cert. > I.e. the following gives a key usage violation error: > ,---- > gnutls-cli -p 4711 --x509certfile > /home/user/secret/organisation-user.pem -p 443 intern.organisation.org > --x509keyfile /home/user/secret/organisation-user-key-nopassphrase.pem > `---- > > `organisation-user.pem' being the output of openssl x509, with ca, > cert and key in one file. > > And the following works: > > ,---- > gnutls-cli -p 4711 --x509certfile > /home/user/secret/organisation-user-ca+cert.pem -p 443 > intern.organisation.org --x509keyfile > /home/user/secret/organisation-user-key-nopassphrase.pem > `---- > > `organisation-user-ca+cert.pem' containing ca + user certs without > key. That's fairly expected and correct, isn't it? I'm assuming the CA cert doesn't have the Digital signature and Key encipherment key usage bits set. You are trying to authenticate against the server using the CA cert. So gnutls-cli is refusing to use the CA cert as a client cert in the connection. > The pkcs12 file of course contains the cert, ca and key in the same > file. > > Now from > http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn.sslcerts > it looks like svn only supports pksc12 type certificates and has to > have cert and key in one file (if I read that correctly), and exactly > that seems to be the problem here, as I can reproduce with gnutls-cli > if I put the key into the same file as the certs. No, the problem above is that you are asking gnutls-cli to authenticate with a client cert (i.e., the CA cert) that isn't usable as a client cert. >> Now it becomes interesting! Try adding '--print-cert --verbose' to >> print the cert chain returned by the server. Does the server cert have >> the 'Digital signature' and 'Key encipherment' key usage bits? > > Note that if I use the version with the keys, I don't even see the > server certificates. > > ,---- > gnutls-cli --print-cert --verbose -p 4711 --x509certfile > /home/user/secret/organisation-user.pem -p 443 intern.organisation.org > --x509keyfile /home/user/secret/organisation-user-key-nopassphrase.pem > `---- > > gives me: > > ,---- > Processed 3 client certificates... I suspect the organisation-user.pem file still contains more than the client certificate. You need to put the client certificate _first_ in the --x509certfile file, and any (optional) sub-CA certs after the client cert. >> You need to separate the key from the certificates after decoding the >> PKCS#12 structure. > > So the question is, how can I use pkcs12 with subversion and gnutls? That is a subversion or neon question, and I don't know the answer. GnuTLS provides interfaces for using PKCS#12 files, subversion/neon just have to use them (if it doesn't already). > I take the liberty of skipping the rest of your questions. If you > think they are still important after what I've discovered, I can > answer them, but I have a feeling that won't be the case. Right. /Simon -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
