Layer7 API Management

Expand all | Collapse all

Validation of certificate path without importing all intermediates into GW

  • 1.  Validation of certificate path without importing all intermediates into GW

    Posted Feb 22, 2018 07:32 AM

    Hi I have a question that is somewhat similar to that of SefanKlotz on 6 Feb 18 but it is from the perspective of a client using mutual TLS auth to the gateway.

     

    We want to set up this mutual auth so that client certificates from multiple intermediates (multiple children of the root certificate) are trusted and can be checked by federated identity provider. It seems to me that we are obliged to import all of these intermediates which is painful since they are quite ephemeral in nature. Our engineers are proposing to stick apache in front of the gateway to get the behaviour we desire. Reason being that Apache's behaviour is more intuitive and in line with how lots of mTLS clients work.

     

    If a client receives a ServerHello with a certificate request in it then it looks to find a path to root:

     

    Client    <-- ServerHello { CertRequest (R1) } -- Server

     

    It will select (maybe with help of the user) a child certificate  of R1, if it has one, and respond with a proof that it possesses the private key. In the response it send the path to R1.

     

    Client -- ClientKeyExchage { certResponse (proof-of-possession, <<CertPathToR1>>) } --> Server

     

    In this way intermediates can change all the time without the server having to specifically trust them. It can trust the root and validate the path as presented by the client. All browsers do this. 

     

    Am I missing some bit of configuration in  the gateway because at first sight it does not seem possible to make it operate this way?

     

    Cheers

    - Steve



  • 2.  Re: Validation of certificate path without importing all intermediates into GW
    Best Answer

    Broadcom Employee
    Posted Nov 24, 2018 01:13 PM

    Steve,

     

    I've stepped through the scenario that you outlined and was able to duplicate the behavior. The gateway by default does not trust any certificate until it is imported into the gateway. There is a cluster wide property that can set to trust all certificates that are apart of the JAVA trust store ( pkix.useDefaultTrustAnchors : Should well known Certificate Authorities be included as Trust Anchors (ture/false) default = false). We many see this being used for outbound HTTPS connections through the HTTP routing assertion.

     

    When it comes to the FIP we are very pedantic about what is trusted for inbound users accessing the system. I agree that if we trust the CA then all its children should be trusted and if the client provides the chain outlining that trust hierarchy then we should allow it to work. I've created an idea on this Federated Identity Provider should support Root CA trust. Please review and add any additional details.

     

    Sincerely,

     

    Stephen Hughes

    Broadcom Support