Can't set TLS/SSL values dynamically in JavaScript policy

[annaku_rad]

I'm trying to set TLS/SSL details dynamically in a Javascript policy that's used in Shared flow, as described in the docs: 

https://cloud.google.com/apigee/docs/api-platform/reference/api-proxy-configuration-reference#tlsssl.... Specifically, I'm setting 

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>

When invoking the Proxy I keep getting 500 error:

{

    "fault": {

        "faultstring": "Target connection failed",

        "detail": {

            "errorcode": "entities.DynamicSSLEvaluationFailed"

        }

    }

}

I'm setting myvars.ssl.enabled in the beginning of my JS file:

context.setVariable('myvars.ssl.enabled', true);

but it seems in the DEBUG that it's not populated. Could you suggest how to set it dynamically?

[alistairnunes · Accepted solution]

Thanks for the quick response, Dino. We don't plan to turn TLS off completely, so I guess setting 'Enabled' to 'true' will work just fine. Just wanted to make sure we had the flexibility to manage it programmatically if required, in some really rare use case. Appreciate the help on this.

The way the variable was set was like this and it showed up as blank even though verifyapikey.VA-Verify-API-Key.ssl_enabled has the value 'true' in it.

var sslEnabled = context.getVariable("verifyapikey.VA-Verify-API-Key.ssl_enabled");
context.setVariable("sslEnabled" , sslEnabled);

[dchiesa1]

Hmmmm. That's frustrating.  It "should just work".  

I can suggest a few things to check, to make sure your attempt to set a variable is successful. 

• Check that your JavaScript syntax, the full file, is correct.  An exception during execution can cause the JS policy to not execute all statements.
• Check that the JS policy is "attached" to the flow, somewhere before your attempt to use the variable (whether in ServiceCallout or Target)
• Simplify the setup during diagnosis, omit everything extraneous.  Eliminate the shared flow, eliminate everything.  Verify that you can set a variable. Then add complexity (add in the SharedFlow, etc) to move toward your intended setup. 

When I try the very simple case, it works. 

My simple proxy that sets the variable is attached.

[annaku_rad]

I tried the simple setting and the same error happens. This is strange.. when I don't set the variable in the:

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>

And using instead:

<SSLInfo>
    <Enabled>true</Enabled>

I see myvars.ssl.enabled is populated, but when I set the <Enabled>{myvars.ssl.enabled}</Enabled> I see it's not populated:

Can this be related to the attaching of my JS Policy to the Proxy Pre-flow?

Btw, in your proxy I didn't see the usage of the variable in the JS Policy SSLInfo, and I wasn't able to attach here my Proxy (got 'The file type (.zip) is not supported.').

[dchiesa1]

I understand the words you've written, and it does not make any sense. 

The trace you showed indicates that the proxy is trying to READ the variable, and is finding no value. 

Are you sure that you have attached your policy and that it is executing before your Target references the variable ?

I suggest that you read again what I wrote above: Simplify. 

Step 1 Are you able to SIMPLIFY your proxy and verify that you can set a variable?  And the variable gets the value you expect? 

Step 2 Can you then reference that variable in a policy, or a condition, that is NOT the SSLInfo? Can you verify that is the case? 

Step 3: reference the variable in SSLInfo

Simplify, break it down.  Take it one step at a time. 

You should be able to diagnose this. 

[annaku_rad]

I simplified and broke this down as suggested, and got the same error:

1. Verify that you can set a variable- yes, I'm able and I see the expected true value: 

2. Reference that variable in a policy, or a condition, that is NOT the SSLInfo- I'm refencing this in a condition for executing RaiseFault policy and I see it works: 

3. Reference the variable in SSLInfo- when setting this I'm getting in the response the same error as in my initial post and seems the variable is not populated:

{
    "fault": {
        "faultstring": "Target connection failed",
        "detail": {
            "errorcode": "entities.DynamicSSLEvaluationFailed"
        }
    }
}

This is my JS Policy xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript continueOnError="false" enabled="true" timeLimit="200" name="Javascript-1">
  <DisplayName>Javascript-1</DisplayName>
  <Properties/>
  <SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>false</ClientAuthEnabled>
    <TrustStore>ref://myTruststoreRef</TrustStore>
    <IgnoreValidationErrors>false</IgnoreValidationErrors>
  </SSLInfo>
  <ResourceURL>jsc://set-Variable.js</ResourceURL>
</Javascript>

* By the way, the same happened when I attached the JS Policy to the Target PreFlow.

[alistairnunes]

Just wondering if there was any solution provided for this issue? I seem to be getting the same issue. And the value shows up blank only for the variable {sslEnabled} used within the <Enabled></Enabled> element. All other variables get set correctly as below which is probably why the error “entities.DynamicSSLEvaluationFailed" is displayed

<HTTPTargetConnection>
<Properties/>
<SSLInfo>
<Enabled>{sslEnabled}</Enabled>
<ClientAuthEnabled>{sslClientAuthEnabled}</ClientAuthEnabled>
<KeyStore>{sslKeyStoreRef}</KeyStore>
<KeyAlias>{sslKeyAlias}</KeyAlias>
<TrustStore/>
</SSLInfo>
<URL>https://mock.target.com/token</URL>
</HTTPTargetConnection>

[alistairnunes]

The call works successfully if the HTTPTargetConnection is changed to 

<HTTPTargetConnection>
<Properties/>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>{sslClientAuthEnabled}</ClientAuthEnabled>
<KeyStore>{sslKeyStoreRef}</KeyStore>
<KeyAlias>{sslKeyAlias}</KeyAlias>
<TrustStore/>
</SSLInfo>
<URL>https://mock.target.com/token</URL>
</HTTPTargetConnection>

[dchiesa1]

Hey, I'm glad you shared that last bit of information. Is there a real reason you want to "turn TLS off" or otherwise "support either using TLS or not" ?

I understand that you've found that using a variable reference like <Enabled>{sslEnabled}</Enabled> is not working as you expect. But do you NEED that capability? I can imagine situations where you'd want to enable or disable client authentication, or modify the keystore and truststore. But ... I am having a harder time imagining a real scenario in which you want to turn TLS completely off.

Having said that, if you DO think you really need this, I believe the <Enabled>{sslEnabled}</Enabled> is expecting a string. You may be able to avoid the "Internal error" by insuring that the variable you reference is a string:

context.setVariable('sslEnabled', true); // no
context.setVariable('sslEnabled', "true"); // yes

[alistairnunes · Accepted solution]

Thanks for the quick response, Dino. We don't plan to turn TLS off completely, so I guess setting 'Enabled' to 'true' will work just fine. Just wanted to make sure we had the flexibility to manage it programmatically if required, in some really rare use case. Appreciate the help on this.

The way the variable was set was like this and it showed up as blank even though verifyapikey.VA-Verify-API-Key.ssl_enabled has the value 'true' in it.

var sslEnabled = context.getVariable("verifyapikey.VA-Verify-API-Key.ssl_enabled");
context.setVariable("sslEnabled" , sslEnabled);

[alistairnunes · Accepted solution]

Just confirming the variable had a typo due to which the value fetched was being set to 'null' and hence nothing in context.setVariable("sslEnabled" , sslEnabled);

All good now.