iRules for SSL certificates

[IvanKusturic]

Hi everybody,

We have a client who is hosting three FQDN's on same web server. In order to deliver correct SSL certificates based on the server name, we have configured SNI, with three different profiles. Configuration is done per this article:

https://support.f5.com/csp/article/K13452

and we used iRule from the same article:

when HTTP_REQUEST {

  set hostname [getfield [HTTP::host] ":" 1]

}

when SERVER_CONNECTED {

  switch -glob [string tolower $hostname] {

  "siteA.com" {

    SSL::profile serverssl-siteA

  }

  "siteB.com" {

    SSL::profile serverssl-siteB

  }

  "sitec.com" {

    SSL::profile serverssl-siteC

  }

 default {

#default serversssl profile to be selected if Host header value cannot be matched with predefined values

  SSL::profile serverssl

 }

}

}

Everything is working as it should. But we have additional request:

1. siteB should require two way SSL authentication when accessed via siteB/admin/ URL 

Could someone advise us regarding iRule that would offer this functionality?

Thanks in advance,

Ivan

[Simon_Blakely]

You need to use SSL::renegotiate and something like

when CLIENTSSL_HANDSHAKE {
  if { [SSL::cert count] > 0 } {
    if { $http_collected eq 1 } {
      HTTP::release
      set http_collected 0
    }
  }
} 
when HTTP_REQUEST {
  if { ([HTTP::host] eq "siteB.com") && ([HTTP::uri] starts_with "/admin/") } {
    if {[SSL::cert count] == 0} {
      set http_collected 1
      HTTP::collect
      SSL::session invalidate
      SSL::authenticate always
      SSL::authenticate depth 9
      SSL::cert mode require
      SSL::renegotiate enable
      SSL::renegotiate
    }
  }
}

Note: this is a modified example from the SSL::renegotiate page, and has not been tested, so YMMV

[IvanKusturic]

Hi Simon,

Thank you very much for the reply. We will try this solution and see how it works. One thing bothers me though: if we want to use end to end encryption from client to backend server (client -> F5, F5 -> web server), we were suggested to use Certificate Constrained Delegation. In that case we have to enable C3D in both SSL profiles: client and server. Do you know where to specify that in iRule, and what would be the syntax?

Thanks again.

[Simon_Blakely]

I guess SSL::c3d might be a start.

Otherwise, you might need to change both the client and server-side SSL certificates to ones configured for using C3D, and then renegotiate SSL on both the client and server side.

Just by way of explanation, C3D allows the details in a client auth certificate to be passed to the server-side SSL negotiation, by creating (forging) a new and valid server-side client authentication certificate based on the server certificate for the server-side TLS negotiation. This is only necessary when the pool member SSL stack needs to see those specific client auth certificate details (for authentication/auditing purposes). If you can get away with a single shared server-side client auth certificate, it's usually an easier option.

I haven't played much with C3D, so it's a bit of a speculative approach, but it's where I would start.

[IvanKusturic]

We first tried to configure two-way using only Client Authentication require setting and root CA under Trusted Certificate Authorities field but it didn't work. That's why we tried with C3D.

The customer is using self signed certificate as Root CA for issuing client certificates. Could that cause the problem with first approach?

[Simon_Blakely]

Without using C3D, you can get client certificate authentication from the client to the client-ssl profile, and use a shared static client authentication certificate on the server-side to the pool member.

What you cannot do is pass an individual client authentication certificate from the client-side to the server-side.

When establishing a TLS connection with a client-auth certificate, the client-auth certificate has to sign the handshake. But while the BigIP has the client auth certificate presented to it, it does not have the client auth certificate private key to sign the server-side handshake. C3D provides a way to generate a new certificate on the BigIP that matches the client auth certificate details so the server-side SSL profile can connect, present a client auth certificate that provides the right details, and can sign the handshake.

[IvanKusturic]

That make sense 🙂 one more question please. If we are to use one static client certificate, we would add that certificate together with a private key under server SSL certificate - certificate and key part at the beginning of profile configuration?

Thanks for help and clarification.