Upgrading the signing algorithms of existing policy servers

Internally Security Access Manager uses X509 certificates to handle authentication of the communication channel between the various Security Access Manager servers. You can run certain CLI commands to force the generation of new X509 certificates.

Before you begin

Make sure that your environment meets the following conditions.

  • All appliances and any external PD.jar API applications must be updated to version 9.0.2.1 before you use this upgrade feature. Older versions are not supported and they will permanently lose contact with the policy server after it has been updated with a new certificate.
  • The time and date on all servers should be synchronized so that the not before and not after attributes of the new certificates are accurate.

Procedure

  1. Use the following CLI commands in order.
    1. isam -> ca -> new

      This command must be the first command to run. Use this command on the appliance that is running the policy server. It creates a new CA certificate in the policy server key file. The policy server keeps the original CA certificate in its key file and continues to use its original server certificate to accept connections from Security Access Manager servers that have not been updated.

      The policy server will be automatically restarted by this command.

    2. isam -> ca -> update

      This command imports the new CA certificate to all Security Access Manager related key files on the appliance. It also forces all Security Access Manager servers to request a new server certificate from the policy server. If the policy server is on the same appliance, this command also updates the server certificate of the policy server. Each Security Access Manager server will start to use the new server certificate, but will also retain the original CA certificate in its key file so that it can continue to connect to the policy server until the server certificate of the policy server is also updated.

      This command must be used after you execute the command in the previous step to generate the new CA certificate and the command must be run on all appliances that are configured to use the policy server. The appliance that is running the policy server must be the last appliance on which this command is run. This is because when the policy server has a new personal certificate, clients that do not have the new CA certificate will fail to connect to it. The policy server must be running for this command to work.

      In a scenario where a policy server is configured on a machine that is not in a cluster and a cluster is using that non-cluster policy server, then the cluster primary node must be the first node among the cluster nodes to run the "update" command.

      All Security Access Manager servers on the appliance on which this command is run will be automatically restarted.

    3. isam -> ca -> deprecate

      This command must be used after you execute the command from the previous step to update the Security Access Manager CA certificates of all appliances. This command removes the original CA certificate from all Security Access Manager key files on the appliance. This command is to be used after all appliances have had their Security Access Manager CA certificate updated.

      All Security Access Manager servers on the appliance on which this command is run will be automatically restarted.

    If a cluster of appliances is configured to replicate the runtime, then after step a, the subsequent step b might have to be delayed until the update on the primary node is replicated to the node that is running the “update” command. A new command isam → ca → replicated is provided for administrators to detect when the replication has occurred.

  2. If a system missed running the "update" operation before the “update” and "deprecate" operation were run on the policy server, use the following commands to allow the system to reconnect with the policy server.
    1. isam -> ca -> add-old

      This command adds the original CA certificate into the policy server key file so that Security Access Manager servers using server certificates that are signed by the original CA certificate can be accepted by the policy server. The policy server will be restarted by this command.

    2. isam -> ca -> remove-old

      This command removes and saves the original CA certificate from the policy server key file. The policy server will be restarted by this command.

    Use these commands in the following sequence:

    1. On the policy server appliance, run the command isam -> ca -> add-old.
    2. On the appliances that need to be recovered, run the isam -> ca -> update and isam -> ca -> deprecate commands.
    3. On the policy server appliance, run the command isam -> ca -> remove-old.

    Example scenarios:

    1. The environment consists of a cluster of two appliances. The policy server is running on the primary master and the runtime data is being replicated to the cluster. An additional appliance, which is not a member of the cluster, also has a Web Reverse Proxy instance configured against the policy server.

      Table 1. Scenario 1
      Step Primary (policy server) node Secondary node Non-cluster node
      1 new    
      2   update update
      3 update    
      4   deprecate deprecate
      5 deprecate    
    2. The environment consists of a cluster of two appliance that are configured to replicate the runtime. The Web Reverse Proxy instances on these two appliances are configured against a policy server that is running on an appliance that is external to the cluster.

      Table 2. Scenario 2
      Step Primary node Secondary node Non-cluster node (policy server)
      1     new
      2 update (before other cluster nodes)    
      3   update  
      4     update
      5   deprecate  
      6 deprecate (after other cluster nodes)    
      7     deprecate