Target Server SSL Error

Google Cloud Apigee
, ,
1

Hi @dchiesa1

I am stuck at one place I am getting the below error while trying to connect with the backend system using Target Server

“fault”: {

“faultstring”: “SSL Handshake failed java.security.cert.CertificateException: No subject alternative DNS name matching *********.com found.”,

“detail”: {

“errorcode”: “messaging.adaptors.http.flow.SslHandshakeFailed”

}

}

}

We tried two option as stated below:

OPTION 1

false https://******************.com/something true true

Working as expected and we are able to bypass the SSL Handshake Errors

OPTION 2

false true true /something

Not working and getting same SSL Handshake Error.

We created the Target server using the Management API call with the below payload.

{
“name”: “api-service-target-Endpoint-2”,
“host”: “***********.com”,
“protocol”: “http”,
“port”: “443”,
“isEnabled”: “true”,
“sSLInfo”: {
“enabled”: “true”,
“ignoreValidationErrors”: “false”
}
}

We tried almost everything to get it work along with Target server but it didnt, So kindly help us understand why it is Working with directly putting the URL in Httpconnection and not working while connecting through the same endpoint with Target server.

P.S: We are using APIGEE Hybrid

Thanks

2

We tried almost everything to get it work along with Target server but it didnt, So kindly help us understand why it is Working with directly putting the URL in Httpconnection and not working while connecting through the same endpoint with Target server.

I think the problem here is that the certificate presented by the target is not correctly identifying the target.

This error message:

No subject alternative DNS name matching *********.com found.

…tells you that. That’s a problem. It’s equivalent to signing on to mybank.com, and getting a certificate that says the site name is “hackerbank.com”. That is a trust violation, and a proper handling of the TLS would be to reject the connection. And that is what Apigee does by default. This is correct, and highly desirable behavior.

The addition of this element:

<IgnoreValidationErrors>true</IgnoreValidationErrors>

…tells Apigee to ignore that problem. It’s ok to do that when you’re in a development stage, but it’s a really poor idea when running in Production.

Moving on to the TargetServer definition, you have a similar option there; you can tell Apigee to ignore TLS validation issues. You did not enable that. You said the payload you used to create the target server is:

{
  "name": "api-service-target-Endpoint-2",
  "host": "***********.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "ignoreValidationErrors": "false"
  }
}

The “ignoreValidationErrors”: “false” here is the equivalent to the IgnoreValidationErrors in the XML, except here you used “false” which tells Apigee DO NOT IGNORE VALIDATION ERRORS. If you want to ignore them, you would change that to true.

But again, this is a Very Bad Idea.

Better to figure out what cert your target is sending back, and how the Subject DN or SANs differ from the hostname you are using to contact the target.

Summary of my advice: fix your cert issues, avoid telling Apigee to ignore SSL Validation problems.

3

@dchiesa1 Thanks Dino. Yes this is only in Non-Production, In Production we have right configurations in place for SSL.

Thanks Again