#2260 Improving mechanism to restore admin access
Closed: migrated by dmoluguw. Opened by edewata.

Currently if the admin certificate has expired the admin user may get locked out of the system since the REST services for admin require client certificate authentication.

The current mechanism to restore access to the system is to enable the admin enrollment page and then to submit a request to generate a new admin certificate. However, it has several issues:

  • The server has to be restarted to enable the admin enrollment page in CS.cfg which requires direct access to the machine. The restart may be disruptive to other users using the system. Also, the server may not restart if other system certificates have also expired, which leads to more disruption.
  • Once enabled, the admin enrollment page is accessible to public without any authentication. Even though the page will disable itself after the first use, there is a small window between server restart and submitting the request that someone else may gain access to the system. To prevent such problem, the public access should be disabled temporarily (e.g. with firewall), leading to disruptions.
  • The admin enrollment page will generate a new admin user and a new admin certificate. The new admin certificate will need to be added to the old admin user, and then the new admin user can be deleted, so it will require some additional manual steps.

There might be better ways to restore the access:
1. Enable admin password authentication by default. This way the admin user can always renew the admin certificate with password even if the admin certificate has already expired.
2. Provide a renewal mechanism via email. The admin will request a renewal via the UI, then the renewed certificate is sent to the registered email in the admin user account.
3. Provide a tool to generate admin certificate without server (see ticket #1691) and update the LDAP database directly. This may need a direct access to the machine.


This could simplify the manual process in ticket #1669.

As Matt, suggested, we can use this ticket for tracking :

https://bugzilla.redhat.com/show_bug.cgi?id=1274419
where in QA suggested to have extensions option so that it can perform other CA operations as well if needed.This flag could be set/unset based on users test cases

Metadata Update from @edewata:
- Issue set to the milestone: UNTRIAGED

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

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 Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)

Metadata