How to apply PKI client authentication (personal certificates)

If your clients will connect to your web sites 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).

Because FortiWeb presents its own server certificate to the client before requesting one from the client, all PKI authentication with FortiWeb is actually 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 Client Certificate Forwarding in “Configuring a 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 an Android or iPhone smart phone.

A known weakness of traditional password based authentication is the vulnerability to password guessing or brute force attack. Despite your admonitions, many users will 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, so it is stronger than a password.


	For even stronger authentication, you can combine PKI authentication with HTTP or form-based authentication. For more information, see “Authentication styles”.

• Sole private key possession — 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.

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.


	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 restrict the private key solely to its intended end-user could allow others to authenticate as that person, compromising the security of your web sites. (i.e., It damages the property of non-repudiation.) In the event of potential private key compromise, immediately revoke the corresponding personal certificate. 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 true, for example, in the RSA cryptographic algorithm.

SSL 3.0 or TLS 1.0 is required. During an SSL or TLS handshake, the client and server (in this case, FortiWeb) negotiate which of their supported cryptographic algorithms to use, and exchange certificate(s). 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 (i.e. a man‑in-the-middle attack).


	Depending on factors such as a misconfigured client, an SSL/TLS connection may in some cases still be vulnerable to man-in-the-middle 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. See also “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 that 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’s certificates that the root CA has verifiably signed will also be trusted as genuine. Hence, 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.

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”.

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

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 the FortiWeb (see “Uploading trusted CAs’ certificates”).

4. Upload the CA’s certificate to the FortiWeb’s trust store (see “Uploading the CA’s certificate to FortiWeb’s trusted CA store”).

6. Depending on the FortiWeb’s current operation mode, configure either a server policy or server pool to consider CA certificates and CRLs when verifying client certificates (see “Configuring FortiWeb to validate client certificates”).