on 20-Jun-2013 06:00 - edited on 24-Mar-2023 17:46 by LiefZimmerman
This is the eighth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM.
This article will discuss the concept of Client Authentication, how it works, and how the BIG-IP system allows you to configure it for your environment.
In a TLS handshake, the client and the server exchange several messages that ultimately result in an encrypted channel for secure communication. During this handshake, the client authenticates the server's identity by verifying the server certificate (for more on the TLS handshake, see SSL Overview and Handshake - Article 1 in this series). Although the client always authenticates the server's identity, the server is not required to authenticate the client's identity. However, there are some situations that call for the server to authenticate the client.
Client authentication is a feature that lets you authenticate users that are accessing a server. In client authentication, a certificate is passed from the client to the server and is verified by the server. Client authentication allow you to rest assured that the person represented by the certificate is the person you expect. Many companies want to ensure that only authorized users can gain access to the services and content they provide. As more personal and access-controlled information moves online, client authentication becomes more of a reality and a necessity.
Before we jump into client authentication, let's make sure we understand server authentication. During the TLS handshake, the client authenticates the identity of the server by verifying the server's certificate and using the server's public key to encrypt data that will be used to compute the shared symmetric key. The server can only generate the symmetric key used in the TLS session if it can decrypt that data with its private key. The following diagram shows an abbreviated version of the TLS handshake that highlights some of these concepts.
Ultimately, the client and server need to use a symmetric key to encrypt all communication during their TLS session. In order to calculate that key, the server shares its certificate with the client (the certificate includes the server's public key), and the client sends a random string of data to the server (encrypted with the server's public key). Now that the client and server each have the random string of data, they can each calculate (independently) the symmetric key that will be used to encrypt all remaining communication for the duration of that specific TLS session. In fact, the client and server both send a "Finished' message at the end of the handshake...and that message is encrypted with the symmetric key that they have both calculated on their own. So, if all that stuff works and they can both read each other's "Finished" message, then the server has been authenticated by the client and they proceed along with smiles on their collective faces (encrypted smiles, of course).
You'll notice in the diagram above that the server sent its certificate to the client, but the client never sent its certificate to the server. When client authentication is used, the server still sends its certificate to the client, but it also sends a "Certificate Request" message to the client. This lets the client know that it needs to get its certificate ready because the next message from the client to the server (during the handshake) will need to include the client certificate. The following diagram shows the added steps needed during the TLS handshake for client authentication.
So, you can see that when client authentication is enabled, the public and private keys are still used to encrypt and decrypt critical information that leads to the shared symmetric key. In addition to the public and private keys being used for authentication, the client and server both send certificates and each verifies the certificate of the other. This certificate verification is also part of the authentication process for both the client and the server. The certificate verification process includes four important checks. If any of these checks do not return a valid response, the certificate verification fails (which makes the TLS handshake fail) and the session will terminate. These checks are as follows:
Here's how the client and server accomplish each of the checks for client authentication:
As you can see, a bunch of stuff has to happen in just the right way for the Client-Authenticated TLS handshake to finalize correctly. But, all this is in place for your own protection. After all, you want to make sure that no one else can steal your identity and impersonate you on a critically important website!
Now that we've established the foundation for client authentication in a TLS handshake, let's figure out how the BIG-IP is set up to handle this feature. The following screenshot shows the user interface for configuring Client Authentication. To get here, navigate to Local Traffic > Profiles > SSL > Client.
The Client Certificate drop down menu has three settings: Ignore (default), Require, and Request. The "Ignore" setting specifies that the system will ignore any certificate presented and will not authenticate the client before establishing the SSL session. This effectively turns off client authentication. The "Require" setting enforces client authentication. When this setting is enabled, the BIG-IP will request a client certificate and attempt to verify it. An SSL session is established only if a valid client certificate from a trusted CA is presented. Finally, the "Request" setting enables optional client authentication. When this setting is enabled, the BIG-IP will request a client certificate and attempt to verify it. However, an SSL session will be established regardless of whether or not a valid client certificate from a trusted CA is presented. The Request option is often used in conjunction with iRules in order to provide selective access depending on the certificate that is presented. For example: let's say you would like to allow clients who present a certificate from a trusted CA to gain access to the application while clients who do not provide the required certificate be redirected to a page detailing the access requirements. If you are not using iRules to enforce a different outcome based on the certificate details, there is no significant benefit to using the "Request" setting versus the default "Ignore" setting. In both cases, an SSL session will be established regardless of the certificate presented.
Frequency specifies the frequency of client authentication for an SSL session. This menu offers two options: Once (default) and Always. The "Once" setting specifies that the system will authenticate the client only once for an SSL session. The "Always"setting specifies that the system will authenticate the client once when the SSL session is established as well as each time that session is reused.
The Retain Certificate box is checked by default. When checked, the client certificate is retained for the SSL session.
Certificate Chain Traversal Depth specifies the maximum number of certificates that can be traversed in a client certificate chain. The default for this setting is 9. Remember that "Certificate Chain" part of the verification checks? This setting is where you configure the depth that you allow the server to dig for a trusted CA. For more on certificate chains, see article 2 of this SSL series.
Trusted Certificate Authorities setting is used to specify the BIG-IP's Trusted Certificate Authorities store. These are the CAs that the BIG-IP trusts when it verifies a client certificate that is presented during client authentication. The default value for the Trusted Certificate Authorities setting is None, indicating that no CAs are trusted. Don't forget...if the BIG-IP Client Certificate menu is set to Require but the Trusted Certificate Authorities is set to None, clients will not be able to establish SSL sessions with the virtual server. The drop down list in this setting includes the name of all the SSL certificates installed in the BIG-IP's /config/ssl/ssl.crt directory. A newly-installed BIG-IP system will include the following certificates: default certificate and ca-bundle certificate. The default certificate is a self-signed server certificate used when testing SSL profiles. This certificate is not appropriate for use as a Trusted Certificate Authorities certificate bundle. The ca-bundle certificate is a bundle of CA certificates from most of the well-known PKIs around the world. This certificate may be appropriate for use as a Trusted Certificate Authorities certificate bundle. However, if this bundle is specified as the Trusted Certificate Authorities certificate store, any valid client certificate that is signed by one of the popular Root CAs included in the default ca-bundle.crt will be authenticated. This provides some level of identification, but it provides very little access control since almost any valid client certificate could be authenticated.
If you want to trust only certificates signed by a specific CA or set of CAs, you should create and install a bundle containing the certificates of the CAs whose certificates you trust. The bundle must also include the entire chain of CA certificates necessary to establish a chain of trust. Once you create this new certificate bundle, you can select it in the Trusted Certificate Authorities drop down menu.
The Advertised Certificate Authorities setting is used to specify the CAs that the BIG-IP advertises as trusted when soliciting a client certificate for client authentication. The default value for the Advertised Certificate Authorities setting is None, indicating that no CAs are advertised. When set to None, no list of trusted CAs is sent to a client with the certificate request. If the Client Certificate menu is set to Require or Request, you can configure the Advertised Certificate Authorities setting to send clients a list of CAs that the server is likely to trust. Like the Trusted Certificate Authorities list, the Advertised Certificate Authorities drop down list includes the name of all the SSL certificates installed in the BIG-IP /config/ssl/ssl.crt directory. A newly-installed BIG-IP system includes the following certificates: default certificate and ca-bundle certificate. The default certificate is a self-signed server certificate used for testing SSL profiles. This certificate is not appropriate for use as an Advertised Certificate Authorities certificate bundle. The ca-bundle certificate is a bundle of CA certificates from most of the well-known PKIs around the world. This certificate may be appropriate for use as an Advertised Certificate Authorities certificate bundle.
If you want to advertise only a specific CA or set of CAs, you should create and install a bundle containing the certificates of the CA to advertise. Once you create this new certificate bundle, you can select it in the Advertised Certificate Authorities setting drop down menu.
You are allowed to configure the Advertised Certificate Authorities setting to send a different list of CAs than that specified for the Trusted Certificate Authorities. This allows greater control over the configuration information shared with unknown clients. You might not want to reveal the entire list of trusted CAs to a client that does not automatically present a valid client certificate from a trusted CA. Finally, you should avoid specifying a bundle that contains a large number of certificates when you configure the Advertised Certificate Authorities setting. This will cut down on the number of certificates exchanged during a client SSL handshake. The maximum size allowed by the BIG-IP for native SSL handshake messages is 14,304 bytes. Most handshakes don't result in large message lengths, but if the SSL handshake is negotiating a native cipher and the total length of all messages in the handshake exceeds the 14,304 byte threshold, the handshake will fail.
The Certificate Revocation List (CRL) setting allows you to specify a CRL that the BIG-IP will use to check revocation status of a certificate prior to authenticating a client. If you want to use a CRL, you must upload it to the /config/ssl/ssl.crl directory on the BIG-IP. The name of the CRL file may then be entered in the CRL setting dialog box. Note that this box will offer no drop down menu options until you upload a CRL file to the BIG-IP. Since CRLs can quickly become outdated, you should use either OCSP or CRLDP profiles for more robust and current verification functionality.
Well, that wraps up our discussion on Client Authentication. I hope the information helped, and I hope you can use this to configure your BIG-IP to meet the needs of your specific network environment. Be sure to come back for our next article in the SSL series. As always, if you have any other questions, feel free to post a question here or Contact Us directly.
See you next time!
If you want to trust only certificates signed by a specific CA or set of CAs, you should create and install a bundle containing the certificates of the CAs whose certificates you trust -
My Query -
(1) as of now we got one certificate from one client.
can we use same certificate as CA or CA is something different.
(2) when we will get more then one certificate from multiple clients then how we will select multiple certificates or CA from drop down, or as you mentioned that we should create bundle. then can you please guide us how to create this bundle./ process.
We tried doing client certificate authentication but unsuccessful. We generated self-signed certificate for client system on F5 LTM. Exported and imported the certificate and key in client system Mozilla browser. We have set 'require' setting in ssl profile client authentication. When trying to access website we get pop-up in mozilla to select certificate, after selecting certificate we get ssl error message in browser.
On F5 LTM logs we see below logs: Aug 31 17:56:56 ltm warning tmm: 01260006:4: Peer cert verify error: self signed certificate (depth 0; cert /C=IN/ST=example/L=abc/O=xyz/OU=IT/CN= Aug 31 17:56:56 ltm info tmm: Rule /Common/Cert_Logging : Certificate 1: XX:XX:XX:XX Aug 31 17:56:56 ltm info tmm: Rule /Common/Cert_Logging : Client Certificate Recieved - IP:192.168.1.4 Serial:XX:XX:XX:XX Aug 31 17:56:56 ltm warning tmm: 01260009:4: Connection error: ssl_shim_vfycerterr:4403: self signed certificate (48)
We see F5 is receiving certificate but unable to verify it. Even though certificate is available with F5.
Thanks John for your response.
We are testing this in our lab so unable to arrange CA certificate. One of our customer have requested to configure client authentication, before we do it on customer device we wanted to test in our lab, to avoid problems during in customer setup.
Client authentication is not possible using self-signed certificate? Even though certificate is imported in f5.
Hi, Thanks for the brief explanation. I am having an issue, hopefully you, or someone has a solution. I turned on SSL bridging for one of the VS. When a client sends pkt to the server it contains a cert ABC but when the reply comes back the cert is getting replaced with XYZ. Our dev team has wrote a code and based on the cert they need to make some decision, but due the cert is getting replaced the code is not working as expected. Also when I turn off SSL bridging and use FastL4 instead, I do not see that issue. Can someone please help how can I retain cert ABC when reply comes back from server ?
Hi Frank! Have you tried posting this question in our Q&A section? I don't have a great answer for you off the top of my head, but I think it might get more attention in the Q&A section than here on the article comments. I'll look around to see if I can find an answer, but you may want to post it in Q&A in the meantime. Thanks!
Hi John, I found the solution but were not able to test it, as client requirements were changed and now they don't need SSL bridging. The solution that I found after going through a number of F5 articles is that in order to retain the client cert. I need to turn on ProxySSL at both server and client side SSL profiles. In that way, client cert will be directly passed by the f5 to a server as soon as it receives it.
Hi John Wagnon,
Is there any CLI command to see certificate which is presented by a client on a specific VIP.
This will help us know the certificate presented by the client and we can add that to the trust store.
Is there any way to tell clients (Windows, Internet Explorer in my case) to only allow the user to pick from certain certificate types? If possible, I'd like to filter on either a specific Key Usage attribute or on a specific "Certificate Policy" attribute that is present for our authentication certificates.
Quick question regarding this topic, as this sounds familiar. I have an application in which F5 is providing the SP FOR. the thing is, clients can be good logging in in the morning, then the evening, they get a PKI/F5 authentication error. I know they have been in before. We are talking different clients, but basically the same thing happens.
Any ideas, or is there anything I can do on this end to stop this from happening?
Hi! I'm reading on this topic and checking on the procedure in implementing it. However, there are some items that are still not yet clear to me (more on the client side), hence would like your help so that I can understand properly. Please feel free to correct me if my statements are wrong:
Thank you and so sorry again if my understanding of this topic is not correct.
We had try Client Authentication successfully with a self-signed Certificate by the Client, importing this Client Certificate on the F5 and setting it on the SSL Client Profile as "Trusted Certificate Authorities".
Now we want the Client to use a certificate signed by a CA (lets say "DigiCert"), if I install the CAs on the F5 and configure it on the profile... Anyone with a Certificate signed by DigiCert will be approved... right?
But we don't want this....
We would like to approve only an specific client... but as the communication will be public so, a Cert CA signed should be the "go to" solution...
In this case, a self-signed could be the best option? or Is there a way to only "approve" an specific Certificate, and also check its CAs?
Hi Daniel...great question! Yes, if you install a certificate signed by a CA (like DigiCert), then clients with that signed certificate would be able to connect. The BIG-IP would effectively be told to accept connections from a signed DigiCert (or whatever you use) certificate. You could move back to the self signed cert if you want. But, I'm wondering if there's another solution for accepting clients. Maybe you could try other options rather than having to use Client Authentication? Obviously I don't know all the details of your setup, but I'm just thinking there might be some other ways to accept some clients and not others. Do you have ASM running by chance?