Lars Noschinski wrote: >>>> Ok. But in this case, the behaviour I observed seems to be indeed a bug >>>> in gnutls, as my certificate list did not contain the server's >>>> certificate, but only the CA certificates. >>> Then please send me something I can reproduce (such as the smallest >>> possible list that I can use to verify the problem and how I can >>> verify it). > > For the certificate list, see > > http://avalon.hoffentlich.net/~cebewee/debug/gnutls/cacert.crt > > (containing the CAcert.org root certificates). > > Now, > > $ gnutls-cli jabberd.jabber.ccc.de --x509cafile cacert.crt > > trusts the server certificate [0]. Now apply the patch [1] to cli.c > and run the patched binary. Now
Hi, Thank you. I've checked the issue and although it sounds strange this quirk of the flag has some logic here. Check what is the output of certtool -e to the list sent by jabberd: > Certificate[0]: C=DE,ST=Hamburg,L=Hamburg,O=Chaos Computer Club > e.V.,CN=jabber.ccc.de > Issued by: O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 > Root > Verifying against certificate[1]. > Verification output: Verified. > > Certificate[1]: O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root > Issued by: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing > Authority,[email protected] > Verifying against certificate[2]. > Verification output: Not verified, Insecure algorithm. > > Certificate[2]: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing > Authority,[email protected] > Issued by: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing > Authority,[email protected] > Verification output: Verified. > > Chain verification output: Not verified, Insecure algorithm. The Certificate[1] is signed using an insecure algorithm. Here you can see that normally gnutls should reject that certificate list. However if the DO_NOT_ALLOW_SAME flag is not set (default), gnutls will keep for verification only Certificate[0] and will verify it against the trusted list and thus passes. However if you set the flag then the list is verified as is and the last certificate in the list is checked against the trusted list. That is the reason for the different result. I have commited a fix in master to have the same result for both methods by allowing the shortening of the list even if the DO_NOT_ALLOW_SAME flag is set except for the 1st certificate (which is the certificate that the flag refers to). You can avoid the problem by having the server only send the first certificate. Sending the whole chain does not help any client who must anyway trust Certificate[1] explicitly since it is signed with insecure algorithm. regards, Nikos _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
