Hi Johannes, On Fri, 2024-11-01 at 13:05 +0100, Johannes Schneider via lists.openembedded.org wrote: > Add handling of ca-chains which can consist of more than one > certificate in a .pem file, which need to be split off, processed and > stored separately in the softhsm - as the tool-chain > signing.bbclass::signing_import_cert* -> softhsm -> 'extract-cert' > only supports one-per-file, due to using/expecting "plain" x509 > in-/output. > > The added signing_import_cert_chain_from_pem function takes a <role> > basename, and iterates through the input .pem file, creating numbered > <role>_1, _2, ... roles as needed.
Why do you want to import certificates without corresponding private keys into the singing mechanism? They can't be used for signing, so don't really fit the role concept as I intended it. This mismatch then leads to workarounds such as the _N suffix and the problem below. > Afterwards the certificates can be used or extracted one-by-one from > the softhsm, using the numbered roles; the only precondition - or > limitation - is that the PKI structure has to be known beforhand; > e.g. how many certificates are between leaf and root. The point of the signing.bbclass is to abstract over different HSMs and allow flexible key selection at the .conf level. With this approach, any recipe using this set of generated (certificate-only) roles now needs to know how long the chain is and the PKIs with different layouts are no longer possible. Could you describe you use-case in detail? I think we should try to find a design which avoids using roles for certificate chains, while also allowing different PKI layouts between SoftHSM and actual HSMs. > Signed-off-by: Johannes Schneider <[email protected]> > --- > meta-oe/classes/signing.bbclass | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/meta-oe/classes/signing.bbclass b/meta-oe/classes/signing.bbclass > index 3e662ff73..8af7bbf8e 100644 > --- a/meta-oe/classes/signing.bbclass > +++ b/meta-oe/classes/signing.bbclass > @@ -134,6 +134,36 @@ signing_import_cert_from_der() { > signing_pkcs11_tool --type cert --write-object "${der}" --label "${role}" > } > > +# signing_import_cert_chain_from_pem <role> <pem> > +# > + > +# Import a certificate *chain* from a PEM file to a role. > +# (e.g. multiple ones concatenated in one file) > +# > +# Due to limitations in the toolchain: > +# signing class -> softhsm -> 'extract-cert' > +# the input certificate is split into a sequentially numbered list of roles, > +# starting at <role>_1 > +# > +# (The limitations are the conversion step from x509 to a plain .der, and > +# extract-cert expecting a x509 and then producing only plain .der again) > +signing_import_cert_chain_from_pem() { > + local role="${1}" > + local pem="${2}" > + local i=1 > + > + cat "${pem}" | \ > + while openssl x509 -inform pem -outform der -out ${B}/temp_${i}.der; > do > + signing_import_define_role "${role}_${i}" Calling signing_import_define_role() from an import function breaks the separation and ordering we currently use (first signing_import_define_role(), then import certs/keys) and is surprising compared to the existing signing_import_define_role() Regards Jan > + signing_pkcs11_tool --type cert \ > + --write-object ${B}/temp_${i}.der \ > + --label "${role}_${i}" > + rm ${B}/temp_${i}.der > + echo "imported ${pem} under role: ${role}_${i}" > + i=$(awk "BEGIN {print $i+1}") > + done > +} > + > # signing_import_cert_from_pem <role> <pem> > # > # Import a certificate from PEM file to a role. To be used > -- Pengutronix e.K. | | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#114076): https://lists.openembedded.org/g/openembedded-devel/message/114076 Mute This Topic: https://lists.openembedded.org/mt/109331453/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
