Re: tls.client.s.dn is not accessible

SanalNaroor

I have added the following section to my virtualhost in Apigee following the sslinfo

"propagateTLSInformation" : {
"connectionProperties" : true,
"clientProperties" : true
}

I am still not seeing the tls.client.s.dn showing up in the trace. I also tried accessing X-apigee.tls.client.s.dn, same result. We are using the Apigee Edge.

I would really appreciate any input to understand this better.

ssvaidyanathan

@SanalNaroor - Can you check this post.

Also can you go a GET on the virtual host using the Apigee Management API and confirm the changes are there? Also please confirm that the virtual host is used by the proxy.

Also - there are some variables that gets populated only for two-way tls (mtls). Hope you are testing it using mtls as the variables you have mentioned are populated only for that use case - for more info

a_aleinikov

Hi @SanalNaroor ,

Even with propagateTLSInformation set in your virtual host, the variable tls.client.s.dn will only be populated if:
– Mutual TLS (mTLS) is enabled (clientAuthEnabled: true).
– The client actually presents a certificate when connecting.
– The presented certificate is successfully validated by the Apigee virtual host using the configured trust store.

to Debug:
✔ Check if the client is sending the certificate (use tools like openssl s_client or Wireshark to test the handshake).
✔ Ensure your Apigee Edge virtual host is correctly set up with the trustStore and keyStore to handle client certificates.
✔ Use Apigee Trace and confirm whether any tls.client.* variables appear — if they are missing, it usually means no mTLS handshake happened or it failed.

The X-Apigee. prefix is not needed; you should use the variable as tls.client.s.dn.

SanalNaroor

When I did a GET on the Virtualhost through api, I found that the section is setup as following even tough I have set the properties to true.

"propagateTLSInformation" : {
"connectionProperties" : false,
"clientProperties" : false
}

We are using Apigee on public cloud and its a paid org. Any thoughts on the reason behind the behavior.

Client authorization is set to true in the virtualhost and while testing I am passing a cert, trusted root of which is present in the trust store.

@ssvaidyanathan @a_aleinikov

dchiesa1

I found that the section is setup as following even tough I have set the properties to true.

It looks to me that you believe you set the properties to true, but you haven't. At least, Apigee doesn't think you have, and that's the only vote that matters. Double check your work. It's possible you set the properties on a different vhost. It's possible that you did not specify clientauthEnabled = true, and so the propagate TLS information is always forced to false. Or maybe there was some other problem. So, set the properties correctly and verify them. And then re-test.

Here's how you create a vhost with support for 2-way TLS and propagating client-side TLS information. That example uses XML. If you are using JSON it looks like this:

curl -X POST -H "Authorization: Bearer $TOKEN" \  
  https://api.enterprise.apigee.com/v1/o/$ORG/e/$APIGEE_ENV/virtualhosts \
  -H 'Content-Type: application/json' \
  --data-raw '{ 
    "description": "Virtual Host used for MTLS", 
    "hostAliases": [ 
        "'$MTLS_HOSTNAME'" 
    ], 
    "interfaces": [], 
    "listenOptions": [], 
    "name": "'$VHOST_NAME'", 
    "port": "443", 
    "retryOptions": [], 
    "sSLInfo": { 
        "ciphers": [], 
        "clientAuthEnabled": "true", 
        "enabled": "true", 
        "ignoreValidationErrors": false, 
        "keyAlias": "alias-of-key-to-use", 
        "keyStore": "ref://keystoreRef", 
        "protocols": [], 
        "trustStore": "ref://truststoreRef" 
    }, 
    "propagateTLSInformation": { 
        "connectionProperties": true, 
        "clientProperties": true 
    } 
}'

and here is how you check:

# check
curl -i -H "Authorization: Bearer $TOKEN" \
 -X GET "https://api.enterprise.apigee.com/v1/o/$ORG/e/$ENV/virtualhosts/$VHOST_NAME"