From: owner-openssl-us...@openssl.org On Behalf Of Pingzhong Li
Sent: Friday, 04 March, 2011 16:11
During a TLS handshake, SSL_get_error call failed and the
error string is retrieved by using the following call:
int sslerror = ERR_get_error();
char buf[120];
char * szError = ERR_error_string(sslerror, buf);
Openssl can record multiple error 'items' so you should loop:
while( (err = ERR_get_error()) != 0 )
ERR_error_string(err, buf), puts (err); // or similar
or just call ERR_print_errors[_fp] which does the loop for you
as long as you want the output to a BIO or FILE*.
Nits: when you supply a buffer to ERR_error_string, its return value
always points to that buffer, so you don't need separate szError.
And technically sslerror should be 'long' to ensure 32 bits,
but in practice very few systems nowadays have 16 bit int,
and those that do may well not support openssl anyway.
What does this error mean:
error:04091068:rsa routines:INT_RSA_VERIFY:bad signature
It means an RSA signature didn't verify; specifically,
after 'decrypting' (y^d mod n) the result isn't the
expected hashes (for SSL protocol signatures) or a
correct encoding of the expected hash (otherwise).
You say this happened during handshake; the only RSA
verifications that should be possible during handshake are:
- client: (Svr)KeyExchange params for EDH_RSA or RSA_EXPORT
- server: (Cli)CertVerify for aRSA client-auth
(the ERR_get_error loop above would show which)
If the signature (packet) was damaged in transit PKCS1
padding would catch this with overwhelming probability
(something like 2^80 to 1, I don't recall exactly),
so either the peer software didn't compute the to-be-signed
value or signature correctly, or the openssl you are using
has a serious bug that affects no one else -- unlikely,
unless you have modified it, or it was built with flaky tools
or executed on a flaky machine; or for a server (handling
Cli-CertVerify) perhaps you have code, perhaps in a callback,
that has corrupted openssl's handshake-check computation.
(One way the peer could compute signatures wrong is if
it is given privatekey and certificate that don't match.
Openssl checks this, but other software might not.)
Which end of the connection are you, what ciphersuite(s)
are you selecting, are you using client-auth, what is at
the other end, and which openssl version are you using?
Can you try commandline openssl s_client to or s_server
from the same peer(s?), with (at least) -msg, and see whether
it gets the same error, and exactly where in the sequence?
Did some search on internet and didn't any useful info.
Any suggestion what to look for to debug?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
