Move to v2 APIs

[fmarco76]

With this PR the default API (with /rest path) will be v2 and all the pki CLI will use this version.

Current API are still available but the path will be /<pki_subsystem>/v1/<path>.
In order to revert default to v1 it is possible to modify the file /usr/share/pki/server/conf/Catalina/localhost/rewrite.config linked from all the instances or the file link /etc/pki/<pki-instance>/Catalina/localhost/rewrite.config for a single instance.

[fmarco76]

@rcritten @flo-renaud after we merge this PR, IPA should modify the file as in the description, or the httpd proxy configuration, to continue with current API, which will be available until you have switched to the new API.
Currently they implement the same endpoint but they support only JSON format.

[edewata]

@fmarco76 The changes look fine, but does it mean that IPA tests (in PKI CI and IPA CI) will fail until IPA is updated to use /v1 instead of /rest? Or should IPA be updated first before merging this PR?

[fmarco76]

@fmarco76 The changes look fine, but does it mean that IPA tests (in PKI CI and IPA CI) will fail until IPA is updated to use /v1 instead of /rest? Or should IPA be updated first before merging this PR?

Yes, we have to wait IPA to modify the deploy in order to continue using the current API version.

[edewata]

@fmarco76 Could you rebase this PR? The latest IPA tests will show the access logs so we can find out which operation in IPA is actually failing. Note that the basic CA tests might fail because of the API tests we just added, but we can ignore that for now.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
10.5% Duplication on New Code

See analysis details on SonarCloud

[fmarco76]

Note that the basic CA tests might fail because of the API tests we just added, but we can ignore that for now.

Yes, there are also some new failures because we added enrollment using XML and it is not supported.

[edewata]

Yes, there are also some new failures because we added enrollment using XML and it is not supported.

Thanks for the rebase! Unfortunately the Tomcat & HTTPD access logs don't show the failed operation, maybe because it's buffered so it's not written yet, or maybe because IPA was expecting an XML response but it got a JSON response. We need to find out which code is failing so we can figure out the most efficient way to fix it.

@rcritten @flo-renaud Any suggestion how to find the failing code in IPA?

[rcritten]

Basic IPA test
test_xmlrpc/test_caacl_profile_enforcement.py::TestCertSignMIME::test_sign_smime_csr
ipalib.errors.InternalError: an internal error has occurred

There should be a traceback in the Apache log for this.

IPA KRA
test_vault_plugin.test_command[0000: vault_add: Create private vault
Invalid key archival request. Bad algorithm.

This error is returned by the API so it originated in PKI. Did the allowed algorithms change?

IPA with Sub-CA
Request failed with status 500: Non-2xx response from CA REST API: 500.

The ca/debug log should have information on this.

Apache doesn't buffer its logs so I don't know why you aren't seeing output there. I don't know whether PKI/tomcat does log buffering or not.

[rcritten]

I saw failures in the IPA xmlrpc tests which are not being executed here. The issue is in the ca retrieval tests if we ask for the full chain it fails that application/pkcs7-mime is not an acceptable type.