Fortinet white logo
Fortinet white logo

WAF Solutions against OWASP Top 10 Risks

7.6.3

Validating the client's certificate to secure sensitive transactions

Validating the client's certificate to secure sensitive transactions

In the previous scenario "Scenario 1- Implementing HTTPS to protect sensitive data in transmission," we discussed that in order to facilitate HTTPS connections, the server/FortiWeb is required to present an SSL certificate to the client to prove the website's identity.

In high-security scenarios, such as online banking platforms, it is crucial to validate the identity in both directions. This is achieved through Mutual Authentication, where the server asks the client to present a client certificate to authenticate its identity before the server sends sensitive data in its response. Mutual Authentication ensures that both the client and the server authenticate each other, providing a higher level of security compared to server-only authentication.

A typical use case of the client certificate is that to access certain data in the online banking system, the bank may issue their customer a hardware device (e.g., smart card or USB token) which stores a digital certificate. To log in to the banking system, the customer needs to connect the smart card or USB token to their computer, configure their web browser to recognize and use the certificate stored on the hardware device to authenticate the their identity to the banking system.

The process of mutual authentication is shown as above:

  1. Client connects to the FortiWeb to initiate an SSL connection.
  2. FortiWeb presents its server certificate to the client. The client authenticates the server certificate from its truststore and can verify the hostname (Optional).
  3. Client presents its client certificate to FortiWeb. FortiWeb authenticates the client certificate.
  4. Symmetric session keys are created, and an SSL connection gets established. The client and FortiWeb exchange information in a secure connection.

Solutions by FortiWeb

FortiWeb provides the following features for client certificate verification:

Uploading CA certificate to validate the client certificate

To verify the authenticity and integrity of the client certificate, FortiWeb should possess the CA certificate that signed the client certificate. FortiWeb will use the CA certificate’s public key to verify the digital signature on the client certificate. If the client certificate was not signed by the corresponding private key of the CA certificate present on FortiWeb, the verification will fail.

The CA certificate used for client certificate verification should be uploaded through Server Objects > Certificates > CA.

The CA group should be referenced in Certificate Verification for HTTPS when you create a server policy.

Restricting client certificate verification to certain URLs

Taking the online banking system as an example, instead of always requiring a client certificate to access the system, you can leverage FortiWeb's "URL based client certificate verification" feature to implement multiple security layers. Client certificate verification is required only for sensitive areas such as money transfers, while the rest part of the websites requires an easier authentication method such as username and password. This approach ensures the security of sensitive data while allowing easier access to general areas.

Configure the following settings to implement URL based client certificate verification:

  1. In Server Objects > Certificates > URL Certificate, specify the URLs for which you would like to implement client certificate verification.
  2. In a server policy, first configure Certificate Verification for HTTPS, then switch on Enable URL Based Client Certificate to select the URLs you have specified in Server Objects > Certificates > URL Certificate. In this way, the client certificate verification will be implemented only on the specified URLs.

Configuring FortiWeb to pass the client information to the back-end server

When FortiWeb acts as an SSL proxy on behalf of back-end servers, it handles the SSL handshake, client certificate verification, and other SSL-related tasks, making these processes invisible to the back-end servers. Once FortiWeb finishes processing the SSL connection with the client, it terminates the SSL connection and establishes a new connection to the back-end servers to forward the traffic. The client’s identifiers and attributes such as email address, DNS names and IP addresses specified in the client certificate will not be conveyed in the traffic to back-end servers. This may lead to issues if the back-end servers rely on specific client certificate information for access control and other purposes.

To address this, FortiWeb can create a client certificate proxy and resign a new certificate with the relevant client information when forwarding traffic to the back-end servers. This ensures that the client’s identity and attributes are preserved and recognized by the back-end servers.

