Virtual host not working in Apigee cloud

nikhilchawla
Participant III

Hi,

We defined a virtual host with empty base url with Host alias as service.XXX.XXXX.net

It was created successfully. When i tried testing it with TLS test, i'm getting below error :

Error Invalid Truststore. Unable to find valid certification path to requested target

certificate with key was added successfully with domain then intermediate then root CA. I'm not sure what else i'm missing.

0 9 747
9 REPLIES 9

Hi

can you show the VirtualHost configuration in its entirety?

$ curl -i -n $mgmtserver/v1/o/$ORG/e/$ENV/virtualhosts/$VHOST
HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 12 Oct 2018 18:49:15 GMT
Server: Apigee LB
Vary: Accept-Encoding, User-Agent
Content-Length: 396
Connection: keep-alive

{
  "hostAliases" : [ "service.foo.net" ],
  "interfaces" : [ ],
  "listenOptions" : [ ],
  "name" : "secure",
  "port" : "443",
  "retryOptions" : [ ],
  "sSLInfo" : {
    "ciphers" : [ ],
    "clientAuthEnabled" : "false",
    "enabled" : "true",
    "ignoreValidationErrors" : false,
    "keyAlias" : "freetrial",
    "keyStore" : "ref://whatisthis",
    "protocols" : [ ]
  }
}



I guess you are doing 2-way TLS, since the error referenced a TrustStore. Show the TrustStore ref you specified for the vhost.

Hi @Dino,

Thanks for the reply. Please see attachments.

vh-1.pngvh-2.png

ok, thanks for the additional information.

I think we are a bit confused, you and me both.

You mentioned your vhost configuration, but now that I am looking into the error message you're reporting, it is a target-specific error message.

I believe the error has nothing to do with the vhost.

What it is saying is :

you've configured your API proxy to connect to a backend system, and that connection is failing.

The reason it is failing is that the Truststore is ? invalid? Or in more detail, the truststore the Target is using, does not contain a certificate chain via which Apigee Edge can validate the certificate that is being presented by the target.

This is standard TLS operation. When a client, in this case Apigee Edge, connects to a target using tLS, then the target presents a certificate to the client. The client then validates the certificate to determine whether to trust it or not. There is a thing called a "trust store" or in some cases a "ceritifcate store" on each client. The client looks in that "store", which is really just a list of certificates. And then

  • if the client can find the target's cert, the target is trusted
  • if the client can find the cert of the SiGNER of the target's cert, then
    • if the signer is a root CA, then done.
    • otherwise, the client will recurse, and see if the client trusts the SIGNER. This recursion continues until the chain is followed to the end.

So I think you need to check the configuration of the SSLInfo on the target.

BTW, to verify that my diagnosis is correct, you can create a loopback proxy that listens on the same vhost. The loopback will connect to "nothing" therefore it will have no issues with TLS Truststores. If that loopback proxy works fine, then your vhost is correct.

Hi @Dino

This error is coming when i'm trying vis SSL test on Apigee cloud. Please see attachment for reference.

Also i created a no-target proxy with all 3 vhost (default, secure and new one). But that proxy is not reachable with new vhost.

My understanding is that i'm creating a northbound host with vhost. Back-end target is independent of this. Isn't it ?

Sorry about the delay.

Yes - good. You've got a no-target proxy and now you're isolating the problem.

you said: The proxy is not reachable with the new vhost.

What specific error do you see? There are multiple reasons why a client might not be able to connect to a proxy via a specific vhost. One possibility: none of the the host aliases used in the vhost are DNS resolvable.

Another possibility is that the vhost is configured for mutual TLS and the client is presenting an invalid or untrusted cert.

Another possibility is that the vhost is configured for 1-way or 2-way TLS, and the key presented by the vhost to the client is not trusted by the client.

There are probably other reasons I am missing. Let's track this down.

The next thing I want to see is:

- the specific error you see at the client with (curl -v)

- the specific error you see at the API Proxy, if any

- the full details of how you have the vhost configured (the complete output of curl -i /v1/o/ORG/e/ENV/virtualhosts/VHOST, as well as the output from the query of the keystore and the truststore, if any)

Hi @Dino

Thanks for the reply.

It is not able to resolve host. You are right when you are saying that new vhost is not DNS resolvable.

How can we resolve it? Proxy is working fine with other vhosts (default and secure).

Thanks

Nikhil

if you use curl aw the client, you can "trick" curl into resolving a name to a specific IP address like this:

curl -i --resolve api.hostalias.com:80:123.45.67.89 https://api.hostalias.com/proxy_basepath/etc 

You can also try to "trick" the router by passing a Host header, like this:

curl -k -i -H host:api.myhostalias.com http://123.45.67.89/basepath/etc

But the use of the -k means your curl client is ignoring the TLS cert presented by the server.

If you are not using curl then maybe you can apply the same reasoning to whatever client you're using. Maybe by hacking the /etc/hosts file on your client machine.

@Dino

Do we need a support ticket to restart edge router so that host alias can be mapped to Router's IP address ?

Thanks

Nikhil

nope - you shouldn't. Are you saying that the DNS entry DOES resolve to the correct address and the router is rejecting it? If that's the case then you need to contact support to troubleshoot it.

Sorry this is such a hassle.