Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1149602

Summary: Certificate Authority ignores invalidityDate and comments in CMC Revocation Request messages
Product: [Retired] Dogtag Certificate System Reporter: Jamil Nimeh <jnimeh>
Component: Certificate ManagerAssignee: Christina Fu <cfu>
Status: CLOSED EOL QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 10.1CC: dpal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 18:38:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
invalidityDate patch for Dogtag 10.1.2 and modified CMCRevoke none

Description Jamil Nimeh 2014-10-06 08:11:17 UTC
Created attachment 944166 [details]
invalidityDate patch for Dogtag 10.1.2 and modified CMCRevoke

Description of problem: When the CA receives CMC revocation messages that contain the invalidityDate optional field, it does not place that invalidityDate field into the CRL entry as an entry extension.  Also comments in the CMC revocation message also are lost, rather than being added as extra, non-CRL info.

I've been able to trace this to base/server/cms/src/com/netscape/cms/authentication/CMCAuth.java, where it does not place either invalidityDate or comments into the IAuthToken.  Further in base/server/cms/src/com/netscape/cms/servlet/cert/CMCRevReqServlet.java the invalidityDate and comments fields are not fetched (even if they had existed in the IAuthToken), so when CMCRevReqServlet.process() is called, the invalidityDate is always null and the comments are always an empty string.

I have attached a patch that fixes these and tested it with Dogtag 10.1.2.  With the patch in place, the resulting CRL after a CMC Revocation Request with the invalidityDate field now has invalidityDate entry extensions with the correct date/time in GMT.

I have also attached a modified CMCRevoke.java that can create a CMC Revocation Control message with the invalidityDate.  It also handles a few other things as well:
1. It uses gnu-getopt for better option parsing than what is currently in place, allowing whitespace between options and values.  It also fixes the fact that you cannot omit both the -h and -c optional arguments (right now you can have either/both -h and -c, but omitting both optional switches will fail).  Also directory expansion of "~" in the path provided to -d does not work, but will work with gnu-getopt.
2. It takes the password argument from a file rather than the command line so as not to expose the password in the process table.
3. The shared secret value currently is the same as the cert/key database password.  The shared secret and certdb passwords may not be the same, and an agent may not want to expose the pin this way, especially since it is a cleartext field.  My modified version allows the user to optionally specify a different shared secret value read from a file (takes the first line of text).
4. A bunch of other options (can specify a certificate and pull issuer and serial from it rather than specify with -i/-s, can generate output in binary DER or PEM, can specify different digest algorithms for use in the signature, etc.

I've included it to help make the CMC revoke message, but if there's anything in there you find useful for updates to CMCRevoke, feel free to use it.

Version-Release number of selected component (if applicable):
Fedora Core 20, x86_64:
Linux gladius 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Dogtag components:
pki-base-10.1.2-2.fc20.noarch
pki-ca-10.1.2-2.fc20.noarch
pki-console-10.1.1-1.fc20.noarch
pki-javadoc-10.1.2-2.fc20.noarch
pki-kra-10.1.2-2.fc20.noarch
pki-ocsp-10.1.2-2.fc20.noarch
pki-ra-10.1.1-1.fc20.noarch
pki-server-10.1.2-2.fc20.noarch
pki-symkey-10.1.2-2.fc20.x86_64
pki-tks-10.1.2-2.fc20.noarch
pki-tools-10.1.2-2.fc20.x86_64
pki-tps-tomcat-10.1.2-2.fc20.noarch

How reproducible: This can be reproduced every time with a modified CMCRevoke tool capable of adding invalidityDate (see attached).


Steps to Reproduce:
1. Using supplied tool, create a CMC revocation message with the following command:
CMCRevoke -d <DBDIR> -p <PASS_FILE> -n <AGENT_NICK> -i <ISSUER> -s <SERIAL> -m <REASON_CODE> -c <COMMENT> -I <INVALIDITY_DATE_GT_STRING>

2. Submit PEM-encoded CMC revocation request message on EE CMC revocation page
3. From agent page, generate a new CRL
4. View CRL from EE page, note that invalidityDate extension is not found in the CRL.

Actual results: No invalidityDate is in the CRL entry for the revoked certificate

Expected results: The invalidityDate in GMT form should be a CRL entry extension for the revoked certificate

Additional info: I originally found this issue in Dogtag 9.0.20 (on FC15).  I haven't looked but I'd assume the general approach in the patch could carry backward to DT9 if that's being maintained at all.

Comment 1 Jamil Nimeh 2014-10-07 08:36:00 UTC
I raised the severity to medium based on the nature of the bug and the description of the severity categories.