[openssl-users] SSL_GET_SERVER_CERT_INDEX:internal error
jgh at wizmail.org
Fri Dec 21 14:24:18 UTC 2018
On 21/12/2018 00:02, Viktor Dukhovni wrote:
>> Thanks for the hint. You are correct, and a clear before that set
>> of crypto operations gets me a far more reasonable message.
> Makes sense.
>> The error seems to be left around after SSL_accept(), and yet
>> it does not appear in my SNI callback. Worse, my verify callback
>> (which I was expected to appear) does not seem to be being called.
>> Yet the SSL_accept() succeeded.
>> Any ideas on that?
> You provide much too little detail. This particular "error"
> happens when a TLS 1.2 ciphersuite does not correspond to any
> any public key type for which OpenSSL might have a certificate.
A packet capture showed me the server side picking an aNULL ciphersuite.
This, I suppose, explains the server-side verify callback never
being called. The SSL_CTX_set_cipher_list() on both ends was
(which I think was your suggestion from a while back?). Presumably
the ALL has added aNULL ciphers back in, after the weird aNULL:-aNULL
sequence (what might be the reason for that?), and the strength-sorting
managed to put many anon ciphers before authenticating ones
(I can see that in the suites list in the client hello).
Appending another :!aNULL on the client brings sanity back;
the server gets a verify callback and an ocsp callback, and this
leftover error is not left in the stack.
Is there some way of putting anon suites later in priority?
Would :+aNULL after the ALL but before strength-sort be preferred? It
does seem to do the right thing in the client hello.
[ I do wish that OpenSSL had a settable debug level, the way that
GnuTLS does, for showing internal operations such as suite-selection ]
> Before beginning a new high-level operation in the SSL library it
> is good to (at least periodically) clear the error stack. Like
> "errno" it is not cleared on function entry, and persists until
> simply cleared or iteratively consumed for reporting.
It's rather awkward that one doesn't know exactly what such a clear
might be required. Randomly spraying them around is hardly nice.
The comparison with errno is poor; there, if the syscall failed
you know that errno is valid. Here, if the library call fails
you know only that one-or-more of the stack are valid, but not
always the ones first accessible from the stack.
I guess for now I'll put a clear after SSL_accept succeeds, and hope
More information about the openssl-users