Hi Andreas, The thing is that this is done, the iSaSiLk server just sends the DSA CA certificates in the certificates message, no RSA CA certificates. -----Original Message----- From: Andreas Sterbenz [mailto:[EMAIL PROTECTED]] Sent: den 19 september 2000 09:44 To: Fredrik Lindell (QTX); [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [iaik-ssl] Client authentication failure when using OpenSSL client against iSaSiLk server! It is perfectly legal to use RSA client authentication even if a DSA ciphersuite is used. The server specifies in its certificate request message which types of certificates it allows, if you want to restrict that you can use context.setAllowedCertificateTypes(SSLContext.CERTTYPE_DSS_SIGN) with iSaSiLk (the equivalent is done automatically if you do not have RSA code installed). For more information about client authentication see the certificates.html file from the iSaSiLk documentation. Regards, Andreas Sterbenz mailto:[EMAIL PROTECTED] -----Urspr�ngliche Nachricht----- Von: "Fredrik Lindell (QTX)" <[EMAIL PROTECTED]> An: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Gesendet: Dienstag, 19. September 2000 09:28 Betreff: [iaik-ssl] Client authentication failure when using OpenSSL client against iSaSiLk server! > Hi, > > I'm using OpenSSL 0.9.4 when implementing a SSL client supporting both DSA and RSA cipher suites. The private keys and certificates are set into the SSL clieent context using the following (C++) code (the OpenSSL client can also act as an SSL server): > > ... > if( !SSL_CTX_use_PrivateKey_file (mp_Clt_ctx, dsaKeyFile.getPath(), SSL_FILETYPE_PEM) || > !SSL_CTX_use_PrivateKey_file (mp_Srv_ctx, dsaKeyFile.getPath(), SSL_FILETYPE_PEM) ) { > // error handling > } > > if( !SSL_CTX_use_certificate_file(mp_Clt_ctx, dsaCertFile.getPath(), SSL_FILETYPE_PEM) || > !SSL_CTX_use_certificate_file(mp_Srv_ctx, dsaCertFile.getPath(), SSL_FILETYPE_PEM) ) { > // error handling > } > > if( !SSL_CTX_use_PrivateKey_file (mp_Clt_ctx, rsaKeyFile.getPath(), SSL_FILETYPE_PEM) || > !SSL_CTX_use_PrivateKey_file (mp_Srv_ctx, rsaKeyFile.getPath(), SSL_FILETYPE_PEM) ) { > // error handling > } > > if( !SSL_CTX_use_certificate_file(mp_Clt_ctx, rsaCertFile.getPath(), SSL_FILETYPE_PEM) || > !SSL_CTX_use_certificate_file(mp_Srv_ctx, rsaCertFile.getPath(), SSL_FILETYPE_PEM) ) { > // error handling > } > ... > > When connecting towards an WWW-server that uses SSL with the IAIK iSaSiLk library (version 3.01) just supporting DSA, and the server requires client authentication the wrong certificate chain from the client are sent back to the server (in the certificates SSL message), i.e. the RSA certificate chain are sent to the server even if the selected cipher suite is a DSA cipher suite. If the code above is modified so that the DSA configuration is set after the RSA configuration everything works ok with the DSA www-server, but if the same server but now supporting RSA is used the client sends the DSA certificate chain to the server! > > The used server and client certificates/private keys seems to be ok, since the client works fine agains an Apache server using mod_ssl (Apache/1.3.9 (Win32) mod_ssl/2.4.10 OpenSSL/0.9.4). Both the apache server with DSA only support and one with RSA support yields that the client sends the correct certificate chain when client authentication is switched on. > > Using the Netscape tool SSLTap I have discovered the following: > > For Apache server: The server_hello, certificate and certificate_request messages are sent in separate SSLPlaintext (SSLRecord) structures. > For the iSaSiLk server: The server_hello, certificate, and certificate_request messages are sent in the *same* SSLPlaintext (SSLRecord) structure. > > I think both the above behaviours are ok, but are the behaviour of the iSaSiLk server confusing the OpenSSL based client. Any suggestions and/or comments before I dig into the OpenSSL code? > > Thanks, > /Fredrik ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
