Hi,
At the moment, stunnel's client certificate verification implementation does not include any Distinguished Names (of the trusted CA certificates configured) in the Request Certificate message. Strictly speaking this violates RFC2246 (see below, apologies for formatting), but to date I've only seen one client that has a problem with it. Explorer deals with this by displaying all available user certificates. If the Distinguished Names are included in the cert req it only displays client certs signed by the appropriate CAs.
The patch below does the necessary openssl bits and pieces to make up the lists of DNs so they're sent with the certificate requests. This has been tested under linux only.
7.4.4. Certificate request When this message will be sent: A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will immediately follow the Server Key Exchange message (if it is sent; otherwise, the Server Certificate message). Structure of this message: enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), (255) } ClientCertificateType; opaque DistinguishedName<1..2^16-1>; struct { ClientCertificateType certificate_types<1..2^8-1>; DistinguishedName certificate_authorities<3..2^16-1>; } CertificateRequest; certificate_types This field is a list of the types of certificates requested, sorted in order of the server's preference. certificate_authorities A list of the distinguished names of acceptable certificate authorities. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used both to describe known roots and a desired authorization space. Note: DistinguishedName is derived from [X509]. Note: It is a fatal handshake_failure alert for an anonymous server to request client identification.
Thanks, Diarmuid.
<<stunnel-4.05_ca_list.patch>>
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the postmaster at the address below. ITS-Support@aepsystems.com
Unless the contrary is specifically indicated above nothing in this message is intended to constitute an electronic signature within the meaning of the Electronic Commerce Act 2000 or similar legislation enacted elsewhere in the world.
This footnote also confirms that this email message has been swept for the presence of computer viruses. *****************************************************************************
On 2004-11-17, at 18:59, Diarmuid O'Neill wrote:
Strictly speaking this violates RFC2246
[cut]
These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used both to describe known roots and a desired authorization space.
It does NOT violate RFC 2246. It's just currently not implemented. "may" and "can" usually indicate optional functionality.
Best regards, Mike