on 20-Apr-2020 00:21
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 🙂
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.
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.
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:
I've now set authenticate-name to server1.rodrigo and TLS handshake suceeds:
Let's break it down into more details:
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.
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.
Hi Rodrigo, thanks for clarifying the details regarding "Authenticate Name" field.👍
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 184.108.40.206 (not present in 220.127.116.11) 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.
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.
Thanks for fast reply 👍 I expected that a bit, so only way is iRule the - right?
I never tried iRules option but if you can do do it yeah.
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.
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. 🙂
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.