Optional Client Certificates and Header Injection
An LTM 16.1 SSL client-certificate deployment serves 500 business partners through virtual server partner_vs 198.51.100.10:443. The Client SSL profile uses Client Certificate: require and a CA bundle containing the partner issuing CAs. The backend application expects an HTTP header named X-Client-Subject containing the certificate subject DN and uses it for authorization. Partners that have certificates work, but partners without certificates fail during the TLS handshake with an alert and never reach the application. Some valid partners also report that the backend sees no X-Client-Subject header even when their certificate is accepted. The business now wants certificates optional: partners with a certificate should be identified, and partners without one should still reach the application as unauthenticated users. The application is HTTP/1.1 behind the BIG-IP, and SSL is terminated on the BIG-IP. No iRules are currently configured on the virtual server.
1. Why do partners without certificates fail, and what Client SSL profile change makes certificates optional while still validating those that are presented?
Read the worked answer
Reasoning
Client Certificate: require sends a CertificateRequest during the TLS handshake and aborts the handshake if the client returns no certificate. That is why partners without certificates never reach HTTP. Changing the setting to request sends the same request but permits an empty client certificate. If the client does present a certificate, the BIG-IP still validates it against the configured CA bundle; an invalid or untrusted certificate should still fail. The profile change alone does not add the missing HTTP header, which explains why accepted certificates are not visible to the backend.
2. Write an iRule that adds the client certificate subject for certificate users and marks anonymous users, including protection against header spoofing.
Read the worked answer
Reasoning
The iRule runs on HTTP_REQUEST after SSL termination. It must remove any inbound copy of the headers before adding its own, otherwise a client could spoof them. SSL::cert 0 returns the first client certificate or an empty value. Use X509::subject to extract the DN. A safe pattern is:
when HTTP_REQUEST {
HTTP::header remove X-Client-Subject
HTTP::header remove X-Client-Auth
set cert [SSL::cert 0]
if { [string length $cert] > 0 } {
HTTP::header insert X-Client-Subject [X509::subject $cert]
HTTP::header insert X-Client-Auth cert
} else {
HTTP::header insert X-Client-Auth anonymous
}
}
For anonymous users, either omit X-Client-Subject or insert a fixed value such as anonymous; do not leave an old client-supplied value in place. The application must treat the presence of X-Client-Auth: cert as meaningful only when the request came through the BIG-IP.
3. What operational and security checks should follow this change?
Read the worked answer
Reasoning
Test four handshake cases with openssl s_client: no client certificate, a valid partner certificate, an expired certificate, and a certificate from an unknown CA. The first should reach HTTP as anonymous; the valid one should reach HTTP with a subject header; the last two should fail TLS. Confirm with a packet capture or application log that the backend receives X-Client-Auth and the expected subject. Review the CA bundle and any revocation method, because request changes who can reach the application even though it does not weaken validation of presented certificates. Finally, confirm that clients cannot reach the backend directly and bypass the header-stripping iRule, and that the application does not trust X-Client-Subject from any other source.