Forum Discussion

SRK_SAP_164849's avatar
SRK_SAP_164849
Icon for Nimbostratus rankNimbostratus
Jul 25, 2014

SSL Handshake error due to Enhanced key usage of client certificate

Hi,

 

client system: SAP ECC system connection type: RFC - type -G (HTTPS) Target system : F5 Load balancer and finally --> SAp Netweaver system. The SSL is termiated at loadbalancer. The target load-balancer has our certificate chain in its trust store. Our client SSL certificate is generated from the SAP system STRUST and signed by VeriSign Class 3 Secure Server CA - G3.

 

Parameters set at loadbalancer: Client Authentication --> Client Certificate == request Ciphers= DEFAULT

 

The load balancer rejects the connection telling below errors. local/tmm1 info tmm1[4963]: Rule client_cert_crossgate : Debug: cert_counter : 0 local/tmm1 info tmm1[4963]: Rule client_cert_crossgate : Debug: verify : 50

 

The reason told by the administrators are that our client certificate has multiple " Enhanced Key usage"- as given below. 1- Server Authentication (1.3.6.1.5.5.7.3.1) 2- Client Authentication (1.3.6.1.5.5.7.3.2) is this a valid reason? Is there an option to change this behavior of the load balancer, so that it accepts this type client certificates also?

 

regards, SRK_SAP

 

5 Replies

  • The extra EKU attributes shouldn't matter at all. In fact I just tested a client cert with these two values and it worked on my 11.5 lab system. I would suggest performing a client side ssldump and observe the SSL handshake for any errors:

    ssldump -k [path to private key] -AdNn -i 0.0 port 443 [and and additional filters]
    
  • Hi Kevin,

     

    is this behaviour controlled by any parameter settings in the LB? Maybe in your test environment it is enabled to accept teh multiple EKU of ssl certificate.

     

    regards, SRK

     

  • Most of the settings in the client and server SSL profile deal with how to handle the cryptographic functions on an SSL session. It is entirely possible to "filter" on an EKU value, but something you'd have to go out of your way to build. I'm using a simple client SSL profile in my testing with default values. Does your CA certificate (or and CA in a chain of CAs) apply any policy constraints? If the administrators are telling you that Server Authentication is not allowed, there may be an Application Policy defined in one of the CAs that specifically defines this.

     

    http://technet.microsoft.com/en-us/library/cc737026%28v=ws.10%29.aspx

     

    This may also be a good time for something a bit stronger than an ssldump. Your best bet is to install WireShark and capture the SSL/TLS data. If you provide it the private key used in the client SSL profile, it can decrypt the traffic as well. An ssldump capture can do the same thing, but WireShark will give you much more information inside the SSL handshakes.

     

  • H Hi, we could find few points about the certificate used here from the vendor (CA)- Verisign. tAs per them, the given certificate can only be used by a webserver and not for client identification. Not sure about the procedure for certifying teh CSR generated from an SAp system for clinet authentication purpose..! The issue is temporarily solved by setting the Load Balancer client certificate check to disabled- “ SSL Client Certificate = Not required”.

     

    regards, Syam

     

  • Not sure about the procedure for certifying teh CSR generated from an SAp system for clinet authentication purpose..!

     

    i may be lost but if you already have client certificate, isn't it to import ca certificate which signs the client certificate to bigip and set it as trusted certificate authorities in clientssl profile?