Relocate SSNv2 range objects for new CA instances #4885

edewata · 2024-10-24T16:07:38Z

pkispawn has been modified to create ou=ranges subtree for SSNv1 and optionally ou=ranges_v2 subtree for SSNv2 if it's enabled for new CA instances. The pki-server <subsystem>-db-init and <subsystem>-range-update commands have been updated to use the proper subtree to store the range objects. Hard-coded subtrees in the create.ldif have been removed.

Similar changes are made to KRA as well, but since there are no tests for KRA with SSNv2 it's not officially supported yet.

The test scripts have been updated to use ou=ranges_v2 subtree for SSNv2 range objects.

edewata · 2024-10-24T16:43:02Z

@fmarco76 For SSNv2 we could use it like this: edewata@4a85681

fmarco76 · 2024-10-24T17:50:58Z

base/server/python/pki/server/deployment/__init__.py

+            request_dn = self.mdict.get('pki_request_number_range_dn')
+            if request_dn:
+                subsystem.set_config('dbs.requestRangeDN', request_dn)
+


The dbs.requestRangeDNis assigned twice, here and on line 1188. Could we merge with something like:

request_dn = self.mdict.setdefault('pki_request_number_range_dn', 'ou=requests,ou=ranges') subsystem.set_config('dbs.requestRangeDN', request_dn)

and remove the one in line 1188 so it is assigned only once.

I decided not to add the pkispawn param for now due to complexity, so the subtree is always ou=ranges for SSNv1 and ou=ranges_v2 for SSNv2.

fmarco76 · 2024-10-24T17:51:51Z

base/server/python/pki/server/deployment/__init__.py

+            serial_dn = self.mdict.get('pki_serial_number_range_dn')
+            if serial_dn:
+                subsystem.set_config('dbs.serialRangeDN', serial_dn)
+


Same as above. (I think we could use the same for the other configuration here)

Please see above.

fmarco76 · 2024-10-24T17:53:57Z

base/server/src/main/java/org/dogtagpki/server/cli/SubsystemDBInitCLI.java