Workflow Overview
  • Client Requests Access:

    The client presents its certificate to FortiWeb. FortiWeb uses the CA certificates you have uploaded in Server Objects > Certificates > CA to validate the client certificate.

  • FortiWeb Collects Client Details:

    FortiWeb collects the client’s details (such as subject name and extensions) from the client certificate.

  • Create CSR:

    FortiWeb uses the client's details and public key to create a Certificate Signing Request (CSR). You don't need to initiate the CSR request. FortiWeb will complete the process automatically.

  • Sign CSR with Sign CA:

    FortiWeb uses the Sign CA you have uploaded in Server Objects > Certificates > Sign CA to sign the CSR, generating a new client certificate.
    The Sign CA is typically an Intermediate CA whose certificate is issued by a Root CA. This setup allows the Intermediate CA to operate as a trusted entity within the Public Key Infrastructure (PKI) and grants it the authority to issue client certificates.

  • Present Client Certificate to Back-end Server:

    FortiWeb presents the dynamically generated client certificate to the back-end server. This requires you to enable Client Certificate Proxy in the server pool rule.

Configure the following settings on FortiWeb:

  1. Upload the CA certificate to Server Objects > Certificates > Sign CA.

  2. In a Server Pool Rule, enable SSL, then click Advanced SSL Settings. In the pop-up window, enable Client Certificate Proxy and then select the Sign CA you have uploaded. FortiWeb will resign a new client certificate with the relevant client information when forwarding traffic to the back-end server.

Maintaining a Certificate Revocation List (CRL) to exclude invalid client certificates

The client certificate has its scheduled expiration date. In some cases it might be revoked before its expiration date for various reasons such as:

  • The certificate's private key has been compromised.

  • The certificate was issued to a user or entity no longer authorized to use it.

  • The details in the certificate have changed and are no longer valid.

To ensure security, FortiWeb must be aware of revoked client certificates so that it can reject access requests when these certificates are presented. This is achieved through the use of a Certificate Revocation List (CRL). A CRL file contains a list of the revoked client certificates.

To ensure that FortiWeb validates only certificates that have not been revoked, you should periodically upload the most current CRL list.

In Server Objects > Certificates > CRL, you can upload a CRL file from your local directory, or enter the URL of the HTTP or SCEP server from which FortiWeb can retrieve the CRL file.

The CRL can be referenced in a certificate verification rule along with the CA group which contains the CA certificate that validates client certificates.

Validating the client's certificate to secure sensitive transactions

Validating the client's certificate to secure sensitive transactions

In the previous scenario "Scenario 1- Implementing HTTPS to protect sensitive data in transmission," we discussed that in order to facilitate HTTPS connections, the server/FortiWeb is required to present an SSL certificate to the client to prove the website's identity.

In high-security scenarios, such as online banking platforms, it is crucial to validate the identity in both directions. This is achieved through Mutual Authentication, where the server asks the client to present a client certificate to authenticate its identity before the server sends sensitive data in its response. Mutual Authentication ensures that both the client and the server authenticate each other, providing a higher level of security compared to server-only authentication.

A typical use case of the client certificate is that to access certain data in the online banking system, the bank may issue their customer a hardware device (e.g., smart card or USB token) which stores a digital certificate. To log in to the banking system, the customer needs to connect the smart card or USB token to their computer, configure their web browser to recognize and use the certificate stored on the hardware device to authenticate the their identity to the banking system.

The process of mutual authentication is shown as above:

  1. Client connects to the FortiWeb to initiate an SSL connection.
  2. FortiWeb presents its server certificate to the client. The client authenticates the server certificate from its truststore and can verify the hostname (Optional).
  3. Client presents its client certificate to FortiWeb. FortiWeb authenticates the client certificate.
  4. Symmetric session keys are created, and an SSL connection gets established. The client and FortiWeb exchange information in a secure connection.

Solutions by FortiWeb

FortiWeb provides the following features for client certificate verification:

Uploading CA certificate to validate the client certificate

To verify the authenticity and integrity of the client certificate, FortiWeb should possess the CA certificate that signed the client certificate. FortiWeb will use the CA certificate’s public key to verify the digital signature on the client certificate. If the client certificate was not signed by the corresponding private key of the CA certificate present on FortiWeb, the verification will fail.

The CA certificate used for client certificate verification should be uploaded through Server Objects > Certificates > CA.

