Need value for session.ssl.cert.valid

Hello,

session.ssl.cert.valid to determine the success or failure of the authentication process.

Please use this irule to have the exact error then check (it will allow you to determine your problem)

http://www.openssl.org/docs/apps/verify.htmlDIAGNOSTICS)

when HTTP_REQUEST {

if {[SSL::cert count] > 0}{
    if { [SSL::verify_result] == 0 }{
         valid cert
    } else {
         Use the SSL status code in the HTTP response (defined here: http://www.openssl.org/docs/apps/verify.htmlDIAGNOSTICS)

        set error_string [X509::verify_cert_error_string [SSL::verify_result]]
        log local0. "AUTH-CERT-NOK error_string = $error_string"
    }
}
}

If I may clarify further, the trusted and advertised CA lists are different.

• Trusted Certificate Authorities is a CA certificate or CA bundle that allows the F5 to validate the client certificate. PKI (public key infrastructure) defines "chains", where a self-signed "anchor" CA (root) issues a subordinate CA, which in turn may issue a "sub-subordinate" CA, which in turn may issue end entity certificates. In reality, the chain can be shorter

  CA root -> end entity
  

  But is rarely so, and minimally contains at least one subordinate,

  CA root -> Subordinate CA -> end entity
  

  but can absolutely be much more deeply nested. I've personally seen PKI chains over 11 long. The Certificate Chain Traversal Depth setting controls how deeply the F5 follows a longer chain. The chains are held together cryptographically by digital signatures - a hash value encrypted by the issuer's private key - so that validating a PKI chain means walking the chain and verifying the signature (with each issuer's public key) along the path. In the above example, CA root signs the Subordinate CA, and the Subordinate CA signs the end entity. To verify this chain, you first need access to all of the certificates, and that's where the Trusted Certificate Authorities bundle comes in. It needs to store all of the CAs and subordinate CAs that the F5 will need to complete the PKI chain from the client's certificate to the self-signed anchor. And if it doesn't have that list, you may get the error you're seeing. It is possible that the client can send some of the subordinate CAs in the TLS handshake (but never the root), but it's also possible that the client will not, so the F5 should have these CA certs anyway. In summary then, if your client certificates are issued by a subordinate CA, the Trusted Certificate Authorities bundle should include the Subordinate CA and the root CA, and any other CA certificates in the PKI chain.

.

• Advertised Certificate Authorities is simply a bundle that "hints" to the client which issuers are acceptable when sending a client certificate. It plays no part in the actual validation of the client certificate. Simply put, if you possess client certificates from multiple issuers, this bundle tells the client which certificate(s) it can use. Browsers will do this automatically - listing only the certificates that match the advertised issuers. Technically, in the TLS handshake, when the server sends its Certificate Request message to the client, it also sends a list of acceptable CAs, which in this case comes from the Advertised Certificate Authorities bundle.

You may also want to try an SSLDUMP on the client side to see if there are any obvious issues. You can post the results here if you want.

ssldump -AdNn -i [inbound vlan] port 443 [and any additional filters]

SSLDUMP on the F5 requires at least one filter option (ex. "port 443").

Okay, so just to be clear, you previously said,

RCA1 (called RCA1-CA) certificate issuer is self (since it is the root)

SCA1 (called xxx-SCA1-CA) issuer is RCA1-CA

And you had RCA1 as the trusted certificate authority and SCA1 as the advertised certificate authority. This is incorrect. You need BOTH certificates in a single bundle file and applied to the trusted certificate authorities selection. A bundle is a single text file that contains the PEM versions of multiple certificates. Example:

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

So in your case, you'd need to create a bundle file that contains:

RCA1
SCA1

The advertised certificate authority selection plays no part in the validation of the client certificate. The difference between the different browsers may have to do with whether or not these browsers have copies of both CA certs, and whether or not they send them in the TLS handshake. Most browser clients will send the client certificate, and any available subordinate CAs (but not the root CA) to the server, in case the server doesn't have these. If you do an SSLDUMP on the client side, you'll probably see the difference - some browsers will send the client cert only, and some will send the client cert and a subordinate CA (or CAs). The better option is to always have these CA certs available in the trusted bundle, not relying the client to send them.

Kevin, just for my information, I have the same problem on another Virtual Server, so the idea was to do exactly the same, but there is an Application Security Policy on this VS.

When I change the setting (same change as for the other), I have this error:

Is this some kind of a bug ? I do not get what could be the problem with the security policy (it is only a SSL client profile change)