[openssl-users] SSL_GET_SERVER_CERT_INDEX:internal error

[Jeremy Harris]

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

aNULL:-aNULL:ALL:+RC4:!LOW:!EXPORT:!MD5:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!RC2:!RC6:@STRENGTH

(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
that suffices.

-- 
Cheers,
  Jeremy