@@ -105,6 +109,21 @@ public void execute(CommandLine cmd) throws Exception {

            if (!cmd.hasOption("skip-containers")) {
                ldapConfigurator.createContainers(subsystem);
+
+                String requestRangeRDN = dbConfig.getRequestRangeDN();
+                if (!StringUtils.isEmpty(requestRangeRDN)) {


If the id generator is legacy or legacy2 should we throw an exception if this is not configured?

In the updated PR the param is guaranteed to exist in CA and KRA so it won't fail. The param will not exist in other subsystems so the code won't create the subtree.

fmarco76 · 2024-10-24T17:54:09Z

base/server/src/main/java/org/dogtagpki/server/cli/SubsystemDBInitCLI.java

+                }
+
+                String serialRangeRDN = dbConfig.getSerialRangeDN();
+                if (!StringUtils.isEmpty(serialRangeRDN)) {


Same as above

fmarco76 · 2024-10-24T18:04:13Z

@fmarco76 For SSNv2 we could use it like this: edewata@4a85681

Since the DS was configurable from the start it is OK to add the possibility to configure. To move the nextRange I am not sure yet.

edewata · 2024-10-26T01:53:05Z

@fmarco76 Thanks for the comments! I'll update this PR after PR #4886. I think we need to change the location of nextRange for SSNv2 so that if there's a problem with the migration the nextRange for SSNv1 is still intact.

fmarco76 · 2024-10-28T15:03:54Z

For SSNv2 we could use it like this: edewata@4a85681

With the new commit PR #4887 the current ranges tree is not modified so it is alwais possible to get the nextRange value for the legacy generator therefore I am wondering if it could be enough a procedure to revert the nextRange value. May be with the command:

# pki-server ca-id-generator-update --type legacy --revert cert

The option --revert means: do not do migration but just revert the value in CS.cfg and in nextRange using the range values and eventually some of the dbs.* values.

edewata · 2024-10-28T16:43:02Z

As mentioned in PR #4887 we are still modifying the same nextRange attribute used by SSNv1 which is replicated to all DS instances and it might create potential issues. I'd prefer we move that into the new ou=ranges_v2 subtree so we have a cleaner separation between SSNv1 and SSNv2. Once this is done, if we provide a revert functionality it will be just restoring the SSNv1 params in CS.cfg. However, if new certs have been issued with SSNv2 things could be more complicated. I'm not sure how SSNv1 code will handle that scenario. Worst case the new certs will need to be removed/revoked as well. See also the Recovery section for RSNv3: https://github.com/dogtagpki/pki/wiki/Configuring-CA-with-Random-Serial-Numbers-v3

fmarco76 · 2024-10-28T18:02:35Z

However, if new certs have been issued with SSNv2 things could be more complicated. I'm not sure how SSNv1 code will handle that scenario. Worst case the new certs will need to be removed/revoked as well. See also the Recovery section for RSNv3: https://github.com/dogtagpki/pki/wiki/Configuring-CA-with-Random-Serial-Numbers-v3

There should be no problem to move from ssnv1 to ssnv2 and going back. Certificates are serial and there is no overlap issue so the problem is to find the right values to avoid conflicts. In the worst case it is possible to read last serial released and start new range from that point. You could have a big gap but not issues.

To move the nextRange in a different location additional configuration parameters could be needed. It is weird that looking at the repository object the nextRange is not used and maintain a wrong value while the new repository for nextRange actually it is not a repository. Therefore, I am also looking at the possibility to store the nextRange in a different place (e.g. the description field is not used, could it be used?)

edewata · 2024-10-28T19:12:05Z

However, if new certs have been issued with SSNv2 things could be more complicated. I'm not sure how SSNv1 code will handle that scenario. Worst case the new certs will need to be removed/revoked as well. See also the Recovery section for RSNv3: https://github.com/dogtagpki/pki/wiki/Configuring-CA-with-Random-Serial-Numbers-v3

There should be no problem to move from ssnv1 to ssnv2 and going back. Certificates are serial and there is no overlap issue so the problem is to find the right values to avoid conflicts. In the worst case it is possible to read last serial released and start new range from that point. You could have a big gap but not issues.

Yes, it might work just fine, but since we do not have a test for this, we don't really know whether there's any unforeseen issues. It's better to minimize the risk as much as possible, especially since we will not be able to assist directly during the actual migration of production environment.

To move the nextRange in a different location additional configuration parameters could be needed. It is weird that looking at the repository object the nextRange is not used and maintain a wrong value while the new repository for nextRange actually it is not a repository. Therefore, I am also looking at the possibility to store the nextRange in a different place (e.g. the description field is not used, could it be used?)

In edewata@4a85681 I was actually trying to use repository object class for the ranges subtree so we can store the nextRange there. Let me update this PR to include that change.

edewata · 2024-10-31T05:11:20Z

@fmarco76 Sorry for the delay. Please see the updated PR. I've changed the code to create SSNv2 range objects in ou=ranges_v2 for new instances to match migrated instances. I dropped the pkispawn params for now and deferred moving the nextRange to a separate PR due to complexity. There are some failures in the CI but I think they are caused by recent changes in Fedora.

pkispawn has been modified to create ou=ranges subtree for SSNv1 and optionally ou=ranges_v2 subtree for SSNv2 if it's enabled for new CA instances. The pki-server <subsystem>-db-init and <subsystem>-range-update commands have been updated to use the proper subtree to store the range objects. Hard-coded subtrees in the create.ldif have been removed. Similar changes are made to KRA as well, but since there are no tests for KRA with SSNv2 it's not officially supported yet.

The test scripts have been updated to use ou=ranges_v2 subtree for SSNv2 range objects.

sonarqubecloud · 2024-10-31T06:16:39Z

Quality Gate passed

Issues
8 New issues
0 Accepted issues

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

See analysis details on SonarCloud

fmarco76

LGTM

edewata · 2024-10-31T15:19:44Z

@fmarco76 Thanks!

edewata requested a review from fmarco76 October 24, 2024 16:12

edewata mentioned this pull request Oct 24, 2024

New legacy id generator #4875

Merged

fmarco76 reviewed Oct 24, 2024

View reviewed changes

edewata force-pushed the sequential branch from a2db6f6 to a8771de Compare October 31, 2024 04:54

edewata changed the title ~~Add installation params for range DNs~~ Relocate SSNv2 range objects for new CA instances Oct 31, 2024

edewata added 2 commits October 31, 2024 00:18

Update test scripts for SSNv2

94fcf40

The test scripts have been updated to use ou=ranges_v2 subtree for SSNv2 range objects.

edewata force-pushed the sequential branch from a8771de to 94fcf40 Compare October 31, 2024 05:18

fmarco76 approved these changes Oct 31, 2024

View reviewed changes

edewata merged commit 830de10 into dogtagpki:master Oct 31, 2024
151 of 168 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Relocate SSNv2 range objects for new CA instances #4885

Relocate SSNv2 range objects for new CA instances #4885

edewata commented Oct 24, 2024 •

edited

Loading

edewata commented Oct 24, 2024

fmarco76 Oct 24, 2024

edewata Oct 31, 2024

fmarco76 Oct 24, 2024

edewata Oct 31, 2024

fmarco76 Oct 24, 2024

edewata Oct 31, 2024

fmarco76 Oct 24, 2024

fmarco76 commented Oct 24, 2024 •

edited

Loading

edewata commented Oct 26, 2024

fmarco76 commented Oct 28, 2024

edewata commented Oct 28, 2024

fmarco76 commented Oct 28, 2024 •

edited

Loading

edewata commented Oct 28, 2024

edewata commented Oct 31, 2024

sonarqubecloud bot commented Oct 31, 2024

fmarco76 left a comment

edewata commented Oct 31, 2024

Relocate SSNv2 range objects for new CA instances #4885

Relocate SSNv2 range objects for new CA instances #4885

Conversation

edewata commented Oct 24, 2024 • edited Loading

edewata commented Oct 24, 2024

fmarco76 Oct 24, 2024

Choose a reason for hiding this comment

edewata Oct 31, 2024

Choose a reason for hiding this comment

fmarco76 Oct 24, 2024

Choose a reason for hiding this comment

edewata Oct 31, 2024

Choose a reason for hiding this comment

fmarco76 Oct 24, 2024

Choose a reason for hiding this comment

edewata Oct 31, 2024

Choose a reason for hiding this comment

fmarco76 Oct 24, 2024

Choose a reason for hiding this comment

fmarco76 commented Oct 24, 2024 • edited Loading

edewata commented Oct 26, 2024

fmarco76 commented Oct 28, 2024

edewata commented Oct 28, 2024

fmarco76 commented Oct 28, 2024 • edited Loading

edewata commented Oct 28, 2024

edewata commented Oct 31, 2024

sonarqubecloud bot commented Oct 31, 2024

Quality Gate passed

fmarco76 left a comment

Choose a reason for hiding this comment

edewata commented Oct 31, 2024

edewata commented Oct 24, 2024 •

edited

Loading

fmarco76 commented Oct 24, 2024 •

edited

Loading

fmarco76 commented Oct 28, 2024 •

edited

Loading