Ok, so I think the correct way to move forward on this is to use the same subsystem certificate in each subsystem in a shared instance.

Before explaining how this will work, let me explain how we currently use subsystem certs. Subsystem certs are currently used in two ways:

• They are used as authentication when one PKI subsystem talks to another. This is for system → system communications like the CA talking to the KRA through the KRA connector, or the TPS talking to the CA, TKS or KRA.

• They are used to authenticate the pkidbuser, which is created at server configuration and can be used to communicate securely with a LDAP database using client auth. This is actually used by IPA.

The exact details of what happens during configuration is as follows:

• A subsystem certificate is generated for each subsystem.

• When needed, a user is created on the target subsystem to facilitate inter-subsystem communications. So, for example, when the KRA is configured, a user is created on the KRA (i.e. uid=CA-<hostname>-<port>,ou=people,<KRA base DN>), which contains the CA subsystem certificate. The CA presents this certificate when initiating communication with the KRA.

• A user is created to communicate with the database. This user uid=pkidbuser,ou=people,<base DN> contains the subsystem cert and also has an attribute seeAlso, which contains the subject DN of the certificate. This attribute is important. When the database is configured, it is expected that certmap.conf will be configured to check this attribute when matching the cert presented by the client.

The ticket describes the problems that occur when Tomcat instances/databases are shared.

The basic outline of the proposed solution is as follows:

• When a new subsystem is created, a system user will be created using the subsystem cert.

• If the subsystems share a Tomcat instance, then they will use the same subsystem certificate.

• If the subsystems share the same Tomcat instance and share the same database, then only one user will have the seeAlso attribute.

The details are in the cases below:

• The CA is configured. A system user is created uid=pkiSystemUser,ou=people,<CA base DN> with the CA subsystem certificate and the seeAlso attribute. This user can be used to communicate with the database.

• The TPS is configured. In the configuration we specify:

  • shared_tomcat_instance=True

  • shared_db=True

  • subsystem_cert_subject_dn=<ca subsystem cert subject dn>

  • subsystem_cert_nick=<ca subsystem cert nick>

  • uid of CA dbuser → uid=pkiSystemUser,ou=people,<CA base DN>

• During TPS configuration,

  • A new subsystem cert is not created, instead the nicks/entries in CS.cfg are obtained from the provided subsystem_nick

  • We call registerUser on the CA and provide a new query parameter: generateUser=False. As before, we pass in the subsystem cert.

  • On the CA, the relevant system user is looked up from the cert, and is added to the relevant agent groups.

  • We create a new user uid=pkiSystemUser,ou=people,<TPS base DN> with the provided subsystem cert retrieved from the specified nick. At this point, this user isn’t actually used for anything, but is there in case we ever need to initiate communications with the TPS.

  • The new user does not have the seeAlso attribute. Because the daetabase is shared, we expect that the database will resolve the CA dbuser when the subsystem cert is presented. We will ensure that the CA dbuser has the relevant ACLs to read the TPS entries.

• The CA is configured. A system user is created uid=pkiSystemUser,ou=people,<CA base DN> with the CA subsystem certificate and the seeAlso attribute. This user can be used to communicate with the database.

• The TPS is configured. In the configuration we specify:

  • shared_tomcat_instance=True

  • shared_db=False

  • subsystem_cert_subject_dn=<ca subsystem cert subject dn>

  • subsystem_cert_nick=<ca subsystem cert nick>

• During TPS configuration,

  • A new subsystem cert is not created, instead the nicks/entries in CS.cfg are obtained from the provided subsystem_nick

  • We call registerUser on the CA and provide a new query parameter: generateUser=False. As before, we pass in the subsystem cert.

  • On the CA, the relevant system user is looked up from the cert, and is added to the relevant agent groups.

  • We create a new user uid=pkiSystemUser,ou=people,<TPS base DN> with the provided subsystem cert retrieved from the specified nick. This user does have the seeAlso attribute so that it can be used to communicate with the database.

• The CA is configured. A system user is created uid=pkiSystemUser,ou=people,<CA base DN> with the CA subsystem certificate and the seeAlso attribute. This user can be used to communicate with the database.

• The TPS is configured. In the configuration we specify:

  • shared_tomcat_instance=False

  • shared_db=False

• During TPS configuration,

  • A new subsystem cert is created and the config is updated as normal.

  • We call registerUser on the CA and provide a new query parameter and pass in the subsystem cert. We will default generateUser to the previous behavior with is True.

  • On the CA, the new system user is added (with its cert) and is added to the relevant agent groups.

  • We create a new user uid=pkiSystemUser,ou=people,<TPS base DN> with the provided subsystem cert retrieved from the specified nickname. At this point, this user has the seeAlso attribute so it can be used to communicate with its database.