For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

DR_19618's avatar
DR_19618
Icon for Nimbostratus rankNimbostratus
Oct 29, 2013

Mutual Auth Failing On Client Certificate Verification

I am trying to set up a VIP with mutual authentication where both the client and server verify each others identity. I was able to get this working with a self-signed cert by doing the following:

Server (F5):

Certificate - signed by intermediate of Certificate Authority 1 (CA1) which is signed by CA1

Key - private side of certificate above

Trusted CA Authorities - self-signed public certificate that represents the client's identity and intermediate of CA1.

Advertised Certificate Authorities - self-signed public certificate that is in Trusted CA Authorities

Client (java client):

Trust store containing cert for CA1

Key store that contains the self-signed private/public key pair that identifies the client.

I cannot however get this to work with a publicly signed client certificate as described below:

Server (F5):

Certificate - signed by intermediate of CA1 which is signed by CA1 (same)

Key - private side of certificate above (same)

Trusted CA Authorities - public certificate that represents clients identity (signed cert) and intermediate of CA1.

Advertised Certificate Authorities - certificate of CA2 (signer of client cert)


Client:

Trust store containing cert for CA1 (same)

Key store that contains the signed private/public key pair that identifies the client (signed by CA2).

If I replace the signed public client cert in the Trusted CA Authorities file with the cert of CA2 it works fine, but this is not the way I would like it considering anyone with a cert signed by CA2 (which happens to be Verisign) could use the service. Is this because the certificate I supplied in the Trusted CA Authorities file is not truly a certificate authority - meaning it isn't the CA of the certificate the client presents (it is the certificate itself)? Is there another way to set this up? What am I missing?

management
security

2 Replies

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Oct 29, 2013

    The Trusted Certificate Authorities option is either a single certificate or text file bundle of certificates that represent the certifying authorities that the system uses to validate the client's certificate. This should be the complete chain of trust from the issuer of the client's cert, to that cert's issuer, and beyond until terminating at the self-signed root. Example:

    client cert -> subordinate CA -> subordinate CA -> root CA

    It might have worked before with the self-signed local certs because you were providing a "closed loop" of trust. The Advertised Certificate Authorities option is a single certificate or text bundle of certificates that the system will use to "hint" to a certifying path. For example, let's say Verisign's root signs/issues two subordinate CAs which in turn sign/issue various client and server certs. The client may have certificates installed from both subordinates. The path hint tells the browser which path the server is expecting. To filter to only certs issued by the first subordinate, the Advertised Certificate Authorities option would ONLY contain this subordinate CA cert.

    With respect to filtering to a subset of certificates within the same issuance, you would need to allow all for validation, and then post-filter with an iRule.

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Oct 30, 2013

    There is only one cert with chain, not 3 certificates one for each client cert -> subordinate CA -> root CA. Is this what you are suggesting that I do?

     

    The F5 just needs to be able to validate the client's cert based on an explicitly defined trust list. If the client cert is signed by a subordinate CA, then that CA cert and its issuer, up to the root, should be in the Trusted Authorities bundle. If the client cert is signed by a root CA, then only that CA cert need be in the bundle.

     

    Letting clients through by establishing an SSL connection to be validated later by another rule seems sub-optimal. At the end of the day, it seems like signing client certs with a non-public authority is our best bet. That way you can be sure that only the certs you sign have access to the service. Thoughts?

     

    It really depends on who you are, what you're providing, and who it's being provided to. If you're a commercial or government entity trying to secure access to an application with client certificates, it may not make sense to also require a non-public authority and the overhead of its maintenance and distribution. For others who want more control, it might absolutely make sense. If you're getting your certs from a public CA, there's not much you can do other than filter after validation. This isn't an F5 limitation, but rather an inherent quality of the technology (PKI).

     

    I'd also probably argue that access to a service shouldn't be granted based solely on the existence and validity of a client certificate. If you're talking about smart cards or other hardware tokens that provides at least two factors of authentication, then you might be able to get away with it, but generally speaking a software-based certificate provides an identity assertion and non-repudiation. You should still make sure the identity asserted by the cert is a valid user in a system and has access to use the service - another filtering function that happens post certificate validation.