On Mon, May 22, 2006 at 01:55:48PM +0200, Marek Marcola wrote:
> > May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]:
> > warning: TLS library problem: 923:error:0407006A:
> > rsa routines:RSA_padding_check_PKCS1_type_1:
> > block type is not 01:rsa_pk1.c:100:
> > May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]:
> > warning: TLS library problem: 923:error:04067072:
> > rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check
> > failed:rsa_eay.c:639:
> > May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]:
> > warning: TLS library problem: 923:error:0D089006:
> > asn1 encoding routines:ASN1_verify:EVP lib:a_verify.c:168:
>
> On server side this may happen when server tries to decrypt
> CertificateVerify packet which is encrypted with client private key.
> Client should use for this operation PKCS1 padding type 1 (for private
> key operation). This type of padding sets first byte to 0
> and second to 1. Your server after decrypting CertificateVerify
> packet can not find this values and report error.
> Some server may try to use other padding type, for example
> suggested for new application PKCS1 OAEP with is not recognized
> (for now) with CertificateVerify.
Would this also happen when the client's private key does not match
the certificate? Why does the handshake fail at this point? Client
certificates are not mandatory in my application, so if OpenSSL
skipped past the error and acted as though no client credentials
were sent, I would prefer that. Is that possible?
> Maybe you can trace this with ssldump and send decrypted
> CertificateVerify packet ?
Will ssldump help with kEDH? Does the client cert handshake take place
before the traffic becomes encrypted?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
