Forum Discussion

soymanue's avatar
Icon for Nimbostratus rankNimbostratus
Apr 05, 2011

Certificate Authentication issue with Firefox 4



We have a SSL site. Once you have connected, you must get authenticated to access a a part of the site. You can be authenticated with user and password, but you can also choose to be authenticated with a certificate.


To do that whe have this iRule (based on an example found in devcentral):




Initialize the variables on new client tcp session.




set collecting 0


set renegtried 0





Runs for each new http request





set uri [string tolower [HTTP::uri] ]


if { $renegtried == 0


and [SSL::cert count] == 0


and ([HTTP::uri] matches_regex {^/certauth.jsp$}) } {




set collecting 1


SSL::cert mode request









After a handshake, we log that we have tried it. This is to prevent


constant attempts to renegotiate the SSL session. I'm not sure of this


feature; this may in fact be a mistake, but we can change it at any time.


It is transparent if we do: the connections only work slower. It would,


however, make BigIP detect inserted smartcards immediately. Right answer


depends on the way the feature is used by applications.




if { $collecting == 1 } {


set renegtried 1


Release allows the request processing to occur normally from this


point forwards. The next event to fire is HTTP_REQUEST_SEND.









Inject headers based on earlier renegotiations, if any.




if {not ([catch {SSL::cipher version} result]) && $result ne "none"}{


clientside {


HTTP::header remove "WL-Proxy-Client-Cert"



if certificate is available, send it. Otherwise, send a header


indicating a failure, if we have already attempted a renegotiate.


catch {SSL::cert count } numbercerts


if { $numbercerts > 0 } {


set client_cert [SSL::cert 0]



HTTP::header insert "WL-Proxy-Client-Cert " [X509::whole [SSL::cert 0]]



HTTP::header insert "WL-Proxy-Client-Cert " [ join [string trim [string map { "-----BEGIN CERTIFICATE-----" "" "-----END CERTIFICATE-----" ""} [X509::whole [SSL::cert 0]] ] ] "" ]


log local0. "\[HTTP::header value WL-Proxy-Client-Cert\]: [HTTP::header value WL-Proxy-Client-Cert]"


foreach aHeader [HTTP::header names] {


log local0. "[IP::client_addr]:[TCP::client_port]: $aHeader \


([string length [HTTP::header value $aHeader]]): [HTTP::header value $aHeader]"




} elseif { $renegtried == 1 } {


This header has some debug value: if the FAILED header is not


present, BigIP is probably not configured to do client certs


at all.


HTTP::header insert "WL-Proxy-Client-Cert_FAILED" "true"






} else {


log local0. "\$result: $result. Redirecting unencrypted request."







After the upgrade to 10.2 the cert authentication stopped working until we enabled ssl renegotiation.Now we are suffering the same problem with Firefox 4: the certificate authentication doesn't work until we enable SSL Renegotation in the browser settings (



Is there any workaround? Is there any way to keep the certificate authentication without enabling SSL Renegotiation?



Thank you in advance



5 Replies

  • Colin_Walker_12's avatar
    Historic F5 Account
    I'm not sure I follow your issue. After the upgrade to 10.2 you started getting bad results? Can you give more details about what's happening and under what circumstances you're seeing failures? Are there any log entries?



  • Hi Manuel,



    Per this Firefox article,, Mozilla has implemented something clever to try to force websites who want to do SSL renegotiation to support RFC5746 (which fixes the SSL renegotiation vulnerability described in CVE-2009-3555).



    So I think the gist it is, until LTM supports RFC5746, FF4 clients will need to manually enable an option in the browser to allow connections to a virtual server which tries to initiate renegotiation. F5's ID for this issue is 223836. It is not currently fixed. If you'd like to escalate this I suggest opening a case with F5 Support and talk with your account manager.





  • Hoolio's right. No way around this until RFC-5746 support, unless you want to collect the client certificate as part of the initial SSL transaction (no more asking for cert only for certain URIs, then).



    The only other way I can see around this in the meantime is to set up another VIP/hostname with the clientSSL profile set to "require" the client certficate, and redirect users who migrate to the /certauth.jsp URI to the new VIP/hostname. You can then modify the iRule to remove URI detection and renegotiation and just set the WL-header values. If you want to get really fancy, you could do this just for Firefox 4 users via User-Agent.


  • I think we have RFC5746 support in v11.0 beta2. And I think there are plans for a 10.2.x hotfix. But more cases/account manager calls would probably help with the 10.2.x fix.



  • ID 223836 - TLS extension for secure renegotiation (Formerly CR 132172) is implemented in solstice/v11.



    i've already asked ES whether it's possible to have it in v10.x but haven't yet got answer.