[Issues] [mod_gnutls 0000086]: SSLUserName settings and Chained Client Certificates
Mantis Bug Tracker
issues at outoforder.cc
Mon Jul 5 03:28:25 EDT 2010
The following issue has been CLOSED
======================================================================
http://issues.outoforder.cc/view.php?id=86
======================================================================
Reported By: szollosi
Assigned To: nmav
======================================================================
Project: mod_gnutls
Issue ID: 86
Category: Feature Request
Reproducibility: N/A
Severity: block
Priority: normal
Status: closed
Apache Version: 2.2.3
Resolution: fixed
Fixed in Version: 0.5.7
======================================================================
Date Submitted: 2008-04-18 09:16 EDT
Last Modified: 2010-07-05 03:28 EDT
======================================================================
Summary: SSLUserName settings and Chained Client Certificates
Description:
i use SSLUserName settings with mod_ssl. i would like to use something
similar with mod_gnutls.
sometimes i use "Chained Client Certificates" but mod_gnutls told me it is
not supported:
"[Fri Apr 18 14:37:24 2008] [info] [client 10.104.2.60] GnuTLS: Failed to
Verify Peer: Chained Client Certificates are not supported."
(it was the bad certificate from issue#85)
i would like to use this if possible.
thanks!
======================================================================
----------------------------------------------------------------------
(0000116) nmav (manager) - 2008-05-06 15:59
http://issues.outoforder.cc/view.php?id=86#c116
----------------------------------------------------------------------
I like these features and they are not too difficult to implement. I will
keep them in my todo list, but I'm quite busy, so don't expect anything
soon. Patches of course are always welcome.
----------------------------------------------------------------------
(0000150) jmdesp (reporter) - 2009-06-30 13:32
http://issues.outoforder.cc/view.php?id=86#c150
----------------------------------------------------------------------
Hi, I'm going to provide a _minimal_ patch for the "Chained Client
Certificates" issue.
That _minimal_ patch will be the one that I can make work with the
smallest effort. Basically the idea is that if they are several x509
certificate, we'll look for the first one that's not a CA, and we'll
assume the user cert is that one.
Yes, that's limited, but with a small change, it'll stop chained client
certificate from systematically returning an error. The server will have
to know all intermediate certificates even when the client can provide
them, but for client certificates it's much less annoying than it is in
other case.
This said the SSLUserName issue is something completely different, and
should have a separate bug.
----------------------------------------------------------------------
(0000151) nmav (manager) - 2009-06-30 13:52
http://issues.outoforder.cc/view.php?id=86#c151
----------------------------------------------------------------------
In TLS you are assured that the first certificate in the client certificate
list is the actual client certificate. If I remember correct, all you need
to do is also use the additional certficates in the list for certificate
verification.
----------------------------------------------------------------------
(0000163) jmdesp (reporter) - 2009-07-01 09:26
http://issues.outoforder.cc/view.php?id=86#c163
----------------------------------------------------------------------
I see. If the whole list is guaranteed to be ordered, simply replacing the
call to gnutls_x509_crt_verify by a call to gnutls_x509_crt_list_verify,
after parsing them all, would work.
If not, it gets more complex, because gnutls_x509_crt_verify that does not
require the cert to be ordered only receives a list of *trusted* ca certs
as input.
So I think it's required to order them, and then call
gnutls_x509_crt_list_verify.
----------------------------------------------------------------------
(0000165) jmdesp (reporter) - 2009-07-07 14:32
http://issues.outoforder.cc/view.php?id=86#c165
----------------------------------------------------------------------
Attached is a tentative patch for gnutls_hooks.c to add x509 chain
handling.
You did not confirm if the list will be ordered, but I thought that the
most common case is with only one intermediate case, in which case there's
no ordering to do, so I went with gnutls_x509_crt_list_verify.
Checked that it fails when I provide only the end cert verification, and
then works when the client provides also the intermediate.
Checked that it doesn't fail if you both provide the intermediate cert and
have it also in the config.
Note : I changed the indentation, and somehow couldn't get rid of some
spurious white-space differences even with "diff -w", so I had to edit the
patch by hand to remove them. I hope I did not break the patch by doing
that.
----------------------------------------------------------------------
(0000170) nmav (manager) - 2009-07-20 17:09
http://issues.outoforder.cc/view.php?id=86#c170
----------------------------------------------------------------------
Hi and sorry for the late reply. I have applied the patch in the svn trunk.
It needed some hand tweaking so I'd appreciate if you can check that
everything is all right. Also let me know of your name and optionally
email to mention in the news.
Issue History
Date Modified Username Field Change
======================================================================
2008-04-18 09:16 szollosi New Issue
2008-04-18 09:16 szollosi Apache Version => 2.2.3
2008-05-06 15:58 nmav Issue Monitored: nmav
2008-05-06 15:59 nmav Note Added: 0000116
2009-06-30 13:32 jmdesp Note Added: 0000150
2009-06-30 13:52 nmav Note Added: 0000151
2009-07-01 09:26 jmdesp Note Added: 0000163
2009-07-07 14:26 jmdesp File Added: gnutls_hooks.patch
2009-07-07 14:32 jmdesp Note Added: 0000165
2009-07-20 17:07 nmav Note Added: 0000170
2009-07-20 17:09 nmav Note Edited: 0000170
2010-07-05 03:23 nmav Status new => resolved
2010-07-05 03:23 nmav Fixed in Version => 0.5.7
2010-07-05 03:23 nmav Resolution open => fixed
2010-07-05 03:23 nmav Assigned To => nmav
2010-07-05 03:28 nmav Status resolved => closed
======================================================================
More information about the Issues
mailing list