Marek Marcola wrote: > Hello, > >>>> In the application I'm currently working on which uses OpenSSL via >>>> Ruby, I seem to be having a problem with the handshake when a client >>>> connects to my server, though my client to their server works fine. >>>> From an ssldump, it appears that my server's certificate request does >>>> not include any certificate_authority entries. Because of this, the >>>> client does not send its certificate and the handshake fails. >>>> >>>> ssldump examples: >>>> >>>> Their server sends a certificate request like this: >>>> >>>> 1 4 0.2734 (0.0064) S>C Handshake >>>> CertificateRequest >>>> certificate_types rsa_sign >>>> certificate_types dss_sign >>>> certificate_authority >>>> C=US >>>> O=Equifax >>>> OU=Equifax Secure Certificate Authority >>>> certificate_authority >>>> C=US >>>> O=Equifax Secure Inc. >>>> CN=Equifax Secure eBusiness CA-1 >>>> certificate_authority >>>> C=US >>>> O=RSA Data Security, Inc. >>>> OU=Secure Server Certification Authority >>>> >>>> >>>> My server only sends this: >>>> >>>> 2 4 0.1097 (0.0000) S>C Handshake >>>> CertificateRequest >>>> certificate_types rsa_sign >>>> certificate_types dss_sign >>>> ServerHelloDone >>>> >>>> The client requires the certificate_authority information as seen in >>>> the first example, but I'm not sure what needs to be set to make that >>>> happen and a list archive search hasn't helped. In the SSL context for >>>> the connection I set the certificate, key, verify_mode, and ca_path. >>>> Am I missing something? Where does this certificate_authority >>>> information come from? >>>> >>> This is optional info and if it is not provided then client may sent >>> any certificate of specified type (here: RSA or DSS). >>> Maybe your client does not have key/cert loaded ? >>> Have you any errors on client or server ? >>> Try: >>> $ openssl s_client -connect ip:port -state -msg -debug >>> $ openssl s_client -connect ip:port -state -msg -debug -cert \ >>> client_crt.pem -key client_key.pem >>> Full SSL session ssldump will be helpful too. >>> >>> Best regards, >>> -- >>> Marek Marcola <[EMAIL PROTECTED]> >>> > .... > >> Marek, >> >> Regarding the CA information being optional in a certificate request >> message, RFC 2246 seems to be vague in this regard. >> >> I've been diagnosing >> a similar issue with a client running on IBM z/OS, and the IBM engineers >> are telling this client that RFC 2246 _requires_ the CA information to >> be present. >> > > RFC2246 says (about CA DNs in certificate_request packet): > > 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. > > (this is exactly get from SSL3 draft specification). > We can of course discuss what this means, "list of DNs" means one or > more or zero or more. > But in RFC4346 (which obsoletes RFC2246) we have: > > 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 to describe both known roots and a > desired authorization space. If the certificate_authorities > list is empty then the client MAY send any certificate of the > appropriate ClientCertificateType, unless there is some > external arrangement to the contrary. > > and here there is no doubt that CA DNs in certificate_request packet > may be empty. > > >> Apparently IBM's client code considers the lack of CA >> information to be a fatal error. >> > I've tested OpenSSL, GNUTLS and NSS (mozilla Network Security Services) > and there is no situation to return fatal error when client received > certificate_request without CA DNs. > In most cases, client sends his certificate in response to this packet > (OpenSSL, GNUTLS, NSS (mozilla, opera) and in one case (NSS - firefox) > client sends ssl alert "no_certificate" (41) as warning (not fatal) > and handshake continues. > > >> Is it the position of the OpenSSL >> project that the CA information is indeed "optional", and if so is it >> taking the "optional" stance just from the vagueness of the RFC, or am I >> missing something that clearly states the optionality? Is there a >> general consensus that this is optional, or is there disagreement on >> this point? >> > In new specification (RFC4346: TLS1.1 and TLS1.2 draft) this is clearly > specified, in RFC2246: TLS1.0 we can discuss what this means. > But even in RFC2246 we can not clearly say that this is REQUIRED. > > But from the other hand, there are books about SSL (like: > "SSL and TLS Essentials. Securing the Web") with information > that this is list of one or more CA DN's. > > In my opinion this is optional (zero or more). > > Best regards, >
Marek, That's exactly the info I was after. I was not aware of RFC4346, but that clears up the ambiguities of 2246 nicely. The IBM z/OS client is the only one I've ever encountered that behaves in this fashion, and I've advised this client of ours to report this as a bug to IBM, especially in lieu of RFC4346. Many thanks, Doug ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
