Application Delivery (ADX)

SSL Client Authentication and Certificate Insertion

by Yasir_Liaqatullah on ‎07-06-2009 11:00 PM - edited on ‎10-31-2013 03:32 PM by bcm1 (2,351 Views)


Client authentication has been enabled on SSL. However, the incoming client-certificate must be sent to the real server.

SSL Client Certificate HTTP header insertion allows the ServerIron to present the original SSL client certificate to the load-balanced real server. The ServerIron inserts the client certificate as the HTTP header, to allow the real server to access the client certificate information.







   ssl profile verisign128
    keypair-file verisign128key
    certificate-file verisign128cert
    cipher-suite all-cipher-suites
    verify-client-cert per-connection require
    ca-cert-file level_0.pem
    session-cache off
   server source-nat-ip port-range 2 for-ssl
   server source-nat-ip port-range 2
   csw-policy "p1"
    default forward 1
    default rewrite request-insert client-cert                     
   server real rs13
    port http
    port http url "HEAD /"
    port http group-id 1 1
    port 8081
    port 8081 group-id 1 1
   server real rs14
    port http
    port http url "HEAD /"
    port http group-id  1 1
    port 8081
    port 8081 group-id 1 1
   server virtual vip1
    port http
    port ssl
    port ssl ssl-terminate verisign128
    port ssl csw-policy "p1"
    port ssl csw
    bind http rs14 http rs13 http
    bind ssl rs13 8081 real-port http rs14 8081 real-port http
   SSL#sho server bind
   Bind info
   Virtual server: vip1                     Status: enabled  IP:
           http -------> rs14:,  http (Active)
                         rs13:,  http (Active)
            ssl -------> rs13:,  8081 (Active-Active)
                         rs14:,  8081 (Active-Active)



After enable url debug 3 under BP, you should see the following output:


SSL1/1# url debug 3
   C 3082: WAIT_REQ(2), data 1= 446,>
           URL </> Length = 1
           No CSW rule hit, take default action 1
           create sticky:>, vport: 443, C:, S: rs13
           real server <rs13>
           Rewrite msg (0x00000080).
   REL MSG: msg too long, <1502>
   REL MSG: msg too long, <1502>
           Append 1(len: 446) pkts to 0(len: 0) pkts.
           RW data (len:446)...
           URL_REW: rew_seq 16, rew_pos 16, increased_len 1447, insert_len 0, clientcert_len 1447, delete_len -1447, tcp_data_len 446
           Split a 446 long packet into two (16 + 430).
           INcrease pkts from 0 to 1 (16 + 430), chain size: 446
           Insert extra:Client-Cert: CwAELgAEKwAEKDCCBCQwggMMoAM(len:1447)
           Out: Increase pkts from 0 to 1 (16 + 1877), chain size: 1893
           Append 2(len: 1893) pkts to 0(len: 0) pkts.
           Save c.rx 0 s.tx 0pkts, wait for server conn.
           Append 2(len: 1893) pkts to 0(len: 0) pkts.
           Send 0 pkts with 2 old ones on s.tx to server
   S 3224: REQ_SENT(6), data 1= 324,<-
           forward to client
           Free single stored packets (0/0).


Tips and Caveats

Various Insertion modes

There are three insertion modes:


  • Entire chain: the entire chain including the leaf certificate will be inserted, in BASE64 encoded form.
  • Leaf certificate: only the leaf certificate will be inserted in BASE64 encoded form, even though the certificate chain is present.
  • Parsed Fields: the important information of the client certificate will be retrieved and inserted as the HTTP headers, in plain text.

If the parsed fields mode is chosen then the following headers will be inserted:


  • "Client-Cert-Version"
  • "Client-Cert-Serial",
  • "Client-Cert-Start"
  • "Client-Cert-End"
  • "Client-Cert-Subject"
  • "Client-Cert-Subject-CN"
  • "Client-Cert-SubjectAlt-CN"
  • "Client-Cert-Issuer"
  • "Client-Cert-Issuer-CN".

The required configuration is:


   config term
     server virtual vip1
       port ssl request-insert client-cert parsed-fields

A sample of an HTTP request captured on a real server is given below.


   GET / HTTP/1.0
   Client-Cert-Version: 2
   Client-Cert-Serial: 10
   Client-Cert-Start: 070620210616Z
   Client-Cert-End: 170617210616Z
   Client-Cert-Subject: commonName=Client Certificate issued by Level_0; organizationName=FDRY OpenSSL PKI; organizationalUnitName=l47;
   Client-Cert-Subject-CN: l47
   Client-Cert-Issuer: commonName=OS Level_0 CA;
   Client-Cert-Issuer-CN: OS Level_0 CA
   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070515 Firefox/
   Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   Accept-Language: en-us,en;q=0.5
   Accept-Encoding: gzip,deflate
   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   Keep-Alive: 300
   Connection:      close
   Pragma: no-cache
   Cache-Control: no-cache

The default header name is Client-Cert, but it can be changed to any prefix. For example, Incoming-Client-Cert. The command would be:


server virtual vip1
   port ssl request-insert client-cert prefix "Incoming-Client-Cert"


Further Reading

by Asif_Taj85
on ‎09-08-2014 09:49 PM

If a client  has two microsoft exchange servers and brocade adx 1000/100f serveiron is installed as a load balancer. The load balancer is connected with router in upward direction while downwards it connects with cisco switch and then cisco switches connects with two microsoft exchnage server. Should the serveriron present the ssl header to the exchnage server to see client ssl certificate information?