Re: Openssl-1.0.2t availability

2019-09-09 Thread Jakob Bohm via openssl-users

On 09/09/2019 20:56, Nikki D'Ambra wrote:

Hello,

I was wondering when the latest version openssl, version 1.0.2t will 
be available for public download?


Announcement is 2019-09-10 between 12:00 and 16:00 UTC approximately.  
That's about 17 to 21 hours after your question.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



Openssl-1.0.2t availability

2019-09-09 Thread Nikki D'Ambra
Hello,

I was wondering when the latest version openssl, version 1.0.2t will be
available for public download?

Thank you,
Nikki


Re: Compiling OpenSSL 1.1 - certs directory is empty, how to obtain?

2019-09-09 Thread Salz, Rich via openssl-users
Another great source is https://github.com/nabla-c0d3/trust_stores_observatory

One-stop shopping for all of apple, Android, Windows, NSS, OpenJDK, Oracle Java.




Re: SSL_get_certificate

2019-09-09 Thread Viktor Dukhovni
> On Sep 8, 2019, at 1:09 PM, 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.

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 ]

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.