Add the ability to set friendly name when using `step certificate p12`

[aae42]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Provide the ability to override the friendly name when using step certificate p12.

Why is this needed?

Sometimes we get specific requests for friendly names in pfx packages.
With openssl pkcs12 we can provide the --name parameter.
I can only assume these friendly names are used as part of some other process where
having the default of <subject> - <fingerprint> is unacceptable.

[aae42]

don't do a ton of Go and have never contributed here, but made a start w/ this commit, still need to go through the rest of the contribution guidelines...

[hslatman]

Hi @aae42, sounds like a useful thing to have and good to see you're already working on it. Let us know when we can review or help otherwise 🙂

[zorhehs]

Hi! I would like to work on this, I'll add a flag (e.g. --friendly-name) to step certificate p12 to override the default friendly name, matching openssl's name behavior. Will follow up with a PR.

[zorhehs]

Hi! I would like to work on this, I'll add a flag (e.g. --friendly-name) to step certificate p12 to override the default friendly name, matching openssl's name behavior. Will follow up with a PR

Started digging in and turns out the underlying go-pkcs12 library's Encoder.Encode() (used for the cert+key "identity" case) doesn't expose a friendly-name parameter at all; it hardcodes LocalKeyId to the cert's SHA 1 fingerprint. The CA-only "trust store" path (EncodeTrustStoreEntries) does support custom friendly names though it's already used internally with the default <subject> - <fingerprint>

So I'm planning to scope this PR to adding a --friendly-name flag for the trust-store (--ca-only) case. Let me know if that matches what you had in mind, or if identity-store support matters enough to look into a library level change too