potential Policy Manager issue

[Michael Mueller]

Dear Team.

I'd like to double check my understanding: It seems, I encountered an issue with the Policy Manager handling the http(s) routing  assertion.

There are four different scenarios regarding to key usage in an http(s) routing assertion, I am looking at

1. no key at all
2. use the default ssl key
3. use a dedicated key from the key-store
4. using a dynamic key, using a variable which points to a key-alias.

I was looking at the xml representation of this assertion, especially when you switch from one scenario to another.

I observed, when you've specified a dedicated key once, the related key data is kept in the xml representation forever.

That means you cant go back to the 2nd scenario ( use default ssl key) anymore. So even if you change the assertion settings, the key specified once will still be in use.

Gateway version : 11.1.3

Policy Manager version : 11.1.3.21907

If this is considered as an incorrect behavior I'd be happy to create a support ticket to handle it.

Just want t get your input first.

Thanks

Best regards

...Michael

-------------------------------------------

[Joseph Fry]

I was able to reproduce this on 11.2 as well.

I created a policy with only a routing assertion, observed that the XML in the databasae has no <L7p:NonDefaultKeystoreId goidValue="..."/> lines.
I set it to use a specific certificate, and the revised policy included that line.
Upon setting it back to use default, that line remained.

HOWEVER

In addition to that line, a line <L7p:UsesDefaultKeyStore booleanValue="false"/> is also created when assigning a certificate, and this line is deleted when reverting back to the default certificate.

I believe that there is no functional defect.  I do not understand why the NonDefaultKeystoreId value remains when the policy is set to use the default, however without UsesDefaultKeyStore=false I suspect it it is ignored.

If there is some concern about this information remaining in the policy, or you observe that the gateway actually uses the wrong certificate, please open a ticket.

-------------------------------------------

[Michael Mueller]

Hi Joseph.

You are completely right. Thanks a million for looking into this.

I did some concrete tests , with checking the incoming client certs, and did some key selection changes on the sender side.

It did not reveal any misbehavior and that's the most important point.

I was looking at xml code to find references to hardcoded keys with a very simple approach by grepping for keyAlias tags in xml-code only:)

This has worked in the past (pre 11.1), but does not work anymore. So the condition to check, if a key is in use, got more complex.

Again thanks for confirmation !

Best regards

...Michael

-------------------------------------------