Add a p12 command to create PKCS12 store files
#372
Conversation
|
|
Codecov Report
@@ Coverage Diff @@
## master #372 +/- ##
==========================================
- Coverage 64.20% 63.93% -0.28%
==========================================
Files 55 56 +1
Lines 6613 6696 +83
==========================================
+ Hits 4246 4281 +35
- Misses 2141 2189 +48
Partials 226 226
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
@doug-fitzmaurice-rowden This looks great.
I've proposed a couple of changes for consistency.
command/certificate/p12.go
Outdated
| cli.StringFlag{ | ||
| Name: "password", | ||
| Usage: `Set the password to encrypt the .p12 file.`, | ||
| }, |
There was a problem hiding this comment.
For consistency with other commands, it makes more sense to use --password-file, and then just use utils.ReadStringPasswordFromFile(filename string) (string, error).
command/certificate/p12.go
Outdated
| x509Cert, err := pemutil.ReadCertificate(crtFile) | ||
| if err != nil { | ||
| return errors.Wrap(err, "error reading certificate") | ||
| } |
There was a problem hiding this comment.
An X.509 certificate is usually bundled with an intermediary, we do that by default if you are using step-ca. I think it makes sense that if we pass a bundled certificate, we should include the intermediary automatically in the list of CAs. Don't you think?
You can use pemutil.ReadCertificateBundle(filename string) ([]*x509.Certificate, error) to get all certificates.
There was a problem hiding this comment.
What would happen if a CA is added multiple times? For example one from the cert and one from the --ca flag.
There was a problem hiding this comment.
I'm not sure - I suspect it will be fine as PKCS12 is a dumb collection of certificates. I'll build a few different types and do some tests.
There was a problem hiding this comment.
Regarding bundles - if a bundle is passed to the --ca option it's easy - append all the certs to the CA list.
If one is passed to <crt_file>, we need to work out which one the key applies to, and which is the intermediate as they get stored in different places in the result.
Is the best way to do this extract the public key from the certs and the private key, and compare to find a match? I had a look around the codebase but I couldnt see any existing code that does such a check.
There was a problem hiding this comment.
A X.509 certificate is usually a bundle like:
-----BEGIN CERTIFICATE-----
MII.... the server certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MII.... the intermediate certificate
-----END CERTIFICATE-----
It can also include multiple intermediates at the end. For example, in TLS this is required because your browser only knows the root certificates and he needs the intermediate to build the validation path.
Check for example:
step certificate inspect --format pem --bundle https://www.google.com/So using a PKI with the structure root->intermediate->leaf and using a CA like step-ca it will make sense to create pkcs#12 certificate like:
step ca certificate mariano@smallstep.com mariano.crt mariano.key
step certificate p12 mariano.crt mariano.key --ca $(step path)/certs/root_ca.crtThere was a problem hiding this comment.
The server cert is always the first. The list of intermediates are in order at the end.
server ->signed by-> int1 -> signed by ->int2-> ... and then signed by --ca
…tificate bundles
|
Thanks @maraino - I've pushed another commit with those changes. |
|
@doug-fitzmaurice-rowden the PR is merged to master, we will probably do a new release soon that will include |
|
Fantastic, thanks so much! I have a couple of PRs pending on the upstream library that will hopefully improve compatibility with some Java tools that consume these .p12s. If / when those are merged I'll put up another quick PR here to update the version of |
Description
This PR adds a
step certificate p12subcommand to support bundling keys and certificates together into PKCS12 / p12 / pfx files, as discussed in #244These are commonly used for installing client certificates into Firefox / Windows, and for configuring server certificates for Java applications.
The arguments / options are an attempt at being easy to use, without forcing the user to understand all the different types of p12 that exist.
A password is specifiable on the CLI as one is required for .p12, but is a bit pointless as the encryption is weak. The author of the upstream library this PR uses suggests using a nominal password then protecting the result file using a stronger external method:
https://github.com/SSLMate/go-pkcs12/blob/master/pkcs12.go#L33