KRA Connector - dogtagpki/pki GitHub Wiki
When a KRA is installed, it calls the updateConnector servlet on the CA (i.e. /ca/admin/ca/updateConnector) with the following parameters:
ca.connector.KRA.enable=true ca.connector.KRA.local=false ca.connector.KRA.timeout=30 ca.connector.KRA.uri=/kra/agent/kra/connector ca.connector.KRA.host=<ownagenthost> ca.connector.KRA.port=<ownagentsport> ca.connector.KRA.transportCert=<transportCert>
These are the parameters that are stored in the CA’s CS.cfg when a connector is defined. The UpdateConnector servlet fist checks to see if the connector is already defined. If not, then it stores these values in the CS.cfg, starts the connector, and sends back success. If the connector is already defined, it returns FAILURE.
This is of course a problem in current installs. We can install a KRA and then remove it - but the connector config still exists on the CA, preventing another KRA being configured to the same CA. We therefore should provide a mechanism for removing the KRA connector info when pkidestory is called on the KRA.
Simply removing the KRA connector info is not sufficient though. It is possible to configure the CA to have failover between multiple cloned KRAs. All the KRAs must use the same transport cert. In this case, ca.connector.KRA.host can be multiply defined and have any of the following:
ca.connector.KRA.host = kra_vip (port defined in ca.connector.KRA.port ) ca.connector.KRA.host = host1:port1 host2:port2 etc. (in this case, the value in ca.connector.KRA.port is ignored, except in log messages)
We’ll define a new restful servlet to manage connector info at /config/connector (com.netscape.certsrv.system.ConnectorResource.java)
This servlet will require token authentication. Or we might just extend the current UpdateConnector servlet (and add an add/remove operation).
-
Requires
host,portas inputs. -
If
connectornot defined, returnSUCCESS. -
If
connector.KRA.host=hostandconnector.KRA.port=port, then remove all entries and returnSUCCESS.If thevip_hostandvip_portare passed in, then this would take care of that scenario. -
If
connector.KRA.host=host:port host2:port2, then removehost:portfrom the list and returnSUCCESS. Ifhost:portis not in the list returnSUCCESS.
-
Requires all the info above (including
host,port,transportCert) -
If
connectornot defined, add the connector info, start the connector and returnSUCCESS. -
If
connector.KRA.host=hostandconnector.KRA.port=port, then overwrite the connector parameters and returnSUCCESS. -
If
connector.KRA.transportCert!=transportCert, returnFAILURE(Connector already defined) -
If
connector.KRA.hostis not a list, then eitherconnector.KRA.hostorconnector.KRA.portare different from the passed inhostandport. Changeconnector.KRA.hostto a list ofhost:port. ReturnSUCCESS. -
If
connector.KRA.hostis a list, check to see ifhost:portis in the list. If not, add it. ReturnSUCCESS.
Add parameters to allow user to specify the connector host and port. This will allow specification of a VIP if desired.
[KRA] pki_kra_connector_host=%(pki_hostname)s pki_kra_connector_port=%(pki_https_port)s
SystemConfig servlet must of course be modified to use these new parameters. At the end of the installation, we should store these parameters in the KRA’s CS.cfg for use by pkidestroy. Store as: kra.connector.host, kra.connector.port
-
New optional parameter added to
pkidestroy --remove-kra-connector-vip(defaultfalse) -
If
--remove-kra-connector-vipistrue, readkra.connector.host,kra.connector.portfrom CS.cfg, and send those parameters in to the remove connector servlet. This will remove the vip config. -
Otherwise, send in
host,portto the remove connector servlet.