Configuring mutual authentication

If your database settings are configured for mutual authentication, you can configure the External S-TAP®, to verify the certificate that is set from both the data store server and client.

About this task

For the External S-TAP, Guardium supports mutual authentication through an External S-TAP custom keystore. In this scenario:
  1. The data store client successfully verifies the certificate in the External S-TAP custom keystore.
  2. The External S-TAP verifies the data store server certificate.
  3. If mutual authentication is enabled on both the client and the server, the client sends the client certificate to the External S-TAP. The External S-TAP parses that message and verifies the certificate on behalf of the server.
  4. If the client certificate is trusted, External S-TAP sends the External S-TAP certificate to the PostgreSQL server so that the PostgreSQL server can verify the certificate from the External S-TAPs.

To provide mutual authentication with multiple client certificates, you need to use certificate mirroring. For more information, see Configuring certificate mirroring.

Procedure

  1. To configure the External S-TAP to trust your data store client certificate, you need the CA-signed certificate (or certificates) from the client data store.
    Note: Make sure that all certificates (for the External S-TAP, the client, and the server) are signed by the same certificate authority.

    Use the following CLI command to store the signed client certificate into the External S-TAP custom keystore: 

    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 for the External S-TAP certificate.
  2. To verify a client certificate on a PostgreSQL server, import the External S-TAP certificate onto the server.
    Note: In some configurations, the server certificate is the default certificate, rather than a certificate signed by a trusted CA. In that case, you can add that certificate to an allowlist, which explicitly adds that certificate to the custom keystore, as described in Certificate allowlists and blocklists.

What to do next

If you know that a certificate can no longer be trusted, you can add it to a blocklist in the custom keystore. For more information, see Certificate allowlists and blocklists.