PKCS#10 CSR generation and bulky crypto library - Re: Questions about legacy apps/req.c code
David von Oheimb
dev at ddvo.net
Wed Dec 22 19:45:18 UTC 2021
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
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
I do not like to separate the code sections that handle the alternative
case of generating a self-signed cert
because there are strong similarities with generating a PKCS#10 CSR, so
a split would introduce quite some redundancy.
(The code would deserve some further cleanup, but this is a general
issue that holds for many, if not all, those apps.)
your comments regarding the (self-)signature key to be used for CSR
signing vs. cert signing are not really to the point being asked.
Also your comments on OpenSSL library code size are a side topic here,
though I fully agree that it would be great if
the crypto lib was relieved from much bulk (to which various people
including myself have added quite a bit recently)
that would much better fit in higher-level library. I suggested
<https://github.com/openssl/openssl/pull/4992> this 4 years back, but so
far the project members have not
found time for this. Later I re-phrased the issue later as a major FR:
On 22.12.21 19:58, Kyle Hamilton wrote:
> 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 just a matter of determining the IssuerDN
> to put into the tbsCertificate, and that can be either an automatic
> process (a flag on the certificate generation call, an automatic
> verification that the signing key matches the key to be signed, the
> certificate generation call being provided a NULL certificate or DN to
> identify the signer, or something else) or a manual process (require
> library clients to know the lore that a self-signed key also needs to
> copy the SubjectDN to the IssuerDN).
> But, "generate a certificate" isn't something I'd personally put into
> the basic SSL or crypto handling libraries. The reason is because
> OpenSSL is still used in many embedded systems that will never use
> that functionality, and putting code paths in place that will never be
> used is both a waste of code space and potentially an invitation for
> attackers to exploit their presence. (The same goes for key
> generation, to a degree, but the value of new key generation can at be
> either limited to Denial of Service or, at best, reset the device for
> a new deployment.)
> I know it'll never happen, but I'd love to see another
> libcrypto/libssl client library (libx509, maybe?) be used for the more
> esoteric aspects of creating and verifying certificates.
> -Kyle H
> On Tue, Dec 21, 2021, 22:25 Philip Prindeville
> <philipp_subx at redfish-solutions.com
> <mailto:philipp_subx at redfish-solutions.com>> wrote:
> 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 it
> bifurcates based on gen_x509 (versus newreq) -- which David
> pointed out to me in a separate mail thread back in mid-October.
> What would be the downside to having two completely different code
> paths for handling -x509 (and gen_x509) i.e. a self-signed
> certificate versus generating a CSR?
> The latter would allow me to move the CSR code into a library and
> have the app exercise that API.
> The only downside I can see is that the self-signed certificate
> path might need to duplicate some of the library code.
> Is that acceptable?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users