how to get request.ssl.clientCertificatesChain

[Michael Mueller]

Dear Team.

I am trying to catch the incoming mtls client certificate chain.
My simple test policy looks like.

While "request.ssl.clientCertificate" is set as expected,
"request.ssl.clientCertificatesChain" is always null.

Any idea, what I am doing wrong here?

Thank you
Best regards
...Michael

[Joseph Fry]

I believe your Validate Certificate assertion must be set to "validate certificate path" or "revocation checking" before it will build the chain.

Let me know if that works and we can ask for clarification in the documentation.

[Michael Mueller]

Hi @Joseph Fry

Thank you. 

Whatever I specify in the Validate Certificate assertion as the Validation Type, I get no result for request.ssl.clientCertificatesChain.

The assertion parameters are looking like:

Hovering over the assertion presents:

Why I am trying this? I need to know, if a gateway routing assertion using a private keyfor mtls, does send a cert chain, including leaf and intermediate.

Btw. : Gateway version  is v11.1.3

Thanks for hints and tips

...Michael

[Joseph Fry]

Michael,

I was able to reproduce your issue in APIGW 11.0 (what I had handy).

I was using Bruno as the client, and confirmed via Debugging SSL/TLS that it was sending a full three certificate chain (root, intermediate, client certs).

Policy was failing chain validation until I added both the root and intermediate certificates to the gateway cert store; this is probably normal behavior.   Once the the intermediate was loaded, policy reported a valid path.

However, like you, nothing I did populated the request.ssl.clientCertificatesChain property.

I recommend opening a support ticket, as it is not behaving as documented.  If you do get a resolution from support, please share it here.

Joe

[Raju Gurram]

@Michael Mueller

@Joseph Fry

Not sure we support the request.ssl.clientCertificatesChain property. Do you think it is a functional gap? I'm wondering how did no questions raised in all these years! cc:  @Ben Urbanski 

Usually, clients get to know about the server's CA trusted certs list (from TLS handshake) and decides to continue if their cert is signed by one of them. In such cases, it seemed unnecessary knowing the entire cert chain.

If at all the client ignores the server's CA trusted list and continued further, it is necessary to validate the individual certs in the entire cert chain till we trust one in the list. So, I assume, you might be building the logic like below. 

For-Each cert in cer-chain

    At least

        All

            Validate the cert

            Set Context Variable validated to true

            break

        Continue

[Michael Mueller]

Thanks Raju.
And thank you, Joseph, for picking up my ask and doing your own tests.

Raju:
My ask is not about the client to check what he will send, but it's about the server to check, what is incoming.
Having access to the incoming chain would provide full transparency of the handshake on the gateway side.

I am wondering about two things.

1.) It's documented. Why, if it shouldn't be supported?

2.) Why is the "Validate Certificate assertion obviously able to validate the chain?
I would have expected that a chain variable gets set by the TLS assertion, because it's a connection&handshake thing, rather than a validation thing at a first glance. Similar to setting the request.ssl.clientCertificate var.


Anyway. Let me rephrase my ask.
The initial reason to look at this: I was looking for evidence, what chain is sent by a gateway as the mtls client cert(chain), when using the http routing assertion with a private key. 
To find evidence, I wanted to analyze the incoming cert and chain, if any. Hence, I was starting to look into it.
So, I was sending a request from the gateway (to send a mtls client cert from the gateway) to the gateway (to analyze what is incoming).

In general I am looking for neccessities
When the gateway sends a request presenting a mtls client cert outbound, do I need to add intermediates and root cert to the partner servers CA trust? Or would it be sufficient to just add the root cert? Yes, I know, that this relies also on the partner server validation.
But first I'd like to know what is sent by the gateway.

Thank you
Best regards
...Michael

[Raju Gurram]

@Michael Mueller

https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/api-gateway/11-1/reference/context-variables/credential-certificates-context-variables.html

You are correct, request.ssl.clientCertificatesChain property is specified in the above doc. Honestly, I didn't aware of this variable existence before. Neither I found the implementation traces for this. We can definitely treat it like a defect. Please open support ticket if you've not done already. 

Major input to the Validate Certificate assertion is a single cert (but not a cert chain). Using the gateway's trust store, this assertion builds the cert trust path for validation purposes.