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
Yeah, self-signed certs are absolutely useful - you just need to be very
careful which ones you trust for what.
Such certs are widely used to provide trust anchor information,
typically of root CAs,
but conceptually and pragmatically, as Jordan also stated below,
they can make much sense even
Yeah, self-signed certs are absolutely useful - you just need to be very
careful which ones you trust for what.
Such certs are widely used to provide trust anchor information,
typically of root CAs,
but conceptually and pragmatically, as Jordan also stated below,
they can make much sense even
> 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
On 12/22/2021 1:08 PM, Philip Prindeville wrote:
> I see there being limited application (utility) of self-signed certs, since
> they're pretty much useless from a security perspective, because they're
> unanchored in any root-of-trust.
They're OK once you take a leap of faith, check the
Agree to your very first point about "generate a CSR to be signed elsewhere"
being very different from "generate a self-signed certificate" or even "sign
this CSR" (i.e. become a Registration Authority).
I'm thinking of the case where you have an IoT (a router, a WAP, a digital
camera, a smart
@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
>From a conceptual perspective, I think "creating a CSR" should be different
than "signing a CSR with a given keypair", and on that reason alone I'd
separate them, allowing some small code duplication.
The difference between "signing with a certified key" and "signing with its
own key" is really
Hi,
I'm trying to add a library routine (or routines) to generate a CSR and make
that available to users of Openssl at the API level.
I'm thinking the shortest path might be to extract code from apps/req.c as we
know it's correct.
My only problem (so far) is dealing with the multiple places
12 matches
Mail list logo
