A problem that I have with apps/req.c is that it is hardly a good reference
for how to use the API calls.
I think, ideally, that all of openssl.cnf should be entirely an artifact of
the apps, but there are (still, I think) things that can only by constructing
some openssl.cnf configuration and
On 12/22/2021 1:33 PM, Philip Prindeville wrote:
> Should supporting openssl.cnf be part of the library API, or
> externally handled in the command-line utility where it then passes in
> the values extracted from that file?
I don't know how openssl.cnf factors into CSR creation with existing
> On Dec 22, 2021, at 2:18 PM, Jordan Brown
> wrote:
>
> On 12/22/2021 11:45 AM, David von Oheimb wrote:
>> Yet beware that a general-purpose library function that has (at least) the
>> flexibility offered by that app would need a non-trivial set of parameters.
>>
>
> I suspect that it
On 12/22/2021 11:45 AM, David von Oheimb wrote:
>
> Yet beware that a general-purpose library function that has (at least)
> the flexibility offered by that app would need a non-trivial set of
> parameters.
>
I suspect that it would end up looking a lot like the existing API.
There might be a
@Philip,
it should not be hard to copy the core code from apps/req.c and cut out
all parts not needed for generating a PKCS#10 CSR (including its
self-signature).
Yet beware that a general-purpose library function that has (at least)
the flexibility offered by that app would need a
@Philip,
it should not be hard to copy the core code from apps/req.c and cut out
all parts not needed for generating a PKCS#10 CSR (including its
self-signature).
Yet beware that a general-purpose library function that has (at least)
the flexibility offered by that app would need a
