Can not access flow variables related to TLS

[#1]

I have configured the two way TLS. I want to get the client certificate serial number in javascript policy and from the documentation it seems that there are certain flow variables available including tls.client.cert.serial but when I try to read this variable in javascript policy using

sn = context.getVariable("tls.client.cert.serial")

the value of sn is null. On the other hand I can read the client.cn successfully using

cn = context.getVariable("client.cn")

This page https://docs.apigee.com/api-platform/system-administration/tls-vars#capturing-tls-connection-informa... say that flow variables are available but I am not able to read them. Is there a specific way to read them?

Thanks

[deboraelkin]

I'm assuming your running Edge Cloud. If so, have you configured your virtual host to propagate client cert properties?

The virtual host should include the following:

<PropagateTLSInformation>
        <ConnectionProperties>true</ConnectionProperties>
        <ClientProperties>true</ClientProperties>
</PropagateTLSInformation>

[#3]

These configuration are already in place.

[joshuacarino]

Is this XML Configuration the same as ticking this TLS Information to Enabled in the Apigee Cloud UI?

[dchiesa1]

No. I think you need to check the vhosts via the API.

[joshuacarino]

Okay, thanks. But is there any way we could make modifications on the Virtualhost on the personal/evaluation account?, like requesting access to it maybe?. its just that we are currently developing APIs to a paying organization that wants to do a custom 2-way TLS implementation but the paid organization won't allow us access to configuration functionalities such as this one to be able to provide them an accurate installation guides. They say they should be the one doing it and we just need to provide them the steps to configure it. Our company, even though a vendor of Apigee, doesn't have a paid organization to where we could do Research and Development and provide them this installation or configuration guides. Ofcourse developers without access to this configurations is like giving directions to a place for a blind man really. It is not as if those in the paid organization knows how to do this things too as they are new in Apigee either. 😕

[dchiesa1]

Ahhh, I'm sorry, that sounds difficult.

I think if you're a vendor/reseller, you really want to get a "paid" (not trial) Apigee organization. Maybe talk to your partner representative.

And,

I think if you want to try out 2-way TLS... what you need to do is create a new vhost. And then apply the correct SSL configuration to that vhost. Is that not possible in trial orgs? If not... then.... you need a paid organization.

I'm not aware of all of the limitations in the Apigee trial subscriptions.

[#8]

@Dino. I see the version is180630 on edge cloud

[dchiesa1]

Your JavaScript looks correct.

You need to check all the things!

• The VHost has Enabled = true and ClientAuthEnabled = true
• The VHost has the PropagateTLSInformation element and the ClientProperties is true. Check for misspellings, which will be accepted silently.
• The API Proxy in question is using the specified Vhost
• The client is invoking the API proxy via a host alias that is specified in the secure vhost. (It is possible to configure an API Proxy to listen on more than one vhost. In which case, it will be possible for the client to invoke the API Proxy with either vhost. If the client uses the insecure vhost, it will not pass its cert, and you won't see the variables)
• The client is actually passing its certificate. (If you have all of the above configured, and the client didn't pass the cert, you'd see a runtime error during the API request)
• That's all I can think of.

We might be able to help a little more if you post

• your vhost configuration in its entirety
• a description (code?) for how you are invoking the Proxy form the client side

[#10]

- This is the VHost configuration I get by calling the GET /virtualhosts

{
  "hostAliases": [
    "xxxxx-twoway.xxxxxxxxxxxx.com"
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "twoWay",
  "port": "443",
  "propagateTLSInformation": {
    "clientProperties": true,
    "connectionProperties": true
  },
  "retryOptions": [],
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "true",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "xxxxxxxxxxxxxxxxxx.com",
    "keyStore": "ref://north",
    "protocols": [],
    "trustStore": "ref://northTrustStore"
  }
}<br>

- The proxy has only one host specified which is "twoWay"

- Client is using the correct VHost as there is only one VHost and api is returning a proper response.

- I am sure the client is passing the certificate becasue the following statements print correct information when used in a javascript policy

print("--Client CN : " + context.getVariable("client.cn"));

print("--Client ORG : " + context.getVariable("client.organization"));<br>

- The values for following is null is the same proxy as above

print("--Client CERT" + context.getVariable("tls.client.cert.serial"));


print("--TLS Protocol" + context.getVariable("tls.protocol"));

- I am using postman to send the request

[dchiesa1]

I see. Everything looks right on that vhost. If the client is getting a proper response, it's possible the documentation for the TLS variables has ben released early, before your router has gotten the update.

I cannot confirm for you if your router and MP's have gotten the update required that would allow you to read variables like tls.protocol and tls.client.cert.serial .

Only Apigee Support staff can tell you this. Can you open a ticket with them to inquire? Also whether you use ELB and SNI may .... affect the availability of these variables. Apigee Support can help you sort it out.