Yes, 2.0.16 and 1.0.2l as per https://www.openssl.org/source/
But there will be a 1.0.2m out on Thursday.
Andrew
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Karyn Ulriksen
Sent: Tuesday, October 31, 2017 14:51
To: openssl-users@openssl.org
Subject: [openssl-users
What is the recommended versions for the latest FIPS module (2.0.16 ?) and SSL
libraries (1.0.2l ?) There was not a clear answer. I dug around and came up
with the ones I mentioned, but need a sanity check.
Thanks in advance.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl
On 10/31/2017 01:05 PM, Dave Coombs wrote:
>>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and
>>> NULL for X509_STORE *st since it won't be used, then I think I should get
>>> the desired result, yes, at the cost of ocsp_find_signer(single-entry
>>> certs) and the in
>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and
>> NULL for X509_STORE *st since it won't be used, then I think I should get
>> the desired result, yes, at the cost of ocsp_find_signer(single-entry certs)
>> and the internal creation/destruction of an unused X509_S
On 31/10/17 17:30, Dave Coombs wrote:
> Hi Matt, thanks for your response.
>
>>> Is the correct solution to use OCSP_basic_verify(), which feels like
>>> overkill for my needs (the code in question is *part of* our own
>>> path-validation routine), or might there be some other way?
>>
>> Can you
Hi Matt, thanks for your response.
>> Is the correct solution to use OCSP_basic_verify(), which feels like
>> overkill for my needs (the code in question is *part of* our own
>> path-validation routine), or might there be some other way?
>
> Can you use OCSP_basic_verify() passing in OCSP_NOVERIF
On 31/10/17 16:58, Grace Priscilla Jero wrote:
> Hi Matt,
>
> Please find attached the pcap which contains only the "Hello Client".
Thanks. Switching back to openssl-users.
> Search with ip.src==22.33.40.11
>
> SSL_accept fails with -1 and get error gives the number as 2.
Error 2 is SSL_ERRO
On 31/10/17 16:42, Wouter Verhelst wrote:
> On 31-10-17 17:26, Matt Caswell wrote:
>> I agree its not a great name for it. Unfortunately we are stuck with it
>> for compatibility reasons. If we renamed it we would break any code that
>> is currently using it. We could introduce a new flag with a
On 31-10-17 17:26, Matt Caswell wrote:
> I agree its not a great name for it. Unfortunately we are stuck with it
> for compatibility reasons. If we renamed it we would break any code that
> is currently using it. We could introduce a new flag with a different
> name which does the same thing - but
On 31/10/2017 17:26, Matt Caswell wrote:
On 31/10/17 16:02, Wouter Verhelst wrote:
Hi Matt,
On 31-10-17 16:36, Matt Caswell wrote:
Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
"flags" argument? This basically finds the signer certificate and
verifies the signature usi
On 31/10/17 16:02, Wouter Verhelst wrote:
> Hi Matt,
>
> On 31-10-17 16:36, Matt Caswell wrote:
>> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
>> "flags" argument? This basically finds the signer certificate and
>> verifies the signature using OCSP_BASICRESP_verify(), b
Hi Matt,
On 31-10-17 16:36, Matt Caswell wrote:
> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
> "flags" argument? This basically finds the signer certificate and
> verifies the signature using OCSP_BASICRESP_verify(), but skips all the
> chain validation bit.
Just wanted
On 10/31/2017 10:36 AM, Matt Caswell wrote:
>
> On 31/10/17 13:06, Dave Coombs wrote:
>
>> Either way, I hereby report you've got a few macros in a public
>> header that can't possibly work as things stand. :-)
> Yes - a bug. I'm tempted just to remove them.
>
That seems like the best course of ac
On 31/10/17 13:06, Dave Coombs wrote:
> Hello,
>
> I was fiddling around with OpenSSL 1.1.0 this past weekend, because
> One Day We'll Need To Upgrade (tm), and ran into the following.
>
> We have some code that uses OCSP_BASICRESP_verify() with 1.0.1 /
> 1.0.2 to confirm that the signature on
I did not get the pcap file? Perhaps it got blocked due to message size.
Try sending it direct to me.
Matt
On 31/10/17 13:26, Grace Priscilla Jero wrote:
> Matt,
> Here is more info on the process backtrace where it is stuck.
>
> cat /proc/15602/stack
> [] inet_csk_accept+0xc1/0x1f0
> [] inet_ac
Matt,
If you have any way to enable some kind of logging it will be useful to
find what is the issue.
Why do we get error 2 for ssl_accept. We have seen this for connect but not
sure why we get it for accept.
Thanks,
Grace
On 31-Oct-2017 6:56 PM, "Grace Priscilla Jero"
wrote:
> Matt,
> Here is
Matt,
Here is more info on the process backtrace where it is stuck.
cat /proc/15602/stack
[] inet_csk_accept+0xc1/0x1f0
[] inet_accept+0x28/0xf5
[] sys_accept4+0x11b/0x1b8
[] sys_accept+0xb/0xd
[] system_call_fastpath+0x16/0x1b
[] 0x
Thanks,
Grace
On Tue, Oct 31, 2017 at 4:22 PM,
Hello,
I was fiddling around with OpenSSL 1.1.0 this past weekend, because One Day
We'll Need To Upgrade (tm), and ran into the following.
We have some code that uses OCSP_BASICRESP_verify() with 1.0.1 / 1.0.2 to
confirm that the signature on an ocsp response is correct. This is a macro in
oc
On 31/10/17 10:40, Grace Priscilla Jero wrote:
> Hi Matt,
> yes, we have found that later and have add the call backs. But we never
> get the Client Hello with cookie. The Hello verify request is sent from
> the server.
>
> Thanks for pointing out that listen was for cookies. Now without that
>
Hi Matt,
yes, we have found that later and have add the call backs. But we never get
the Client Hello with cookie. The Hello verify request is sent from the
server.
Thanks for pointing out that listen was for cookies. Now without that
providing the SSL_accept, it hangs. We are unable to figure out
On 31/10/17 06:06, Grace Priscilla Jero wrote:
> Thankyou for the suggestions. After correcting few options the
> "ClientHello" goes successfully but we have failure in "DTLSv1_listen".
> There are'nt any cookies in the Client Hello request.
> But DTLSv1_listen return error and the failure in see
Hello!
I see the CMS-Interface (CMS_encrypt, X_write_CMS, ...) does not support
AES128-GCM.
https://mta.openssl.org/pipermail/openssl-dev/2015-April/001177.html
Is there a list of all supporting ciphers for CMS?
Or how can I find out without trying it?
Thanks!
Chris
--
openssl-users mailin
22 matches
Mail list logo