The CA group should be referenced in Certificate Verification for HTTPS when you create a server policy.

Restricting client certificate verification to certain URLs

Taking the online banking system as an example, instead of always requiring a client certificate to access the system, you can leverage FortiWeb's "URL based client certificate verification" feature to implement multiple security layers. Client certificate verification is required only for sensitive areas such as money transfers, while the rest part of the websites requires an easier authentication method such as username and password. This approach ensures the security of sensitive data while allowing easier access to general areas.

Configure the following settings to implement URL based client certificate verification:

  1. In Server Objects > Certificates > URL Certificate, specify the URLs for which you would like to implement client certificate verification.
  2. In a server policy, first configure Certificate Verification for HTTPS, then switch on Enable URL Based Client Certificate to select the URLs you have specified in Server Objects > Certificates > URL Certificate. In this way, the client certificate verification will be implemented only on the specified URLs.

Configuring FortiWeb to pass the client information to the back-end server

When FortiWeb acts as an SSL proxy on behalf of back-end servers, it handles the SSL handshake, client certificate verification, and other SSL-related tasks, making these processes invisible to the back-end servers. Once FortiWeb finishes processing the SSL connection with the client, it terminates the SSL connection and establishes a new connection to the back-end servers to forward the traffic. The client’s identifiers and attributes such as email address, DNS names and IP addresses specified in the client certificate will not be conveyed in the traffic to back-end servers. This may lead to issues if the back-end servers rely on specific client certificate information for access control and other purposes.

To address this, FortiWeb can create a client certificate proxy and resign a new certificate with the relevant client information when forwarding traffic to the back-end servers. This ensures that the client’s identity and attributes are preserved and recognized by the back-end servers.

Workflow Overview
  • Client Requests Access:

    The client presents its certificate to FortiWeb. FortiWeb uses the CA certificates you have uploaded in Server Objects > Certificates > CA to validate the client certificate.

  • FortiWeb Collects Client Details:

    FortiWeb collects the client’s details (such as subject name and extensions) from the client certificate.

  • Create CSR:

    FortiWeb uses the client's details and public key to create a Certificate Signing Request (CSR). You don't need to initiate the CSR request. FortiWeb will complete the process automatically.

  • Sign CSR with Sign CA:

    FortiWeb uses the Sign CA you have uploaded in Server Objects > Certificates > Sign CA to sign the CSR, generating a new client certificate.
    The Sign CA is typically an Intermediate CA whose certificate is issued by a Root CA. This setup allows the Intermediate CA to operate as a trusted entity within the Public Key Infrastructure (PKI) and grants it the authority to issue client certificates.

  • Present Client Certificate to Back-end Server:

    FortiWeb presents the dynamically generated client certificate to the back-end server. This requires you to enable Client Certificate Proxy in the server pool rule.

Configure the following settings on FortiWeb:

  1. Upload the CA certificate to Server Objects > Certificates > Sign CA.

  2. In a Server Pool Rule, enable SSL, then click Advanced SSL Settings. In the pop-up window, enable Client Certificate Proxy and then select the Sign CA you have uploaded. FortiWeb will resign a new client certificate with the relevant client information when forwarding traffic to the back-end server.

Maintaining a Certificate Revocation List (CRL) to exclude invalid client certificates

The client certificate has its scheduled expiration date. In some cases it might be revoked before its expiration date for various reasons such as:

  • The certificate's private key has been compromised.

  • The certificate was issued to a user or entity no longer authorized to use it.

  • The details in the certificate have changed and are no longer valid.

To ensure security, FortiWeb must be aware of revoked client certificates so that it can reject access requests when these certificates are presented. This is achieved through the use of a Certificate Revocation List (CRL). A CRL file contains a list of the revoked client certificates.

To ensure that FortiWeb validates only certificates that have not been revoked, you should periodically upload the most current CRL list.

In Server Objects > Certificates > CRL, you can upload a CRL file from your local directory, or enter the URL of the HTTP or SCEP server from which FortiWeb can retrieve the CRL file.

The CRL can be referenced in a certificate verification rule along with the CA group which contains the CA certificate that validates client certificates.