-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for the PKI v2 REST API + fall back #7587
base: master
Are you sure you want to change the base?
Conversation
6be468c
to
7fa5271
Compare
The failed tests are due to a change in PKI related with "AttributeError: 'cryptography.hazmat.bindings._rust.x509.Certificate' object has no attribute 'not_valid_before_utc'" This change was made due to deprecation warnings in python-cryptography. The PKI team is going to revert this change for now and will work on a fix that is forward and backwards compatible. |
I did some additional testing including testing forwarding CA requests to a remote CA of a different version. The changes include:
Upstream PKI has fixed the UTC issue. Re-testing this patch. |
There is a new bug in PKI causing the installation to fail. |
PKI has a plan to re-implement REST APIs using different libraries and supporting only JSON format. The new APIs have a different path, /v2, and when ready the current implementation will be deprecated. These APIs will not be back-ported to other branches and for the moment the APIs will not be for external use but the CLI will be progressively migrated to the new API endpoints so these have to be accessible. For reference: https://github.com/dogtagpki/pki/wiki/CA-REST-API-v2 Related: https://pagure.io/freeipa/issue/9695
The v2 API avoids using VLV so will not have performance issues with the 389 lmdb backend. This adds a new configuration option, ca_url_base, which defines the list of URI prefixes to try on the local or remote CA. On a 404 or 405 the code will failover to the next prefix until either there is a successful invocation or they all fail. The worst-case scenario is trying to retrieve a certificate that does not exist. It will attempt on all prefixes until it fails. It might be nice to have a global list of all CA's and their versions so we can cache the prefix but IPA tries to avoid global variables despite already no being thread-safe. Fixes: https://pagure.io/freeipa/issue/9695 Signed-off-by: Rob Crittenden <[email protected]>
The existence of directory /root/.dogtag/pki-tomcat/ca was causing TestExternalCAProfileScenarios to fail while testing the REST API v2 change in https://pagure.io/freeipa/issue/9695 Related: https://pagure.io/freeipa/issue/8080 Related: https://pagure.io/freeipa/issue/9695 Signed-off-by: Rob Crittenden <[email protected]>
Note that the KRA interface uses the pki-provided KRAClient class which is currently hardcoded at v1. I haven't yet investigated what to do about that such that it is forwards and backwards compatible. |
Endi created an abstraction layer in PKI for the REST versions in PR dogtagpki/pki#4900 |
This PR is mostly for verifying that fallover works when trying to contact a PKI API. It will use the v1/rest endpoints because v2 isn't available in Fedora yet. I will test with a temp commit at some point using the dogtag nightlies.
For now this is looking for regressions.
I haven't touch the KRA at all yet.