SSL_get0_verified_chain was exactly what I needed, thanks!
-Original Message-
From: openssl-users On Behalf Of Viktor
Dukhovni
Sent: Friday, October 25, 2019 11:55 AM
To: openssl-users@openssl.org
Subject: Re: Retrieve CA for client cert from SSL*
> On Oct 25, 2019, at 5:38 PM, Jan
> On Oct 25, 2019, at 5:38 PM, Jan Just Keijser wrote:
>
>> Is there a way to figure out which CA the server used to validate the client
>> certificate?
>
> on the server side? you would have to write your own verify callback to
> intercept the certificate stack as it is processed. That
Is looking at the IssuerDN good enough?
Hi Tobias,
On 23/10/19 10:11, tobias.w...@t-systems.com wrote:
Our PKCS11 module development will discontinue and therefore I can`t use it
anymore, but the idea is great and very interesting.
To give more details we need a callback or similar mechanism to replace the
signature created in
On 24/10/19 19:55, Fen Fox wrote:
Is there a way to figure out which CA the server used to validate the
client certificate?
on the server side? you would have to write your own verify callback to
intercept the certificate stack as it is processed. That way, you can
monitor which CA
On Fri, Oct 25, 2019 at 8:50 PM Matt Caswell wrote:
>
>
> On 25/10/2019 09:39, Viktor Dukhovni wrote:
> > On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote:
> >
> >> I'm using OpenSSL 1.1.1d.
> >> Just want to confirm if DHE_DSS cipher suites are not supported by this
> >> version.
> >
On 25/10/2019 09:39, Viktor Dukhovni wrote:
> On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote:
>
>> I'm using OpenSSL 1.1.1d.
>> Just want to confirm if DHE_DSS cipher suites are not supported by this
>> version.
>
> They are supported, but:
>
> * DSS ciphersuites are disabled
> If I have an x-point which follows this representation
> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is
> composed by 33 byte and first byte is '0x02') and I use
> 'EC_POINT_set_compressed_coordinates_GFp' function, it will be
> considered as compressed-y-0 or
But the y bit is indicated by the foutth parameter of
'EC_POINT_set_compressed_coordinates_GFp' function.
Isn't the representation you linked different by that that I linked
previously?
Luca
Thulasi Goriparthi ha scritto:
02 indicates y bit is 0
03 indicates y bit is 1
02 indicates y bit is 0
03 indicates y bit is 1
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.2977=rep1=pdf
Thanks,
Thulasi.
On Fri, 25 Oct 2019 at 16:50, Luca Di Mauro wrote:
>
> Mh, maybe I didn't understand.
>
> If I have an x-point which follows this representation
>
Mh, maybe I didn't understand.
If I have an x-point which follows this representation
https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is
composed by 33 byte and first byte is '0x02') and I use
'EC_POINT_set_compressed_coordinates_GFp' function, it will be
considered
> Thank you! I thought they were the same.
>
> And given an x-only coordinate, how can I find the y coordinate? I
> don't find the relative functions on the documentation.
Well it depends on what you mean. Internally,
EC_POINT_set_compressed_coordinates_GFp will internally automatically
compute
Thank you! I thought they were the same.
And given an x-only coordinate, how can I find the y coordinate? I
don't find the relative functions on the documentation.
Luca
Billy Brumley ha scritto:
Don't do that. As I said, the library is trying to tell you that's not a
point on the
On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote:
> I'm using OpenSSL 1.1.1d.
> Just want to confirm if DHE_DSS cipher suites are not supported by this
> version.
They are supported, but:
* DSS ciphersuites are disabled by DEFAULT. You need to
specify an explicit "-cipher"
Hi,
I'm using OpenSSL 1.1.1d.
Just want to confirm if DHE_DSS cipher suites are not supported by this
version.
Please consider the below simple case,
1. s_server uses a DSA certifcate
2. force s_client to use TLS 1.2 and TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
(DHE-DSS-AES256-GCM-SHA384)
the
Don't do that. As I said, the library is trying to tell you that's not a
point on the secp256k1 curve.
Quickly browsing the standard, you are likely looking for the prime256v1
curve.
BBB
On Fri, 25 Oct 2019, 9.28 Luca Di Mauro, wrote:
> I think it is correct because I extracted the
I think it is correct because I extracted the hexadecimal string from
a packet contained in a pcap.
This compressed point is created following the ETSI TS 103 097 v1.3.1
standard for secured communications in the vehicular communication
context
17 matches
Mail list logo
