cancel
Showing results for 
Search instead for 
Did you mean: 
ltwagnon
Legacy Employee
Legacy Employee

This is the eighth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM.  The first seven articles are:

  1. SSL Overview and Handshake
  2. SSL Certificates
  3. Certificate Chain Implementation
  4. Cipher Suites
  5. SSL Options
  6. SSL Renegotiation
  7. Server Name Indication
  8. Client Authentication
  9. Server Authentication
  10. All the "Little" Options

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.

 

Client Authentication

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 article 1 of 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.

 

How Does Client Authentication Work?

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.

 

0151T000003d5nkQAA.jpg

 

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).  0151T000003d5nlQAA.png

 

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.

 

0151T000003d5nmQAA.jpg

 

 

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:

  1. Check digital signature
  2. Check certificate chain
  3. Check expiration date and validity period
  4. Check certificate revocation status

Here's how the client and server accomplish each of the checks for client authentication:

  1. Digital Signature:  The client sends a "Certificate Verify" message that contains a digitally signed copy of the previous handshake message.  This message is signed using the client certificate's private key.  The server can validate the message digest of the digital signature by using the client's public key (which is found in the client certificate).  Once the digital signature is validated, the server knows that public key belonging to the client matches the private key used to create the signature.
  2. Certificate Chain:  The server maintains a list of trusted CAs, and this list determines which certificates the server will accept.  The server will use the public key from the CA certificate (which it has in its list of trusted CAs) to validate the CA's digital signature on the certificate being presented.  If the message digest has changed or if the public key doesn't correspond to the CA's private key used to sign the certificate, the verification fails and the handshake terminates.
  3. Expiration Date and Validity Period:  The server compares the current date to the validity period listed in the certificate.  If the expiration date has not passed and the current date is within the period, everything is good.  If it's not, then the verification fails and the handshake terminates.
  4. Certificate Revocation Status:  The server compares the client certificate to the list of revoked certificates on the system.  If the client certificate is on the list, the verification fails and the handshake terminates.

 

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!

 

BIG-IP Configuration

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.

 

0151T000003d5nnQAA.jpg

 

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.

 

Conclusion

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, please contact us at https://devcentral.f5.com/s/community/contact-us.  See you next time!

Comments
you wrote -

 

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.
the above I configured as per below: - but it is not working:- Client shared a open.ssl self signed certificate let say client_cert.cer I have imported client_cert.cer in F5. then When I configuring the SSL Client Profile, I selected the client_cert.cer in drop down box of Trusted Certificate Authorities :-- .. is this configuration TRUE, or will I need the different CA certificate from client
mulham_173701
Nimbostratus
Nimbostratus
Hi john , thank you for your great article , one question thought : does the chain considered valid (verified) if only one CA signature is verified or ALL CA's signature has to be verified (which require that all CA's in the chain are in the trusted CA list)
Nitin_Kulkarni1
Nimbostratus
Nimbostratus
Thanks for the information. Really helped me a lot.
matternikus_589
Nimbostratus
Nimbostratus
This page supplied the needed information to me. Good explanation.
sachin_80710
Nimbostratus
Nimbostratus

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[12989]: 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[12989]: Rule /Common/Cert_Logging : Certificate 1: XX:XX:XX:XX Aug 31 17:56:56 ltm info tmm[12989]: 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[12989]: 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.

 

ltwagnon
Legacy Employee
Legacy Employee

this looks to be an issue with the fact that the certificate is self-signed. do you have the option of obtaining a certificate from a Trusted CA?

 

sachin_80710
Nimbostratus
Nimbostratus

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.

 

ltwagnon
Legacy Employee
Legacy Employee

Could you add your self-signed cert to the list of trusted certificates? That would potentially take care of the issue.

 

Macaron
Altostratus
Altostratus

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 ?

 

ltwagnon
Legacy Employee
Legacy Employee

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!

 

Macaron
Altostratus
Altostratus

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.

 

ltwagnon
Legacy Employee
Legacy Employee

ahhh...makes sense! Glad you were able to figure this one out!

 

Sukesh123456
Altostratus
Altostratus

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.

 

Regards Sukesh

 

Stephan_V
Nimbostratus
Nimbostratus

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.

 

socar65
Nimbostratus
Nimbostratus

Hi Guys,

 

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?

 

socar65
Nimbostratus
Nimbostratus

Also -- a bit more info -- On the ssl profile, it is set for request and we do use TRUSTED CA.

 

aries22
Altocumulus
Altocumulus

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:

 

  1. So the client needs its own certificate signed by a CA. The CA certificate (root CA?) will be imported in Big-IP and associated in the Trusted Certificate Authority under Client Authentication field of the client SSL profile.
  2. When generating the client certificate, I am assuming it is much like generating a server certificate- wherein a CSR & private key will be created, and client certificate will be issued using the CSR.
  3. Both the client certificate and client private key shall be imported on the client device.
  4. In the case where let's say 100 client devices are expected to connect to the VS for client authentication, should each client be generated with their own unique certificate?

Thank you and so sorry again if my understanding of this topic is not correct.

 

Daniel_Rodrigue
Nimbostratus
Nimbostratus

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?

 

Thank you

 

ltwagnon
Legacy Employee
Legacy Employee

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?

 

Version history
Last update:
‎20-Jun-2013 06:00
Updated by:
Contributors