cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

Quick Intro

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

0151T000003WGVcQAO.png

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:

0151T000003WGVhQAO.png

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:

0151T000003WGVmQAO.png

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

0151T000003WGVrQAO.png

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:

0151T000003WGVwQAO.png

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:

0151T000003WGVxQAO.png

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.

Comments
nikzin
Altocumulus
Altocumulus

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 ?

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

Rahul_Kaul
Cirrus
Cirrus

Hi Rodrigo, thanks for clarifying the details regarding "Authenticate Name" field.πŸ‘

dragonflymr
Cirrus
Cirrus

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

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
Cirrus
Cirrus

Hi,

Thanks for fast reply πŸ‘ I expected that a bit, so only way is iRule the - right?

Piotr

I never tried iRules option but if you can do do it yeah.

dragonflymr
Cirrus
Cirrus

Well, did plenty of Server SSL Profile switching profile iRules, so basics should work, can't see right now why not, but will test it 😎

 

Any chance you can share info about serverssl-use-sni - seems like quite useful function (especially in Virtual Hosting scenario), just from description I am not sure to what ClientHello SNI is matched - to value in Server Name property of Server SSL Profile or maybe Authenticate Name is used for that?

If multiple server SSL profiles are configured, and serverssl-use-sni is enabled, then the server SSL profile whose server-name matches the SNI extension in ClientHello will be selected. It's available in v15.1.0 that is already out.

dragonflymr
Cirrus
Cirrus

Well, I know that πŸ˜€ That is how I found it - however there is no matching option in GUI, and as I already asked not sure with which parametr in Server SSL Profile ClientHello SNI is matched...

It's not on Server SSL profile, it's on Virtual Server configuration. πŸ™‚

dragonflymr
Cirrus
Cirrus

Sure I know. Anyway I tested it and works like charm for Virtual Hosting scenario. Multiple FQDNs pointing to single VS, then this VS sending traffic to Pool Members as well handling multiple FQDNs. Correct Server SSL Profile is selected based on client ClientHello SNI. So both SNI presented to backend server is the same as specified by client, and Authenticate Name is checked based on previously selected Server SSL Profile.

I doubt however it can be used for VS serving one FQDN but with Pool Members each requiring different SNI - only way is switching Server SSL profiles via iRule.

Piotr

Version history
Last update:
β€Ž20-Apr-2020 00:21
Updated by:
Contributors