Bug 246273

Bob, Wan-Teh, what's your thinking about shipping the "checkcert" tools?

(Michael, if we are going to include it, we might only ship it as an unsupported
tool in /usr/lib/nss/unsupported-tools/ )

Unsupported is fine with me. It's a useful diagnostic tool to have on the system.

I never used checkcert.  CVS logs show that checkcert.c has
never been modified since we open-sourced NSS in 2000.  So
I am afraid that its status is unknown.  It's also possible
that you can use certutil to accomplish what checkcert does.

I didn't even know we have it. If it still builds, go ahead and put it into
unsupported. If others find it's useful, I'm sure we will get bugs and patch
submissions for it.;).

It needs the following patches.  1. Increase MAX_MODULUS from 1024
to at least 2048.  2. Call NSS_NoDB_Init so that it can verify the
signature for a self-signed cert or when the issuer cert is available.
(It doesn't seem to call any NSS initialization function now.)

FWIW, it built and ran for me w/o issue (but the cert I was checking was only 1024).

It's possible that certutil could suffice, but checkcert seemed easier based on
RH & other online documentation.

Created attachment 159102 [details]
Patch for checkcert.c

I had to add the NSS_NoDB_Init call, otherwise checkcert
crashes for me.  It crashes in SECOID_FindOID, called by
the SECU_RegisterDynamicOids call in the main function,
because oidhash is NULL.  I'm wondering why Michael can
run checkcert without issue.

I also updated MAX_MODULUS and a warning about not using
PKCS1 MD5 to what might be the appropriate current values,
and removed an incorrect assertion.

I can't tell you why it runs - perhaps it's got something to do with my certs?

I think it's unclear what the checkcert is supposed to check exactly. Can you
explain?

I was not successful in executing checkcert at all, regardless what parameters I
use, I always get the "usage" output.

I think we should not invest resources into unmaintained and broken tools.

If the functionality can not be achieved with certutil, we should rather move
the functionality over.

If I understand correctly, you can get the same functionality using the
validation functionality of certutil:
  certutil -V

I agree, it seems that using certutil might require one or two additional steps.
While checkcert seems to work on files directly, it appears certutil -V can only
operate on certs imported to the database.

So, you can do this:
mkdir test
cd test
certutil -d . -N
  (create empty db)
certutil -d . -A -n nickname-for-your-cert -t ,, -i certfile (-a)
  (import cert without explicit trust, use -a if it's a PEM file)
certutil -d . -V -n nickname-for-your-cert -u X
  (attempt to validate the cert. Explicitly state the desired usage
   you want to validate using -u. )

Optional:
certutil -d . -A -nickname-for-ca-cert -t ,, -i cacertfile (-a)
  (import a root without explicit trust)

Michael, does this make sense?

vfychain also verifies certificates.

I think we're talking apples & oranges.  In older Fedora versions checkcert was
installed and configured to run from cron to notify the system administrator
when system-wide certs were expiring. Mostly, that'd be for sendmail and apache.
If I understand certutil correctly (which is far from certain), certutil is
intended more for user (browser, etc.) certs.

Rechecking on fedora 8, looks like checkcert has been replaced with certwatch.