Some Useful Diagnostic Commands

[brites]

The following is a succinct list of simple Linux command line commands that can be helpful when investigating why calls might be arriving at your newly deployed proxy. You may need to install some tools such as 'jq'.

Check connections are going through

Replace the host/domain/IPs/ports below with your own.

Replace the path with that of your proxy.

$ telnet api.domain.co 443
$ telnet 12.3.45.6 443
$ dig api.domain.co
$ curl -v -k --resolve api.domain.co:443:12.3.45.6 https://api.mydomain.co/v1/prx/

Check if telnet can establish any connection. If not, then it will likely be a networking or firewall related issue.

Check that dig's CNAME entry looks to be correct (it should be an apigee DN if you're on Edge Cloud), and check the A Record is the IP address you expect (if you're on Private Cloud).

The curl command here will let you enter your virtual host's host alias and force it to resolve to your expected IP address. It will also pass in appropriate SNI and Host Header information so that the call arrive at the appropriate Apigee virtual host in your org/env. This command's 'k' option will let it ignore SSL certificate validity issues.

-k ignores the client-side certificate validation

you can also try the below commands.

tracert api.domain.co

pathping api.domain.co

Check the SSL certificate

Replace the domain below with that of your virtual host / proxy

$ openssl s_client -showcerts -connect api.mydomain.co:443 </dev/null | openssl x509 -text

Check the 'CN', 'Subject Alternative Name' matches that of your virtual host's host alias.

Check the `validity` period (from date and expiry date) is correct.

Run a quick simple check that your certificate file contains the appropriate certificate chain. If you are using the one file for both your domain/leaf certificate and intermediate certificates.

Replace both instances of the file name below, with the certificate file contain the certificate chain.

$ openssl verify -CAfile CERTFILE.pem CERTFILE.pem

Use the Edge Management API to check the proxy's deployment status

Consider using environment variables for the Auth portion of the command. Examples below

Of course, substitute/enter your own credentials above.

Replace $ORG, $ENV and 'prx' with your own Apigee Organization, Environment, and the name of your proxy. Or just define these as environment variables.

# All environments:
$ curl $AUTH -v https://api.enterprise.apigee.com/v1/o/$ORG/apis/prx/deployments

# For a specific environment:
$ curl $AUTH -v https://api.enterprise.apigee.com/v1/organizations/$ORG/environments/$ENV/apis/prx/deployments

The first curl command API call give the deployment status across all environments within your organization. The second, for just the specified environment.

Check that you don't have the same Virtual Host Alias & PORT used twice, anywhere

Replace $ORG , $ENV if you haven't already defined them as environment variables.

Make sure the $AUTH environment variable is still correctly defined (from above).

$ curl $AUTH https://api.enterprise.apigee.com/v1/organizations/$ORG/environments/$ENV/virtualhosts | jq -r -c '.[]' | while read i; do curl -s $AUTH https://api.enterprise.apigee.com/v1/organizations/$ORG/environments/$ENV/virtualhosts/$i ; done | grep -B 5 -E "port.*443" | grep hostAlias | sort

This command requires that 'jq' be installed. Run this for each environment you have.

It will print out all host alias for all virtual hosts defined in your environment, listening on port 443 .

Check that no host alias appears twice, anywhere. Having a host alias appear twice could lead to requests unpredictable going to one virtual host or the other.