Verifying client and server certificates

To provide an extra level of security, you can store server or client certificates in a custom keystore, explicitly include or exclude known certificates in the keystore, or both.

Configure client and server certificates for the External S-TAP

In this scenario, you want to use the External S-TAP custom keystore verify that the External S-TAP communicates only with trusted clients and servers.

  1. Configure the External S-TAP to trust your data store server certificate, you need the one of the following certificates:
    • The signed certificate from your data store server, along with the token that was provided to create the certificate signing request (CSR). In this case, use the following CLI command to store the signed certificate in a custom keystore on the External S-TAP:
      store certificate custom_keystore_external_stap
      When prompted, supply the following information:
      • The alias for the signed certificate, which was included in the CSR output file.
      • The token that was provided to create the CSR.
    • A self-signed certificate from your data store server. In this case, you can store the certificate directly into the allowlist, as described in Certificate allowlists and blocklists.
  2. Configure the data store client to trust the External S-TAP certificate, by taking one or both of the following steps:
    • If the client can accept a trusted certificate, then store the signed External S-TAP certificate on the client data store.
    • If the client can trust a certificate based on allowlist, you can also store the External S-TAP directly.
    Note: If your site is using PostgreSQL for both the client and server data stores, you can additionally configure the server to trust the External S-TAP certificate to create a mutual authentication scenario. For more information, see Configuring mutual authentication.

Certificate allowlists and blocklists

In addition to using certificates to verify communication with the External S-TAP, you can use allowlists and blocklists to explicitly define which certificates your site can, or cannot, trust. The lists are stored in the custom keystore.

You can add one or more certificates to an allowlist to explicitly trust the certificates on a client or server machine. In addition, you can explicitly exclude, by using a blocklist, certificates that you know can no longer be trusted.
Note: Certificates can be added only one at a time.
Use the following CLI command to add a certificate to a trusted list (an allowlist):
store certificate allowlist_external_stap

Use the following CLI command to explicitly exclude a certificate (a blocklist):

store certificate blocklist_external_stap
When you add a certificate to either an allowlist or a blocklist, you are prompted for the following information:
  • The alias for the signed certificate, which was included in the CSR output file.
  • The token that was provided to create the CSR for the External S-TAP certificate.
Note: For an added level of security, you can optionally use the certificate that you created to verify the collector's certificate. For more information, see Verify collector certificates (optional).

Other certificate CLI commands

To delete one or more certificates from the keystore, use the following CLI command:
delete certificate external_stap

A numbered list of all of the certificates in the keystore displays. Select the certificates to delete, by their number. To delete multiple certificates, separate each number with a comma.

To show details about the certificates in the keystore, use the following CLI command:
show certificate external_stap

For each certificate, useful information such as alias name, entry type, owner, and valid dates displays.

For more information about certificate-related CLI commands, see Certificate CLI commands.

Note: To determine the actions to take when Guardium encounters an invalid certificate, set the actions in either the External S-TAP tab or the deployment script. For more information, see External S-TAP tab or the --invalid-cert-disconnect and --invalid-cert-notify parameters in Table 3.