1506819 – Incorrect SubjectID for CMC_SIGNED_REQUEST_SIG_VERIFY

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1506819 - Incorrect SubjectID for CMC_SIGNED_REQUEST_SIG_VERIFY

Summary: Incorrect SubjectID for CMC_SIGNED_REQUEST_SIG_VERIFY

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	pki-core
Sub Component:
Version:	7.5
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Christina Fu
QA Contact:	Asha Akkiangady
Docs Contact:	Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2017-10-26 20:56 UTC by Matthew Harmsen
Modified:	2020-10-04 21:36 UTC (History)
CC List:	3 users (show)
Fixed In Version:	pki-core-10.5.1-1.el7
Doc Type:	Bug Fix
Doc Text:	Certificate System correctly logs the user name in CMC request audit events Previously, when Certificate System received a Certificate Management over CMS (CMC) request, the server logged an audit event with the SubjectID field set to "$NonRoleUser$". As a result, administrators could not verify who issued the request. This update fixes the problem, and Certificate System now correctly logs the user name in the mentioned scenario.
Clone Of:
Environment:
Last Closed:	2018-04-10 17:01:25 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	dogtagpki pki issues 2939	0	None	None	None	2020-10-04 21:36:12 UTC
Red Hat Product Errata	RHBA-2018:0925	0	None	None	None	2018-04-10 17:02:23 UTC

Description Matthew Harmsen 2017-10-26 20:56:36 UTC

Currently when the server receives a CMC request it will generate the following log:

[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=$NonRol
eUser$][Outcome=Success][ReqType=enrollment][CertSubject=CN=
CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE][SignerInfo=P
KI Administrator] agent pre-approved CMC request signature v
erification

The SubjectID should have been the UID of the person who submits the certificate enrollment or revocation request (i.e. PKI Administrator), but now it says $NonRoleUser$.

