SSL_GET_SERVER_CERT_INDEX:internal error

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL_GET_SERVER_CERT_INDEX:internal error

Jeremy Harris
Hi,

Library version: OpenSSL: Compile: OpenSSL 1.0.2k-fips  26 Jan 2017
                          Runtime: OpenSSL 1.0.2k-fips  26 Jan 2017
                                 : built on: reproducible build, date
unspecified

CentOS 7.6.181



"14142044:SSL routines:SSL_GET_SERVER_CERT_INDEX:internal error"


What is the meaning of this error return from EVP_PKEY_verify() ?
The term "CERT" implies certificate, but there isn't one involved
here.
--
Thanks,
  Jeremy
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_GET_SERVER_CERT_INDEX:internal error

Viktor Dukhovni
> On Dec 20, 2018, at 8:00 AM, Jeremy Harris <[hidden email]> wrote:
>
> Library version: OpenSSL: Compile: OpenSSL 1.0.2k-fips  26 Jan 2017
>                  Runtime: OpenSSL 1.0.2k-fips  26 Jan 2017
>                 built on: reproducible build, date unspecified CentOS 7.6.181
>
> "14142044:SSL routines:SSL_GET_SERVER_CERT_INDEX:internal error"

This is an SSL library error in your error stack.  Likely left
over from an earlier function call, with no ERR_clear_error()
before the new call.

> What is the meaning of this error return from EVP_PKEY_verify() ?

It is not a crypto library error, and so cannot be a result of
a call to EVP_PKEY_verify().  The function that reports that
error is not reachable from libcrypto.

> The term "CERT" implies certificate, but there isn't one involved
> here.

Perhaps clear your error stack and try again.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_GET_SERVER_CERT_INDEX:internal error

Jeremy Harris
On 20/12/2018 17:16, Viktor Dukhovni wrote:
>> "14142044:SSL routines:SSL_GET_SERVER_CERT_INDEX:internal error"
>
> This is an SSL library error in your error stack.  Likely left
> over from an earlier function call, with no ERR_clear_error()
> before the new call.

Thanks for the hint. You are correct, and a clear before that set
of crypto operations gets me a far more reasonable message.


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?
--
Cheers,
  Jeremy
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_GET_SERVER_CERT_INDEX:internal error

Viktor Dukhovni


> On Dec 20, 2018, at 6:43 PM, Jeremy Harris <[hidden email]> 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.

Perhaps another ciphersuite is then selected, as OpenSSL is trying
to find one that works?  Not all "errors" are actual problems, some
are resolved by taking an alternative code path.

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.

--
--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_GET_SERVER_CERT_INDEX:internal error

Viktor Dukhovni
On Fri, Dec 21, 2018 at 02:24:18PM +0000, Jeremy Harris wrote:

> > 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.

Which naturally does not map to any kind of certificate.  While TLS
1.2 still lives and is still capable of aNULL ciphersuites, it might
make sense to add a line of code to detect that condition, and not
push anything onto the error stack...

> This, I suppose, explains the server-side verify callback never
> being called.

That callback is about client certificates, but in TLS 1.2 and
earlier, it is IIRC not valid to ask for client certificates when
there is no server certificate.

> 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?).

Yes, for pure opportunistic TLS modes for Postfix, when neither
side does anything with certificates.

> Presumably the ALL has added aNULL ciphers back in, after the weird
> aNULL:-aNULL sequence (what might be the reason for that?),

IIRC, this is documented somehere.  The most recentlky removed
ciphers end up at the top of the "stack", and are therefore the
most preferred when they are brought back.  Therefore,

        aNULL:-aNULL:ALL

produces a list in which the aNULL ciphers are preferred to all
others.

> 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).

Yes, it is a "stable" sort.

> 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.

If that's what you want, just use "DEFAULT:..." rather than
"aNULL:-aNULL:ALL:...".

> Is there some way of putting anon suites later in priority?

Note, they're only used when the client enables them, i.e.  the
client has no intention of authenticating the server?  Is there any
point in using certificates at that point?

That said, it does not sound like you want to support them at all,
but if you do, then just "ALL" will leave them at a lower priority
than "aRSA" and "aECDSA".

> Would :+aNULL
> after the ALL but before strength-sort be preferred? It does seem to do
> the right thing in the client hello.

You might do that, but I don't know of any clients that support
*only* aNULL ciphers, so there's not much point in having them
at all, if they're not preferred.

> > 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.

In Postfix we strive to clear the error stack before each high level
operation that reports errors on failure.  That way we're only
reporting the relevant errors.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_GET_SERVER_CERT_INDEX:internal error

Viktor Dukhovni
On Fri, Dec 21, 2018 at 11:20:43AM -0500, Viktor Dukhovni wrote:

> Which naturally does not map to any kind of certificate.  While TLS
> 1.2 still lives and is still capable of aNULL ciphersuites, it might
> make sense to add a line of code to detect that condition, and not
> push anything onto the error stack...

Perhaps this patch is too late for 1.0.2, which is on its last year
of support, and so likely gets security fixes only, but here it is
for the record:

--- ssl/ssl_lib.c
+++ ssl/ssl_lib.c
@@ -2540,8 +2540,13 @@ int ssl_check_srvr_ecc_cert_and_alg(X509 *x, SSL *s)
 
 static int ssl_get_server_cert_index(const SSL *s)
 {
+    const SSL_CIPHER *c = s->s3->tmp.new_cipher;
     int idx;
-    idx = ssl_cipher_get_cert_index(s->s3->tmp.new_cipher);
+
+    /* Certificate-less ciphers don't have a cert index, and that's OK */
+    if (c->algorithm_auth & (SSL_aNULL | SSL_aPSK | SSL_aSRP))
+        return -1;
+    idx = ssl_cipher_get_cert_index(c);
     if (idx == SSL_PKEY_RSA_ENC && !s->cert->pkeys[SSL_PKEY_RSA_ENC].x509)
         idx = SSL_PKEY_RSA_SIGN;
     if (idx == -1)

It avoids needlessly generating the "error" you reported.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users