* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com

* Podcasts
* Social Channels
* Video Streaming

 

 

 

 

 

ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

Hello all,

Anyone capable of giving me the meaning of session.ssl.cert.valid with value 20 ?

I found some informations about this field, but not the possible values, that would help a lot

Regards,

Hello all,

Anyone capable of giving me the meaning of session.ssl.cert.valid with value 20 ?

I found some informations about this field, but not the possible values, that would help a lot

Regards,

The F5 Certification is excited to announce that all five of the NEW F5 Certified BIG-IP Administrator Certification (F5 CAB) exams are now live and available to schedule via the new Education Services Portal.

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 {\n\nif {[SSL::cert count] > 0}{\n    if { [SSL::verify_result] == 0 }{\n         valid cert\n    } else {\n         Use the SSL status code in the HTTP response (defined here: http://www.openssl.org/docs/apps/verify.htmlDIAGNOSTICS)\n\n        set error_string [X509::verify_cert_error_string [SSL::verify_result]]\n        log local0. \"AUTH-CERT-NOK error_string = $error_string\"\n    }\n}\n}

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

• \n

  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

  \n

  CA root -> end entity\n

  \n\n

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

  \n

  CA root -> Subordinate CA -> end entity\n

  \n\n

  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.

  \n

.

• 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]\n

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-----\n\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\n\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\n\n-----END CERTIFICATE-----\n

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

RCA1\nSCA1\n

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:\n

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)

Could simply be an mcpd validation error. What is the policy doing, and what happens if you try to remove the policy first, change the SSL profile, and then re-add the policy?

I was about to do exactly that, but I do not really know what this policy is doing, and I am afraid that I will not be able to re-add the policy :)

May I check something particular in the policy ?

Nothing looks out of the ordinary. So can you replicate this behavior on a \"dummy\" VIP so that you're not affecting production traffic?