dogtagpki

#2920 CMC: Audit Events needed for failures in SharedToken scenarios
Closed: fixed Opened by mharmsen.

Closed: fixed
Reopen Issue

Audit events are required in case of SharedToken failures.Debug logs have it but audit logs doesn't capture them. This behavior is observed when testing is done for "CMC Revocation Request (User-signed)" and SharedSecret.

if we provide incorrect value of sharedsecret in revocation file or ldap missing metainfo ,it will fail during HttpClient request.That's expected.Currently, any failures related to revocation is not getting displayed in audit logs.

Steps to Reproduce:

Provide incorrect shared secret.

Follow procedure:

  • http://pki.fedoraproject.org/wiki/PKI_10.5_CMC_Shared_Token#Example_Enrollment_Procedure

Actual results:

No Audit events getting generated

Expected results:

for consistent behavior, all the success and failure events should be there.

Metadata Update from @mharmsen:
- Custom field component adjusted to None
- Custom field feature adjusted to None
- Custom field origin adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1540440
- Custom field type adjusted to None
- Custom field version adjusted to None

Up for review: https://review.gerrithub.io/398279

commit e7ec7d3004354f4a4a98d696833e531fb7a0e41c (HEAD -> master, origin/master, origin/HEAD, 2920-cmcSharedTokenMissingAudit)
Author: Christina Fu cfu@redhat.com
Date: Fri Feb 2 16:39:30 2018 -0800

Ticket #2920 CMC: Audit Events needed for failures in SharedToken scenarios
This patch adds the missing CERT_STATUS_CHANGE_REQUEST_PROCESSED event in case of shared token failure at revocation;
In addition, a missing validate() call is made for decrypted POP request as well as the failure audit event.
fixes: https://pagure.io/dogtagpki/issue/2920
Change-Id: I45b53f579794c3a5f32cc475a6293240025922c2

Metadata Update from @cfu:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5.5 (was: 10.5)

Metadata Update from @mharmsen:
- Custom field fixedinversion adjusted to pki-core-10.5.5-1.fc27

Re-opened due to discovery of errors.

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.6 (was: 10.5.5)
- Issue status updated to: Open (was: Closed)

Per 10.5.x/10.6 Triage: 10.5

cfu: re-opened due to errors
Edited by mharmsen

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5 (was: 10.6)

up for review:
https://review.gerrithub.io/#/c/dogtagpki/pki/+/416297

commit 0bfc946c7b71973a38003d56c30052982b1f8030 (HEAD -> master, origin/master, origin/HEAD, ticket-2920-SharedTokenFailureAudit-master)
Author: Christina Fu cfu@redhat.com
Date: Wed Jun 20 18:59:28 2018 -0700

Ticket 2920 Part2 of SharedToken Audit
This patch addresses the issue that the original audit message for failure
got overwritten for SharedToken.
fixes https://pagure.io/dogtagpki/issue/2920
Change-Id: I0c09fbcc39135dc9aeee8a49a40772565af996c4

Metadata Update from @cfu:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

Metadata Update from @mharmsen:
- Custom field fixedinversion adjusted to pki-core-10.5.10-1.fc27 (was: pki-core-10.5.5-1.fc27)
- Issue set to the milestone: 10.5.10 (was: 10.5)

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/3038

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.
Metadata
None
None
None
Low
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.