cURL / Mailing Lists / curl-library / Single Mail


Enhancements to mk-ca-bundle

From: Patrick Watson <>
Date: Tue, 25 Feb 2014 19:39:15 -0500

I've been working on a few enhancements to cURL's mk-ca-bundle Perl
script and would like to solicit functionality feedback before
submitting a patch.

== Main change ==
Today, mk-ca-bundle outputs all certificates within Mozilla's certdata
file containing the purpose CKA_TRUST_SERVER_AUTH at trust level
CKT_NSS_TRUSTED_DELEGATOR, i.e. CAs trusted to issue SSL server certs.
At NCR, we need the ability to generate a bundle containing the
explicitly untrusted certs (for a blacklist) as well as CAs trusted
for other purposes, such as code signing. Therefore, I have enhanced
mk-ca-bundle to take a list of trust purposes and trust levels on the
command line. It'll then output all certificates which are trusted for
at least one of the requested purposes at one of the requested trust

Example (using y and z as placeholders for the TBD parameter flags):
This would generate a bundle containing all certificates which are not
trusted for either SSL server auth or for code signing.

** Does anyone have an opinion on which flags are used for these
command line parameters? -p could be used for the purpose list, but an
intuitive letter for the trust level isn't available since both -t and
-l are already used.
** The default behavior remains as before: output only SSL server trusted CAs.
** Are there any objections to this change?

== Auxiliary changes ==
(Plain text mode example attached for a single cert)
When outputting in plain text mode (flag -t), I've added the ability
to output several different cert hashes. I did this because the
previous output was MD5, which is inconvenient since Windows normally
displays the certificate "thumbprint" using SHA1. I wanted to maintain
compatibility with any applications/processes out there that still use
the MD5 hash, so I just added SHA1 and SHA256 outputs. However, this
slows down the generation process since we go from creating 1 hash to
creating 3.
** Is this acceptable to everyone? If need be, we could add a command
line parameter to allow picking a hash algorithm.

When outputting the certificate, I also write out the certificate
trust information. I find this to be useful for troubleshooting.
** Is this acceptable to everyone?
** Should this be output only in plain text mode (flag -t)? I
currently output it in both modes since it cannot be recovered from
the certificate PEM encoding.
** Do you have an opinion on if this is output before or after the
==== line? I currently output before the ==== line since I want to
conceptually separate it from the certificate itself. After all, the
trust we place in the cert is not an attribute of the cert itself.

Patrick Watson, CISSP
Senior Software Engineer
NCR Corporation

List admin:

Received on 2014-02-26