Steps to reproduce:

  1. Install a root CA
  2. Install a subordinate CA (https://pki.fedoraproject.org/wiki/Installing_CA_with_External_CA_Signing_Certificate)
    a. Run installation step 1 to generate CA signing CSR
    b. Use CMC on the root CA to issue the CA signing CSR (https://pki.fedoraproject.org/wiki/Issuing_CA_Signing_Certificate_with_CMC)
  3. Inspect the audit log on the root CA

Actual result:

There is one log entry for CMC_SIGNED_REQUEST_SIG_VERIFY event and it has [SubjectID=$NonRoleUser$].

Expected result:

The log entry should have [SubjectID=PKI Administrator].

Comment 2 Matthew Harmsen 2017-10-26 20:59:40 UTC

commit 328654627bfb6d65ae795b5435409c1724d20458 (HEAD -> master, origin/master, origin/HEAD)
Author: Christina Fu cfu
Date: Mon Oct 23 15:56:39 2017 -0700

Ticket #2819  Incorrect SubjectID for CMC_SIGNED_REQUEST_SIG_VERIFY

This patch fixes https://pagure.io/dogtagpki/issue/2819

Before this patch, one would see something like the following (with generic
SubjectID):
[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=$NonRoleUser$][Outcome=Success][ReqType=enrollment][CertSubject=CN=just me cfu,UID=cfu][SignerInfo=UID=TestAgent2,OU=example] agent pre-approved CMC request signature verification

After this patch, one would see the SubjectID being filled in:
[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=UID=TestAgent2,OU=example][Outcome=Success][ReqType=enrollment][CertSubject=CN=just me cfu,UID=cfu][SignerInfo=UID=TestAgent2,OU=example] agent pre-approved CMC request signature verification

Change-Id: I3385a771e0c43d5db7c51e806991039cf14c8b42

Comment 4 Geetika Kapoor 2017-12-06 08:41:30 UTC

Test Environment:
================

non -HSM

rpm -qa pki-*
pki-core-debuginfo-10.4.1-17.el7_4.x86_64
pki-tools-10.5.1-1.el7.x86_64
pki-ocsp-10.5.1-1.el7pki.noarch
pki-kra-10.5.1-1.el7.noarch
pki-console-10.5.1-1.el7pki.noarch
pki-tps-10.5.1-1.el7pki.x86_64
pki-javadoc-10.4.1-17.el7_4.noarch
pki-base-java-10.5.1-1.el7.noarch
pki-ca-10.5.1-1.el7.noarch
pki-base-10.5.1-1.el7.noarch
pki-symkey-10.5.1-1.el7.x86_64
pki-server-10.5.1-1.el7.noarch
pki-tks-10.5.1-1.el7pki.noarch


Test Result:
===========

RootCA --> ExternalCA
(nssdb)    (dogtag-pki)

ca/signedAudit/ca_audit:0.http-bio-8443-exec-1 - [28/Nov/2017:17:16:27 IST] [14] [6] [AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=CN=PKI Administrator,E=caadmin,OU=pki-tomcat,O=EXAMPLE][Outcome=Success][ReqType=enrollment][CertSubject=CN=CA Signing Certificate,OU=topology-CA-EX,O=EXAMPLE][SignerInfo=CN=PKI Administrator,E=caadmin,OU=pki-tomcat,O=EXAMPLE] agent pre-approved CMC request signature verification

Comment 6 Geetika Kapoor 2018-01-29 06:30:21 UTC

One question:

Now we see the correct value of SubjectID but still signerInfo has "$Unidentified$". Also the CertSubject is not picked correctly because certSubject is "[CertSubject=CN=Test11,UID=Testing,OU=test]" which is correctly picked by AuditEvent=PROFILE_CERT_REQUEST.


0.http-bio-20443-exec-2 - [24/Jan/2018:06:41:53 EST] [14] [6] [AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY_SUCCESS][SubjectID=CN=PKI Administrator,E=example,OU=gkapoor_RHCS_75,O=Example-rhcs92-CA][Outcome=Success][ReqType=enrollment][CertSubject=OU=test, , CN=Test11][SignerInfo=$Unidentified$] User signed CMC request signature verification success

Comment 7 Matthew Harmsen 2018-02-13 18:31:08 UTC

(In reply to Geetika Kapoor from comment #6)
> One question:
> 
> Now we see the correct value of SubjectID but still signerInfo has
> "$Unidentified$". Also the CertSubject is not picked correctly because
> certSubject is "[CertSubject=CN=Test11,UID=Testing,OU=test]" which is
> correctly picked by AuditEvent=PROFILE_CERT_REQUEST.
> 
> 
> 0.http-bio-20443-exec-2 - [24/Jan/2018:06:41:53 EST] [14] [6]
> [AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY_SUCCESS][SubjectID=CN=PKI
> Administrator,E=example,OU=gkapoor_RHCS_75,O=Example-rhcs92-
> CA][Outcome=Success][ReqType=enrollment][CertSubject=OU=test, ,
> CN=Test11][SignerInfo=$Unidentified$] User signed CMC request signature
> verification success

Changing gkapoor request for info from me to cfu as she resolved this bug.

Comment 9 Christina Fu 2018-02-13 21:38:54 UTC

(In reply to Geetika Kapoor from comment #6)
> One question:
> 
> Now we see the correct value of SubjectID but still signerInfo has
> "$Unidentified$". Also the CertSubject is not picked correctly because
> certSubject is "[CertSubject=CN=Test11,UID=Testing,OU=test]" which is
> correctly picked by AuditEvent=PROFILE_CERT_REQUEST.
> 
> 
> 0.http-bio-20443-exec-2 - [24/Jan/2018:06:41:53 EST] [14] [6]
> [AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY_SUCCESS][SubjectID=CN=PKI
> Administrator,E=example,OU=gkapoor_RHCS_75,O=Example-rhcs92-
> CA][Outcome=Success][ReqType=enrollment][CertSubject=OU=test, ,
> CN=Test11][SignerInfo=$Unidentified$] User signed CMC request signature
> verification success

Could you provide the entire test case complete with configuration and steps to produce?

In general, whether information will be displayed or not depends on stage of the process.  If info is not there in the audit log, there is a chance that logically the server does not have the info.  For example, if it's a Shared Token request, then in no way will the server know who is responsible for it until the shared token is checked.
In terms of security, One should look at ALL audit events produced by one request.  If the info is eventually gleaned and put in any of the audit entry, then it's considered good.

Comment 11 Geetika Kapoor 2018-02-14 12:40:30 UTC

(In reply to Christina Fu from comment #9)
> (In reply to Geetika Kapoor from comment #6)
> > One question:
> > 
> > Now we see the correct value of SubjectID but still signerInfo has
> > "$Unidentified$". Also the CertSubject is not picked correctly because
> > certSubject is "[CertSubject=CN=Test11,UID=Testing,OU=test]" which is
> > correctly picked by AuditEvent=PROFILE_CERT_REQUEST.
> > 
> > 
> > 0.http-bio-20443-exec-2 - [24/Jan/2018:06:41:53 EST] [14] [6]
> > [AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY_SUCCESS][SubjectID=CN=PKI
> > Administrator,E=example,OU=gkapoor_RHCS_75,O=Example-rhcs92-
> > CA][Outcome=Success][ReqType=enrollment][CertSubject=OU=test, ,
> > CN=Test11][SignerInfo=$Unidentified$] User signed CMC request signature
> > verification success
> 
> Could you provide the entire test case complete with configuration and steps
> to produce?
> 
> In general, whether information will be displayed or not depends on stage of
> the process.  If info is not there in the audit log, there is a chance that
> logically the server does not have the info.  For example, if it's a Shared
> Token request, then in no way will the server know who is responsible for it
> until the shared token is checked.
> In terms of security, One should look at ALL audit events produced by one
> request.  If the info is eventually gleaned and put in any of the audit
> entry, then it's considered good.

-- This behaviour I am seeing with an User CMC scenario like http://pki.fedoraproject.org/wiki/PKI_10.4_CMC_Feature_Update_%28RFC5272%29#User-signed_CMC_requests_Example_.28with_PopLinkWitnessV2.29
If you want we can look this offline and if needed raise a different bugzilla.

Comment 14 errata-xmlrpc 2018-04-10 17:01:25 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0925

Note You need to log in before you can comment on or make changes to this bug.