Internally Security Verify Access uses X509 certificates to handle
authentication of the communication channel between the various Security Verify Access 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
-
Use the following CLI commands in order.
- 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 Verify Access
servers that have not been updated.
The policy server will be automatically
restarted by this command.
- isam -> ca -> update
This
command imports the new CA certificate to all Security Verify Access related key files on the
appliance. It also forces all Security Verify Access 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 Verify Access 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 Verify Access servers on the appliance on
which this command is run will be automatically restarted.
- isam -> ca -> deprecate
This command must be used after you execute the command from the previous step to update the
Security Verify Access CA certificates of
all appliances. This command removes the original CA certificate from all Security Verify Access key files on the appliance.
This command is to be used after all appliances have had their Security Verify Access CA certificate updated.
All Security Verify Access
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.
-
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.
- isam -> ca -> add-old
This command adds
the original CA certificate into the policy server key file so that Security Verify Access 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.
- 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:
- On the policy server appliance, run the command isam -> ca ->
add-old.
- On the appliances that need to be recovered, run the isam -> ca -> update and isam -> ca -> deprecate
commands.
- On the policy server appliance, run the command isam -> ca ->
remove-old.
Example scenarios:
-
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 |
|
|
-
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 |