How to apply PKI client authentication (personal certificates)

If your clients will connect to your websites using HTTPS, you can configure FortiWeb to require clients to present a personal certificate during the handshake in order to confirm their identities. This is sometimes called public key infrastructure (PKI) authentication (RFC 5280; http://www.ietf.org/rfc/rfc5280.txt).

Because FortiWeb presents its own server certificate to the client before requesting one from the client, all PKI authentication with FortiWeb is mutual (2-way) authentication.

In addition to FortiWeb verifying client certificates, you can configure FortiWeb to forward client certificates to the back-end server, whether for additional verification or identity-based functionality. See Configuring an HTTP server policy.

PKI authentication is an alternative to traditional password-based authentication. The traditional method is based on “what you know”—a password used for authentication. PKI authentication is based on “what you have”—a private key related to the certificate bound to only one person. PKI authentication may be preferable for devices where it is onerous for the person to type a password, such as smart phones or tablets.

A known weakness of traditional password based authentication is the vulnerability to password guessing or brute force attacks. Despite warnings, many users still choose weak passwords either because they do not understand what makes a password “strong,” because they do not understand the risks that it poses to the organization, or because they cannot remember a randomized password.

PKI authentication is far more resilient to brute force attacks, and does not require end-users to remember anything. This means that the security of PKI authentication is often stronger than traditional passwords.

For even stronger authentication, you can combine PKI authentication with HTTP or form-based authentication. For details, see Authentication styles.

Bilateral authentication

PKI authentication relies on sole private key possession and asymmetric encryption to confirm a user's identity.

Sole private key posession

The private key is a randomized string of text that has a hard-to-guess relationship with its corresponding public key. As such, it features cryptographic protection that passwords lack: passwords do not necessarily have a verifiable, computable relationship with anything. However, like a password, a private key’s strength depends on it remaining a secret.

Like with all X.509 certificates, a client’s identity can only be irrefutably confirmed if no one else except that person has that certificate’s private key.

Provide the client’s private keys only to that specific client, and transmit and store any backups securely, just as you would for passwords. Failure to store them securely and properly restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your websites.

In the event of potential private key compromise, immediately revoke the corresponding personal certificate. For details, see Revoking certificates.

Asymmetric encryption

Public key encryption is a type of asymmetric encryption: it is based upon two keys that are different—but exactly paired—mathematical complements.

Only the private key can decrypt data that was encrypted by its public key. The inverse is also true: only the public key can decrypt data that was encrypted by its private key. This is illustrated in the Rivest-Shamir-Adleman (RSA) cryptographic algorithm.

RSA algorithm:

During an SSL or TLS handshake, the client and FortiWeb negotiate which of their supported cryptographic algorithms to use, and exchange certificates. After the server receives the client’s certificate with its public key, the client encrypts subsequent communications using its private key. As a result, if the server can decrypt messages using the public key, it knows that they originate from the originally connecting client who has the related private key, not an intercepting host (e.g., a Man-in-the-Middle (MITM) attack).

Depending on factors such as a misconfigured client, an SSL/TLS connection may in some cases still be vulnerable to MITM attacks.

There are several steps that you can take to harden security, including using greater bit strengths, updating and properly configuring clients, revoking compromised certificates, and installing only trusted certificates. For details, see Hardening security and Configuring FortiWeb to validate client certificates.

Encrypted transmissions can contain a message authentication checksum (MAC) to verify that the message was not altered during transmission by an interceptor:

Digital signatures—Public keys are also used as signatures. Similar to an encrypted message, as long as the private key is possessed by only one individual, any signature generated from it is also guaranteed to come only from that client. The client will sign a certificate with its matching public key.

Because certificate authorities (CA) sign applicants’ certificates, third parties who have that CA’s certificate can also confirm that the CA certified the applicant’s identity, and the certificate was not forged.
Chain of trust—What if a device does not know the CA that signed the connecting party’s certificate? Since there are many CAs, this is a common scenario.

The solution is to have a root CA in common between the two connecting parties, a “friend of a friend.”

If a root CA is trusted to be genuine and to sign only certificates where it has verified the applicant’s identity, then by induction, all sub-CA certificates that the root CA has signed will also be trusted as genuine. Therefore, if a client or server’s certificate can prove that it is either indirectly (through an intermediary CA signed by the root CA) or directly signed by the trusted root CA, that client/server’s certificate will be trusted as genuine.

To configure client PKI authentication

Obtain a personal certificate for the client, and its private key, from a CA.

Steps vary by the CA. Personal certificates can be purchased or downloaded from either commercial CAs such as VeriSign, Thawte, or Comodo, or your organization’s own private CA, such as a Linux server where you use OpenSSL or a Mac OS X server where you have set up a CA in Keychain Access. For information on certificate requirements such as extended attributes, see Configuring FortiWeb to validate client certificates.

For a private CA example, see Example: Generating & downloading a personal certificate from Microsoft Windows 2003 Server.

Download the CA’s certificate, which contains its public key and therefore can verify any personal certificate that the CA has signed.

Steps vary by the CA.

For a private CA example, see Example: Downloading the CA’s certificate from Microsoft Windows 2003 Server.

If you purchased personal certificates from CAs such as VeriSign, Thawte, or Comodo, you should not need to download the certificate: simply export those CAs’ certificates from your browser’s own trust store, similar to To export and transmit a personal certificate from the trust store on Microsoft Windows 7, then upload them to FortiWeb. For details, see Uploading trusted CA certificates.

Install the personal certificate with its private key on the client.

Steps vary by the client’s operating system and web browser. If the client uses Microsoft Windows 7, see Example: Importing the personal certificate & private key to a client’s trust store on Microsoft Windows 7.

Upload the CA’s certificate to the FortiWeb’s trust store. For details, see Uploading the CA’s certificate to FortiWeb’s trusted CA store.
If you have a certificate revocation list, configure FortiWeb with it. For details, see Revoking certificates.
Depending on FortiWeb’s current operation mode, configure either a server policy or server pool to consider CA certificates and CRLs when verifying client certificates. For details, see Configuring FortiWeb to validate client certificates.
Configure the server policy to accept HTTPS. For details, see HTTPS Service.

Example: Generating & downloading a personal certificate from Microsoft Windows 2003 Server

If you are running Microsoft Certificate Services on Microsoft Windows 2003 Server, you can use your server as a CA, to generate and sign personal certificates on behalf of your clients.

As part of signing the certificate, the CA will send the finished personal certificate to your web browser. As a result, when you are finished generating, you must export the certificates from your computer’s trust store in order to deploy the certificates to clients.

To generate a personal certificate in Microsoft Windows 2003 Server

On your management computer, start your web browser.
Go to:

https://<ca-server_ipv4>/certsrv/

where <ca-server_ipv4> is the IP address of your CA server.

Log in as Administrator.
Click the Request a certificate link.
Click the advanced certificate request link.
Click the Create and submit a request to this CA link.
In the Certificate Template drop-down list, select the Client Authentication template (or a template that you have created for the purpose using Microsoft Management Console (MMC)).
In the Name field, type the name the end-user on behalf of which the client certificate request is being made. This will be the Subject: field in the certificate. Other fields are optional.
Click Submit.

The certificate signing request (CSR) is submitted to the CA.

If a message appears, warning you that the website is requesting a new certificate on your behalf, click Yes to proceed.

Once the CA server generates the requested certificate, the Certificate Issued window appears.

Click the Install this certificate link.

Your browser downloads the certificate, including its private key, and installs it in its trust store. The certificate’s name is the one you specified in In the Name field, type the name the end-user on behalf of which the client certificate request is being made. This will be the Subject: field in the certificate. Other fields are optional..

Transmit and store any private key backups securely, just as you would for passwords. Failure to store them securely and restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your websites.

In the event of potential private key compromise, immediately revoke the corresponding personal certificate. For details, see Revoking certificates.

If a message appears, warning you that the website is adding one or more certificates to your computer, click Yes to proceed.
Return to the Microsoft Certificate Services (MSCS) home page for your local CA and repeat Click the Request a certificate link. through If a message appears, warning you that the website is adding one or more certificates to your computer, click Yes to proceed. for each end-user that will use PKI authentication.

To export and transmit a personal certificate from the trust store on Microsoft Windows 7

Start Microsoft Internet Explorer 9.
Go to Tools [gear icon] > Internet options.
Click the Content tab.
Click the Certificates button.
Click to select a personal certificate in the list.
Click Export.
Click Next.
Select Yes, export the private key.

The end-user will require his or her private key in order to authenticate. Without that token (or if many people possess that token), identity cannot be confirmed.

In the event of potential private key compromise, immediately revoke the corresponding personal certificate. For details, see Revoking certificates.

Click Next.
Select Personal Information Exchange - PKCS #12 (.pfx) as the file format.
f you need to absolutely guarantee identity (e.g., not even you, the administrator, will have the end-user’s private key installed – only the end-user will), mark the check box named Delete the private key if the export is successful.
For improved performance, do not include all CA certificates from the personal certificate’s certification path (e.g., the chain of trust or signing chain). Including the signing chain increases the size of the certificate, which slightly increases the amount of time and traffic volume required to transmit the certificate each time to FortiWeb. Instead, upload those CAs’ certificates to the FortiWeb appliance. For details, see Uploading trusted CA certificates.
Click Next.
Enter and confirm the spelling of the password that will be used to password-protect and encrypt the exported certificate and its private key.
Click Next.
In File name, enter a unique file name for the certificate, then click Browse to specify the location where you want to save the exported certificate and private key.
Use a consistent naming convention. This will minimize the likelihood that you confuse one person’s private key with another’s, deliver it to the wrong person, and therefore need to revoke the corresponding certificate and generate a new one.
Click Finish to export the certificate and private key.
The certificate and private key are exported in a single file with a .pfx file extension to the location specified in In File name, enter a unique file name for the certificate, then click Browse to specify the location where you want to save the exported certificate and private key.Use a consistent naming convention. This will minimize the likelihood that you confuse one person’s private key with another’s, deliver it to the wrong person, and therefore need to revoke the corresponding certificate and generate a new one..
If the export is successful, a notice appears.
Click OK.
Securely transmit both the .pfx file and its password to the end-user, along with instructions on how to install the certificate in his or her web browser’s trust store.

Only provide the client’s private key to that specific client, and transmit and store any backups securely, just as you would for passwords. Failure to store it securely and restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your websites.

In the event of potential private key compromise, immediately revoke the corresponding personal certificate. For details, see Revoking certificates.

For example, you could give him or her a USB key in person and instruct the end-user to double-click the file, or install the .pfx in a Microsoft Active Directory roaming profile. For details, see Example: Importing the personal certificate & private key to a client’s trust store on Microsoft Windows 7.

Example: Downloading the CA’s certificate from Microsoft Windows 2003 Server

If you are generated and signed your end-users’ personal certificates using Microsoft Certificate Services on Microsoft Windows 2003 or 2008 Server, you must download the CA’s certificate and provide it to the FortiWeb appliance so that it will be able to verify the CA signature on each personal certificate.

To download a CA certificate from Microsoft Windows 2003 Server

On your management computer, start your web browser.
Go to:
https://<ca-server_ipv4>/certsrv/
where <ca-server_ipv4> is the IP address of your CA server.
Log in as Administrator.
Click the Download CA certificate, certificate chain, or CRL link.
From Encoding Method, select Base64.
Click Download CA certificate.
If your browser prompts you, select a location to save the CA’s certificate file.

Example: Importing the personal certificate & private key to a client’s trust store on Microsoft Windows 7

If you need to import one or two certificates to a person’s computer on his or her behalf, you can manually import the .pfx file.

If you are importing a clients’ personal certificates to their computers on their behalf, for mass distribution, it may save you time to instead deploy certificates via a script or, if the computer is a member of a Microsoft Active Directory domain, a login script or roaming profile.

To harden security, you should also make sure that the browser’s settings are configured to check servers’ certificates (such as FortiWeb’s) with a CRL in case the servers’ certificates become compromised, and must be revoked.

Methods for importing a certificate to the trust store vary by the client’s browser and operating system. In this section are methods for some popular browsers. For other browsers and operating systems, consult the client’s browser documentation.

To import a client certificate into Microsoft Windows 7

Start Microsoft Internet Explorer 9.
Alternatively, if you have a .pfx file, double-click it to open the wizard, then skip to step Start Microsoft Internet Explorer 9.Alternatively, if you have a .pfx file, double-click it to open the wizard, then skip to step Start Microsoft Internet Explorer 9.Alternatively, if you have a .pfx file, double-click it to open the wizard, then skip to step 6.Go to Tools [gear icon] > Internet options.Click the Content tab.Click the Certificates button.Click Import.The Certificate Import Wizard appears.Click Next. If you double-clicked the certificate and private key file to start the wizard, the file is already specified in File name.Otherwise, click Browse. Go to the location where you downloaded the personal certificate. From Files of type, select Personal Information Exchange (*.pfx, *.p12), All Files (*.*), or whatever file format was used to export the certificate. Finally, select the certificate file, and click Open.Click Next.The Password step appears.In Password, type the password that was used to secure the private key. (If the certificate was made on your behalf by an administrator, this is the password that the administrator used when exporting your .pfx file. He or she must provide this password to you.)Click Next.The Certificate Store step appears.Select either:Automatically select the certificate store based on the type of certificate—Your personal certificate will automatically be placed in the default personal certificate store, as long as it was created correctly.Place all certificates in the following store—Click the Browse button to manually indicate your personal certificate store.Click Next.Click Finish.If the import is successful, a notification appears.Click OK.The certificate and private key are now imported to the store of certificates specified in step Select either:Automatically select the certificate store based on the type of certificate—Your personal certificate will automatically be placed in the default personal certificate store, as long as it was created correctly.Place all certificates in the following store—Click the Browse button to manually indicate your personal certificate store., which should be the personal certificate store. The person’s browser should now be able to present his or her personal certificate whenever a server requires PKI authentication. Click the Advanced tab.In the Settings area, scroll down to the Security settings.Enable Check for server certificate revocation.Click OK to save your settings and close the Internet Options dialog window.Close Internet Explorer..Go to Tools [gear icon] > Internet options.Click the Content tab.Click the Certificates button.Click Import.The Certificate Import Wizard appears.Click Next. If you double-clicked the certificate and private key file to start the wizard, the file is already specified in File name.Otherwise, click Browse. Go to the location where you downloaded the personal certificate. From Files of type, select Personal Information Exchange (*.pfx, *.p12), All Files (*.*), or whatever file format was used to export the certificate. Finally, select the certificate file, and click Open.Click Next.The Password step appears.In Password, type the password that was used to secure the private key. (If the certificate was made on your behalf by an administrator, this is the password that the administrator used when exporting your .pfx file. He or she must provide this password to you.)Click Next.The Certificate Store step appears.Select either:Automatically select the certificate store based on the type of certificate—Your personal certificate will automatically be placed in the default personal certificate store, as long as it was created correctly.Place all certificates in the following store—Click the Browse button to manually indicate your personal certificate store.Click Next.Click Finish.If the import is successful, a notification appears.Click OK.The certificate and private key are now imported to the store of certificates specified in step Select either:Automatically select the certificate store based on the type of certificate—Your personal certificate will automatically be placed in the default personal certificate store, as long as it was created correctly.Place all certificates in the following store—Click the Browse button to manually indicate your personal certificate store., which should be the personal certificate store. The person’s browser should now be able to present his or her personal certificate whenever a server requires PKI authentication. Click the Advanced tab.In the Settings area, scroll down to the Security settings.Enable Check for server certificate revocation.Click OK to save your settings and close the Internet Options dialog window.Close Internet Explorer..
Go to Tools [gear icon] > Internet options.
Click the Content tab.
Click the Certificates button.
Click Import.
The Certificate Import Wizard appears.
Click Next.

If you double-clicked the certificate and private key file to start the wizard, the file is already specified in File name.

Otherwise, click Browse. Go to the location where you downloaded the personal certificate. From Files of type, select Personal Information Exchange (*.pfx, *.p12), All Files (*.*), or whatever file format was used to export the certificate. Finally, select the certificate file, and click Open.

Click Next.
The Password step appears.
In Password, type the password that was used to secure the private key. (If the certificate was made on your behalf by an administrator, this is the password that the administrator used when exporting your .pfx file. He or she must provide this password to you.)
Click Next.
The Certificate Store step appears.
Select either:
Automatically select the certificate store based on the type of certificate—Your personal certificate will automatically be placed in the default personal certificate store, as long as it was created correctly.
Place all certificates in the following store—Click the Browse button to manually indicate your personal certificate store.
Click Next.
Click Finish.
If the import is successful, a notification appears.
Click OK.
The certificate and private key are now imported to the store of certificates specified in step Select either:Automatically select the certificate store based on the type of certificate—Your personal certificate will automatically be placed in the default personal certificate store, as long as it was created correctly.Place all certificates in the following store—Click the Browse button to manually indicate your personal certificate store., which should be the personal certificate store. The person’s browser should now be able to present his or her personal certificate whenever a server requires PKI authentication.
Click the Advanced tab.
In the Settings area, scroll down to the Security settings.
Enable Check for server certificate revocation.
Click OK to save your settings and close the Internet Options dialog window.
Close Internet Explorer.

The Check for server certificate revocation option will not take effect until you restart the browser.

To import a client certificate into Google Chrome on Microsoft Windows 7

Start Google Chrome.
Click the wrench icon in the top right (Customize and control Google Chrome), then select Settings... from the drop-down menu that appears. On Mac OS X, this option is named Preferences.
The dialog for configuring Google Chrome settings appears. On the left hand navigation menu, the Settings section is selected.
At the bottom of the page, click Show advanced settings to reveal additional settings, including HTTP/SSL.
In the HTTPS/SSL area, enable Check for certificate revocation.
Click the Manage certificates button.

The Windows Certificates store dialog window appears. (In Mac OS X, this is the Keychain Access application instead.) By default, the Personal tab is front most. Continue with Click Import.The Certificate Import Wizard appears. in To import a client certificate into Microsoft Windows 7.

Import a personal certificate in Google Chrome. Go to [Wrench icon] > Options > Under the Hood, click Manage Certificates, then click Import

Uploading the CA’s certificate to FortiWeb’s trusted CA store

In order for FortiWeb to be able to verify the CA’s signature on client’s personal certificates when they connect, the CA’s certificate must exist in the FortiWeb’s trusted CA certificate store.

You must either:

Upload the certificates of the signing CA and all intermediary CAs to FortiWeb’s store of CA certificates. For details, see Uploading trusted CA certificates.
Include the full signing chain up to a CA that FortiWeb knows in all personal certificates in order to prove that the clients’ certificates should be trusted.

To harden security, regularly update FortiWeb’s CRL file in order to immediately revoke a CA’s certificate if has been compromised. For details, see Revoking certificates.

Configuring FortiWeb to validate client certificates

To be valid, a client certificate must:

Not be expired or not yet valid.
Not be revoked by a certificate revocation list (CRL).
Be signed by a certificate authority (CA) whose certificate you have imported into the FortiWeb appliance. For details, see Uploading trusted CA certificates.
Contain a CA field whose value matches a CA’s certificate.
Contain an Issuer field whose value matches the Subject field in a CA’s certificate.

If the client presents an invalid certificate during PKI authentication for HTTPS, the FortiWeb appliance will not allow the connection.

Certificate validation rules (in the web UI, these are called certificate verification rules) tell FortiWeb which set of CA certificates to use when it validates personal certificates. They also specify a CRL, if any, if the client’s certificate must be checked for revocation.

Alternatively, if you have enabled SNI in a server policy or server pool, FortiWeb uses the set of CA certificates specified in the SNI configuration that matches the client request to validate personal certificates.

If you configure the URL-based client certificate feature in a server policy orgroup, the rules in the specified URL-based client certificate group determine whether a client is required to present a personal certificate.

To configure a certificate validation rule

Before you can configure a certificate validation rule, you must first configure a CA group. For details, see Grouping trusted CA certificates. You may also need to upload a CRL file if you need to explicitly revoke some invalid or compromised certificates. For details, see Revoking certificates.
Go to System > Certificates > Certificate Verify.
To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Admin Users category. For details, see Permissions.
Click Create New.
A dialog appears.
Configure these settings:

Name	Type a name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
CA Group	Select the name of an existing CA Group that you want to use to authenticate client certificates. For details, see Grouping trusted CA certificates.
CRL Group	Select the name of an existing CRL Group, if any, to use to verify the revocation status of client certificates. For details, see Revoking certificates.
Publish CA Distinguished Name	Enable to list only certificates related to the specified CA group. This is beneficial when a client installs many certificates in its browser or when apps don't list client certificates. If you enable this option, also enable the option in a CA group. For details, see Grouping trusted CA certificates.
Strictly Require Client Certificate	Enable so that FortiWeb requires a client to provide a client certificate during the SSL handshake. When enabled, if a client doesn't provide a client certificate during the SSL handshake, FortiWeb won't accept the request. When disabled, FortiWeb will accept a request even if the client doesn't provide a client certificate during the SSL handshake.

Click OK.

To apply a certificate verification rule, do one of the following:

Select it in a server policy or server pool configuration that includes HTTPS service. For details, see Configuring an HTTP server policy or Creating a server pool.
Select it in an SNI configuration. For details, see Allowing FortiWeb to support multiple server certificates.

When a client connects to the website, after FortiWeb presents its own server certificate, it will request one from the client.The web browser should display a prompt, allowing the person to indicate which personal certificate he or she wants to present.

If the connection fails when you have selected a certificate verifier, verify that the certificate meets the web browser’s requirements. Web browsers may have their own certificate validation requirements in addition to FortiWeb's requirements. For example, personal certificates for client authentication may be required to either:

Not be restricted in usage/purpose by the CA.
Contain a Key Usage field that contains a Digital Signature or have a ExtendedKeyUsage or EnhancedKeyUsage field whose value contains Client Authentication.

If the certificate does not satisfy browser requirements, although it may be installed in the client’s store, when the FortiWeb appliance requests the client’s certificate, the browser may not present a certificate selection dialog to the user, or the dialog may not contain that certificate. In that case, verification will fail.

For browser requirements, see your web browser’s documentation.

When a PKI authentication attempt fails, if you have enabled logging, attack log messages will be recorded. Messages vary by the cause of the error. Common messages are:

X509 Error 20 - Issuer certificate could not be found. FortiWeb does not have the certificate of the CA that signed the personal certificate, and therefore cannot verify the personal certificate. For details, see Uploading trusted CA certificates.

X509 Error 52 - Get client certificate failed. The client did not present its personal certificate to FortiWeb, which could be caused by the client not having its personal certificate properly installed. For details, see How to apply PKI client authentication (personal certificates).

X509 Error 53 - Protocol error. Various causes, but could be due to the client and FortiWeb having no mutually understood cipher suite or protocol version during the SSL/TLS handshake.

Configure FortiWeb to validate server certificates

A valid server certificate must:

Not expire.
Not be revoked by a certificate revocation list (CRL).
Be signed by a certificate authority (CA) whose certificate you have imported into the FortiWeb appliance.
Contain a CA field whose value matches a CA’s certificate.

For Reverse Proxy and True Transparent Proxy modes, FortiWeb can now verify validity of the back end server certificate.

If the server presents an invalid certificate during PKI authentication for HTTPS, the FortiWeb appliance will not allow the connection, and block access to the server.

To configure a server certificate validation rule

Before you can configure a server certificate validation rule, you must first configure a CA group. For details, see Grouping trusted CA certificates. You may also need to upload a CRL file if you need to explicitly revoke some invalid or compromised certificates. For details, see Revoking certificates.
Go to System > Certificates > Server Certificate Verify.
To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Admin Users category. For details, see Permissions.
Click Create New.
A dialog appears.
Configure these settings:

Name	Type a name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
CA Group	Select the name of an existing CA Group that you want to use to authenticate server certificates. For details, see Grouping trusted CA certificates.
CRL Group	Select the name of an existing CRL Group, if any, to use to verify the revocation status of server certificates. For details, see Revoking certificates.

Click OK.
To apply a server certificate verification rule, select it in a server pool configuration that includes HTTPS service.

Use URLs to determine whether a client is required to present a certificate

You can use Certificate Verification in a server policy (Reverse Proxy mode) or server pool configuration (True Transparent Proxy) to require clients to present a personal certificate. When you select a value for this setting, all clients are required to present a personal certificate.

Alternatively, you can configure the URL-based client certificate feature in a server policy or server pool, which allows you to require a certificate for some requests and not for others. Whether a client is required to present a personal certificate or not is based on the requested URL and the rules you specify in the URL-based client certificate group.

A URL-based client certificate group specifies the URLs to match and whether the matched request is required to present a certificate or exempt from presenting a certificate.

When the URL-based client certificate feature is enabled, clients are not required to present a certificate if the request URL is specified as exempt in the URL-based client certificate group rule or URL of the request does not match a rule.

To configure a certificate validation rule

Go to System > Certificates > URL Certificate.
To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Admin Users category. For details, see Permissions.
Click Create New.
For Name, enter a name that can be referenced in other parts of the configuration.
Click OK.
Click Create New.
Complete these settings:

URL

Specify the URL to match.

When the URL of a client request matches this value and Match is selected, FortiWeb requires the client to present a private certificate.

Match

Specifies whether client requests with the URL specified by Use URLs to determine whether a client is required to present a certificate are required to present a personal certificate.

If this option is not selected, client requests with the URL specified by Use URLs to determine whether a client is required to present a certificate are not required to present a personal certificate.

Repeat the URL certificate member creation steps for any other URLs you require.
Click OK to close the URL certificate configuration.
To apply URL-based client certificate group, select it in a server policy or server pool configuration that includes an HTTPS service or SSL. For details, seeConfiguring an HTTP server policy or Creating a server pool.

Using XML client certificates and server certificates for WS-Security rule

Unique for WS-Security rules in XML Protection, you can upload XML client certificates and server certificates to FortiWeb. The XML server certificate is used for request decryption or response signature, while the XML client certificate is used for request verification or response encryption.

The certificates must be in x509v3 format and PEM file.

To upload a server certificate

Go to System > Certificates > XML Certificate.
To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Admin Users category. For details, see Permissions.
Click Server Certificate.
Click Import.

Configure these settings.

Certificate file	Click Choose File to locate the certificate file that you want to upload.
Key file	Click Choose File to locate the key file that you want to upload with the certificate.
Password	Type the password that is used to encrypt the file, enabling the FortiWeb appliance to decrypt and install the certificate.

Click OK.
To apply the certificate, select it in a WS-Security rule. For details, see Creating WS-Security rules

To upload a client certificate

Go to System > Certificates > XML Certificate.
To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Admin Users category. For details, see Permissions.
Click Client Certificate.
Click Import.

Configure these settings.

Certificate file

Click Choose File to locate the certificate file that you want to upload.

SecretKey file

Click Choose File to locate the key file that you want to upload with the certificate.

This is optional, used only for HMAC-SHA-1 sign.

Click OK.
Once you have uploaded the client certificates you want to use, create a Client Certifcate Group to include in your WS-Security rule. For details, see To create a client certificate group and Creating WS-Security rules.

To create a client certificate group

Go to System > Certificates > XML Certificate.
To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Admin Users category. For details, see Permissions.
Click Client Certificate Group.
For Name, enter a name that can be referenced in other parts of the configuration.
Click OK.
Click Create New to add a client certificate to the group.
Select a client certificate from the drop-down list to include in the group.
Click OK.
Repeat the above steps to include additional client certificates in the group.
To apply the certificate for client authentication, select it in a WS-Security rule. For details, see Creating WS-Security rules