#1525 User Certificate Revocation page should be renamed to Self Certificate Revocation
Closed: fixed Opened by rpattath.

EE page: revocation of user certificate does not list all the imported user
certificates

Steps to Reproduce:

goto the ca's eeSSL port and enroll for 2 user certs using the profile
caUserCert
subject name 1 : cn=testuser1,o=example
subject name 2 : cn=testuser2, o=example
goto the ca's agent page and as an agent, approve these certificate requests
goto the ca's eessl port and import these 2 user certificates to the browser.
goto the ca's eessl port and goto the revocation tab
select user certificate.
select a reason to revoke the cert.
click submit.

Actual results:

lists only the cert that was used to login to the EE secure page

Expected results:

Login to the EE ssl page using CA admin cert should list all the imported user
certificates for revocation

The User Certificate Revocation page is actually a self revocation tool because it can only revoke the client certificate that the user used to authenticate to the EE interface. An agent intending to revoke other user's certificate is supposed to use the Revoke Certificates page in the Agent interface instead.

To clarify the distinction, the User Certificate Revocation page probably should be renamed to Self Certificate Revocation.

Per CS/DS Meeting of 08/03/2015: 10.3

Per Bug Triage of 05/05/2016: 10.3.2

NOTE: (cfu) I agree with Endi's comment: https://bugzilla.redhat.com/show_bug.cgi?id=1248113#c2
It should just be a simple renaming of the tab

Per PKI Bug Council of 06/23/2016: 10.4

Per Offline Triage of 11/30/2016-12/01/2016: 10.4 - trivial

Metadata Update from @rpattath:
- Issue set to the milestone: 10.4

Per CS/DS Meeting of August 7, 2017, it was determined to move this issue from 10.4 ==> FUTURE.

Metadata Update from @mharmsen:
- Custom field feature adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field version adjusted to None
- Issue close_status updated to: None
- Issue set to the milestone: FUTURE (was: 10.4)

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

[20171025] - Offline Triage ==> 10.6

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

Fixed in master branch:

  • https://github.com/dogtagpki/pki/commit/889e8dd1881baeea4a5deed77169acc7d736bed6

Metadata Update from @edewata:
- Issue close_status updated to: fixed
- Issue set to the milestone: 10.6.0 (was: 10.6)
- Issue status updated to: Closed (was: Open)

Per 10.5.x/10.6 Triage: 10.6.0

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/2084

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