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.
DescriptionAbhinay Reddy Peddireddy
2020-08-29 09:13:37 UTC
Description of problem:
The root CA key of our Idm realm is 2048 bits long. This is the strict minimum allowed by our corporate security policy, so the question arose if it's possible to replace it with a longer key and what it would take to do so.
The CA server roles in the Idm realm are running RHEL 7.7. We use sub-ca's in our environment.
What steps do we need to take to replace the root CA key with another key with 3072 bits, for instance? Do we need to re-key all signed certificates? Can we run with two root CAs until all certificates signed by the 2048 bits long one have been replaced?
Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux 7.7
How reproducible:
every RHEL 7.x Idm installation has key length
Comment 4Florence Blanc-Renaud
2020-08-31 08:00:08 UTC
Hi,
can you provide additional details regarding the customer's setup:
1. Is IdM deployed with an embedded CA or with 3rd part certificates?
2. If using IdM with an embedded CA, is it a self-signed CA or an externally signed CA?
Please be aware that it is not currently possible to re-key an external CA (see https://bugzilla.redhat.com/show_bug.cgi?id=1512322).
Comment 5Florence Blanc-Renaud
2020-08-31 08:01:24 UTC
Thank you taking your time and submitting this request for Red Hat Enterprise Linux 7. Unfortunately, this RFE cannot be kept even as a stretch goal and is moved to RHEL8 for proper evaluation.
Comment 6Abhinay Reddy Peddireddy
2020-09-03 09:44:07 UTC
(In reply to Florence Blanc-Renaud from comment #4)
> Hi,
>
> can you provide additional details regarding the customer's setup:
> 1. Is IdM deployed with an embedded CA or with 3rd part certificates?
> 2. If using IdM with an embedded CA, is it a self-signed CA or an externally
> signed CA?
>
> Please be aware that it is not currently possible to re-key an external CA
> (see https://bugzilla.redhat.com/show_bug.cgi?id=1512322).
The CA is embedded, and self-signed.
Thanks
it may depend on the use case, there may be a solution with the existing IPA tools if the IPA certs are only used for the replicas and for internal services ( not by IPA clients, no hosts, no services, no users with certs)
Otherwise, IPA CA re-keying is currently not supported, because it is more than expanding a CA signing cert validity, changing the private key changes everything, it is a configuration re-start from scratch, then have to re-issue all existing deployed valid certs to replace the no longer valid ones, there is no workaround when breaking a trust chain at the root.
some ideas/notes:
- if there is a CA re-key, we need to populate the new trust and maintain the old one until all the existing valid certs are updated into the IPA clients and apps
- expand ipa-certupdate for rekey and have a renewal mechanism of all existing valid certs, along with an update feature to allow IPA clients (and some apps?) to pick and install new certs?
- have a root CA with 4K key, then use subordinates.
- have less clones of the same CA everywhere?
- the concept of IPA CA signing cert life cycle?
- have some current valid CA's stop issuing certs some month before expiration, generating CRLs until they phase out (retired CA), and having new replica with new CAs (different cubject DNs) issuing new certs?
- may be have AIA extension with multiple records to point to several URI / CRLs and/or OCSP responders, several CRL distributions points ( a CA signing cert could be re-issued to add/update AIAs or CRL DPs)?
- could be IPA CAs for users or for hosts and services, or by location?
- managing different IPA CAs even as cross CAs would add integration complexity, new problems
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. It was unfortunately not given priority Red Hat Enterprise Linux.
Given that this request is not planned for a close release, it is highly unlikely it will be fixed in this major version of Red Hat Enterprise Linux. We are therefore closing the request as WONTFIX.
To request that Red Hat reconsiders the decision, please reopen the Bugzilla with the help of Red Hat Customer Service and provide additional business and/or technical details about it's importance to you.