> On Mar 18, 2019, at 6:51 AM, Graham Leggett wrote:
>
> The CSR is incomplete, but isn’t malformed.
A mandatory part of the CSR is missing. It is malformed.
> The CSR is the in the process of being built. Part of that process involves
> sending the partially complete CSR to another
> On Mar 18, 2019, at 4:02 PM, Dave Coombs wrote:
>
> (Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode
> a given X509_REQ's X509_REQ_INFO for you.)
Yes, i2d_re_X509_REQ_tbs is the key function for constructing the
"to be signed" (tbs) request:
int
On 18 Mar 2019, at 18:49, Viktor Dukhovni wrote:
> A mandatory part of the CSR is missing. It is malformed.
Some further digging shows the CSR is indeed malformed - the old openssl code
created a CSR like this:
507:d=2 hl=2 l= 1 prim: OBJECT:itu-t
while the new openssl code
> This makes sense - however there don’t appear to be any APIs in openssl that
> allow you to manipulate a X509_REQ_INFO structure. I can create it, and
> encode/decode it, but there is no X509_REQ_INFO_get_subject_name() (or
> friends) to populate the structure. X509_REQ_INFO itself is opaque.
> On Mar 18, 2019, at 8:22 PM, Graham Leggett wrote:
>
> How would I decode the X509_REQ_INFO structure on the other side, turning it
> back into X509_REQ?
The function returns the DER form of the CRI, which can then be signed.
You can use d2i_X509_REQ_INFO() to get an X509_REQ_INFO, but
Hi All,
Thanks for all your response.
I have tried to set LD_LIBRARY_PATH to the lib path of newly installed
openssl and still "./openssl version" fails with the same reason.
There is another suggestion to "compile with a RUNPATH set in the
output ELF files. " . Could anyone please provide more
Since openssl verion 1.1.0, code for TLS server can use
`SSL_CTX_set_dh_auto(ctx, 1);` to let openssl handle choice of DH group
which will be used to generate ephemeral keys if a DHE cipher suite is
negotiated.
TLS 1.3 limits DHE parameters to use groups from RFC 7919, from ffdhe2048
to
On 18 Mar 2019, at 22:27, Viktor Dukhovni wrote:
>> (Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode
>> a given X509_REQ's X509_REQ_INFO for you.)
>
> Yes, i2d_re_X509_REQ_tbs is the key function for constructing the
> "to be signed" (tbs) request:
>
> int
On 18 Mar 2019, at 22:02, Dave Coombs wrote:
>> This makes sense - however there don’t appear to be any APIs in openssl that
>> allow you to manipulate a X509_REQ_INFO structure. I can create it, and
>> encode/decode it, but there is no X509_REQ_INFO_get_subject_name() (or
>> friends) to
On 18 Mar 2019, at 04:55, Viktor Dukhovni wrote:
> On Mon, Mar 18, 2019 at 01:06:19AM +0200, Graham Leggett wrote:
>
>> [root@localhost ~]# openssl req -in req.bin -inform der
>> unable to load X509 request
>> 139903756527504:error:0D0C40D8:asn1 encoding
>> routines:c2i_ASN1_OBJECT:invalid
On 18 Mar 2019, at 12:51, Graham Leggett wrote:
>> which has a non-zero length signature algorithm OID (l = 9). Your
>> example has "l=0" where one would expect the signature OID after
>> the extensions.
>
> How do I fix openssl to parse this as it did before?
I've raised this at
11 matches
Mail list logo
