Understanding the Authenticate Name Option on Server SSL profile on BIG-IP

Quick Intro

Have you ever wondered what this little option on Server SSL profile really does in practice?

This is what this article is all about.

If you're only interested about what I learnt during my lab tests, please feel free to read just Lab Test Results section.

Otherwise, enjoy the lab walkthrough :)

Lab Test Results

In case you just want to know what it is, this setting looks at both commonName and subjectAltName extension and if whatever name set on Authenticate Name doesn't match the name in any of these 2 fields I mentioned, certificate authentication fails and BIG-IP resets connection.

Note: for Authenticate Name to work, Server Certificate has to be set to Require, i.e. BIG-IP should be configured to check the validity of Server Side certificate. On top of that, ca-file (Trusted Certificate Authorities in the GUI) is also required to be set, otherwise BIG-IP has no trusted Root CA list to validate server's certificate.

What it is

This is like another layer of authentication. When server sends us a Certificate and peer-cert-mode is set to require, BIG-IP looks up Root CA present in ca-file and confirms that server's certificate is trusted. Then, when authenticate-name is also set, BIG-IP checks subjectAltName extension and commonName for a match of what we've typed in this field. If no match is found, certificate authentication fails and we do not trust certificate. Otherwise, certificate is trusted and we proceed with handshake.

Lab Test

When Authenticate Name does not match Certificate's commonName or subjectAltName

I created an end-entity X.509v3 TLS Certificate and set commonName (CN) to server1.rodrigo and subjectAltName extension to server01.rodrigo as seen below:

I set Server Certificate (peer-cert-mode in tmsh) to require, added the Root CA that signed back-end server's certificate to BIG-IP's Trusted Certificate Authorities (ca-file in tmsh) and authentication-name to fail.rodrigo:

On Wireshark, we see that authentication fails as soon as we receive Certificate message from server:

Note: If we want BIG-IP to display the specific alert such as unknown_ca above, we need to disable generic-alert on Server SSL settings.

It fails because fail.rodrigo is neither in CN nor in subjectAltName. I had set server1.rodrigo instead, remember?

Let's break it down into more details:

back-end server sends Certificate message to BIG-IP
because peer-cert-mode is set to require, BIG-IP looks up the Root CA list in ca-file (root-ca.crt here)
BIG-IP answers the following question: was back-end certificate signed by any of the certificates listed in root-ca.crt?
If not, authentication fails immediately and we never get to use authenticate-name
In this case it was, so BIG-IP moves on to check if fail.rodrigo is in either commonName or subjectAltName fields of back-end's X.509v3 certificate
Because fail.rodrigo doesn't match server1.rodrigo, authentication fails and BIG-IP resets connection.

When Authenticate Name matches Certificate's commonName or subjectAltName

I've now set authenticate-name to server1.rodrigo and TLS handshake suceeds:

Let's break it down into more details:

back-end server sends Certificate message to BIG-IP
because peer-cert-mode is set to require, BIG-IP looks up the Root CA list in ca-file (root-ca.crt here)
BIG-IP answers the following question: was back-end certificate signed by any of the certificates listed in root-ca.crt?
If not, authentication fails immediately and we never get to use authenticate-name
In this case it was, so BIG-IP moves on to check if server1.rodrigo is in either commonName or subjectAltName fields of back-end's X.509v3 certificate
Because server1.rodrigo matches server1.rodrigo in both commonName and SubjectAltName fields, authentication succeeds and TLS handshake proceeds

If you ever wondered where to find commonName and SubjectAltName on TLS headers, here's where they are:

The above snippet is from back-end's Certificate message that is sent to BIG-IP as part of TLS handshake.

Hope that's helpful.

Published Apr 20, 2020

Version 1.0

15 Comments

Rodrigo_Albuque
MVP
Apr 26, 2020
It's not possible, Piotr. I'm sorry. Authenticate Name has to be FQDN and only a single one. For example, I had server1.rodrigo.example and server2.rodrigo.example in my lab. So, *.rodrigo.example didn't work, .rodrigo.example didn't work, and comma-separated list also didn't work. The only thing that worked as server1.rodrigo.example or server2.rodrigo.example. There's an old RFE internally tracked by ID 362848 but it didn't get the traction needed to move forward.
dragonflymr
Cirrostratus
Apr 26, 2020
Hi Rodrigo,
Is that possible to use *.company.com in Authenticate Name? If not probably only option to verify certificates of servers set with different FQDNs is to use iRule - guess Local Traffic Policy will be of no use here? - and select correct Server SSL Profile (with Authenticate Name matching Pool Member selected via LB) based on for example Data Group - any better option here?

Doing tmsh list ltm virtual [VS name] on 15.1.0.2 (not present in 14.1.2.3) I noticed parameter serverssl-use-sni with description:

When multiple server-ssl profiles are attached to a virtual, setting this allows one to be chosen based on the SNI extention from the ClientHello if a client-ssl profile is also attached to the virtual.

Probably a bit unrelated but would be great if you could create article about this functionality.

Piotr
Rahul_Kaul
Cirrus
Apr 23, 2020
Hi Rodrigo, thanks for clarifying the details regarding "Authenticate Name" field.👍
Rodrigo_Albuque
MVP
Apr 21, 2020
Hey nikzin, if both pool members are using a certificate with same CN/SubjectAltName that matches FQDN in Authenticate Name (or even the same certificate), it should be fine. Otherwise, you don't need to use Authenticate Name option as it's just another layer of authentication and pretty much leave it blank.

Cheers,
Rodrigo
nikzin
Altocumulus
Apr 21, 2020
Thanks for the article. But what do you set in authenticate name field, if you have more than one poolmember, e.g. server1.rodrigo and server2.rodrigo ? Then you need two server ssl profiles ?