Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionFraser Tweedale
2019-09-05 06:04:10 UTC
The current controls governing certificate issuance authorisation are limited, falling short for a number of important use cases:
Limited operator authorisation
Currently a single permission, "request certificate", controls whether an operator can issue a certificate, along with the ability to write the subject entity's userCertificate attribute. This check is waived for "self-service" requests and for host principal operators. (The request is still subject to CA ACLs, unless the operator has the "request certificate ignoring caacl" permission, and userCertificate attribute write access checks).
A use case where current implementation falls short: only vpnadmins user group should be able to issue certs for hosts in vpnservers hostgroup (using VPN profile and CA), and only webadmins user group should be able to issue certs for hosts in webservers hostgroup (using HTTPS profile and CA). Currently, "request certificate" permission is required to request the cert, but having that permission means that the operator could request VPN or HTTPS certs regardless of group membership.
Lack of ability to enable/disable self-service
For self-service requests (operator is subject), the "request certificate" permission is not checked. If a CA ACL allows a particular CA+profile to issue a cert to the subject, then self-service is unconditionally allowed. This is not good enough, e.g. if some kind of certificate, though appropriate for the subject, should only be issued by an admin.
Proper operator authorisation (use case (1)) should encompass this, i.e. self-service is allowed when operator scope is a superset of subject scope.
No fine-grained authorisation for revocation.
Currently revocation is an "all or none" permission. Customers should be able to delegate revocation permission to particular principals or groups, optionally scoped to particular CAs.
Related discussion: https://gist.github.com/frasertweedale/6093f2312d16b3958374cc15b55b4d63
See also https://bugzilla.redhat.com/show_bug.cgi?id=1730372 (operator authorisation for revocation).
Comment 3RHEL Program Management
2021-03-05 07:30:47 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
The current controls governing certificate issuance authorisation are limited, falling short for a number of important use cases: Limited operator authorisation Currently a single permission, "request certificate", controls whether an operator can issue a certificate, along with the ability to write the subject entity's userCertificate attribute. This check is waived for "self-service" requests and for host principal operators. (The request is still subject to CA ACLs, unless the operator has the "request certificate ignoring caacl" permission, and userCertificate attribute write access checks). A use case where current implementation falls short: only vpnadmins user group should be able to issue certs for hosts in vpnservers hostgroup (using VPN profile and CA), and only webadmins user group should be able to issue certs for hosts in webservers hostgroup (using HTTPS profile and CA). Currently, "request certificate" permission is required to request the cert, but having that permission means that the operator could request VPN or HTTPS certs regardless of group membership. Lack of ability to enable/disable self-service For self-service requests (operator is subject), the "request certificate" permission is not checked. If a CA ACL allows a particular CA+profile to issue a cert to the subject, then self-service is unconditionally allowed. This is not good enough, e.g. if some kind of certificate, though appropriate for the subject, should only be issued by an admin. Proper operator authorisation (use case (1)) should encompass this, i.e. self-service is allowed when operator scope is a superset of subject scope. No fine-grained authorisation for revocation. Currently revocation is an "all or none" permission. Customers should be able to delegate revocation permission to particular principals or groups, optionally scoped to particular CAs. Related discussion: https://gist.github.com/frasertweedale/6093f2312d16b3958374cc15b55b4d63 See also https://bugzilla.redhat.com/show_bug.cgi?id=1730372 (operator authorisation for revocation).