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 Marcola <[EMAIL PROTECTED]>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to