SSL_get_certificate

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

SSL_get_certificate

Jeremy Harris
I have a note from 2017 in my code to the effect that
SSL_get_certificate() is broken in that it returns the last
cert loaded rather than the one passed out to the client
(on the server).

Is this still the case?  I can't track down any obvious fix in the
OpenSSL git.

I'd like to use it to pick the right stapling to use, in a dual
RSA/EC server cert installation.
--
Cheers,
  Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: SSL_get_certificate

Jeremy Harris
On 29/08/2019 23:31, Jeremy Harris wrote:
> I have a note from 2017 in my code to the effect that
> SSL_get_certificate() is broken in that it returns the last
> cert loaded rather than the one passed out to the client
> (on the server).

Note that one might have both an EC and an RSA cert loaded.

> Is this still the case?  I can't track down any obvious fix in the
> OpenSSL git.

Nobody knows?

--
Cheers,
  Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: SSL_get_certificate

Viktor Dukhovni
> On Sep 8, 2019, at 1:09 PM, Jeremy Harris <[hidden email]> wrote:
>
>> I have a note from 2017 in my code to the effect that
>> SSL_get_certificate() is broken in that it returns the last
>> cert loaded rather than the one passed out to the client
>> (on the server).
>
> Note that one might have both an EC and an RSA cert loaded.

One of the "CHANGES" entries for 1.0.1d reads:

 *) Call OCSP Stapling callback after ciphersuite has been chosen, so
    the right response is stapled. Also change SSL_get_certificate()
    so it returns the certificate actually sent.
    See http://rt.openssl.org/Ticket/Display.html?id=2836.
    [Rob Stradling <[hidden email]>]

Consequently 1.0.1d and later had the expected behaviour.  However,
in commits this was updated:

 dc144417571735c82853421a8845ef603d828a0b (1.0.2-beta1)
 e5db9c3b67deb80e274f66e3832a9cfba931670c (also master, at the time 1.1.0-dev)

   Minor enhancement to PR#2836 fix. Instead of modifying SSL_get_certificate
   change the current certificate (in s->cert->key) to the one used and then
   SSL_get_certificate and SSL_get_privatekey will automatically work.

The code for "change the current certificate" was:

diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index d0764e8cd3..a438321a41 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -2355,6 +2355,18 @@ int ssl_check_clienthello_tlsext_late(SSL *s)
       if ((s->tlsext_status_type != -1) && s->ctx && s->ctx->tlsext_status_cb)
               {
               int r;
+               CERT_PKEY *certpkey;
+               certpkey = ssl_get_server_send_pkey(s);
+               /* If no certificate can't return certificate status */
+               if (certpkey == NULL)
+                       {
+                       s->tlsext_status_expected = 0;
+                       return 1;
+                       }
+               /* Set current certificate to one we will use so
+                * SSL_get_certificate et al can pick it up.
+                */
+               s->cert->key = certpkey;

But it only runs if there's a "tlsext_status_cb" callback, which may
not cover all the expected use-cases.  I think this merits a new
issue on Github.  On servers the function should return the certificate
used, whether that happened via an SNI callback, or simply via choosing
a certificate for the negotiated algorithm...

>> Is this still the case?  I can't track down any obvious fix in the
>> OpenSSL git.
>
> Nobody knows?

Perhaps I do now...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SSL_get_certificate

Jeremy Harris
On 09/09/2019 16:21, Viktor Dukhovni wrote:

> One of the "CHANGES" entries for 1.0.1d reads:
>
>  *) Call OCSP Stapling callback after ciphersuite has been chosen, so
>     the right response is stapled. Also change SSL_get_certificate()
>     so it returns the certificate actually sent.
>     See http://rt.openssl.org/Ticket/Display.html?id=2836.
>     [Rob Stradling <[hidden email]>]
>
> Consequently 1.0.1d and later had the expected behaviour.  However,
> in commits this was updated:
>
>  dc144417571735c82853421a8845ef603d828a0b (1.0.2-beta1)
>  e5db9c3b67deb80e274f66e3832a9cfba931670c (also master, at the time 1.1.0-dev)
>
>    Minor enhancement to PR#2836 fix. Instead of modifying SSL_get_certificate
>    change the current certificate (in s->cert->key) to the one used and then
>    SSL_get_certificate and SSL_get_privatekey will automatically work.
>
> The code for "change the current certificate" was:

> But it only runs if there's a "tlsext_status_cb" callback, which may
> not cover all the expected use-cases.  I think this merits a new
> issue on Github.

Thanks.  Fortunately it covers mine; I "just" need to work out
how to match up an OCSP resp to the cert.

Could we also get SSL_get_certificate documented?  It doesn't
seem to be currently, despite
https://www.openssl.org/docs/manmaster/man3/SSL_get_tlsext_status_ocsp_resp.html
saying the server should use it.

Another reason for wanting this will be for TLS1.3 with whole-chain stapling.
I wonder whether the library could provide more built-in support for stapling -
attaching the status (chain)(s) to the server certificate chain(s) before
SSL_accept() rather than doing (multiple) callbacks on seeing the client
status-request.
--
Cheers,
  Jeremy