Amazon Root Certificates not able to validate chain
Article ID: 261134
Updated On:
Products
Issue/Introduction
There are calls to a service that uses Amazon CA certs but the Root certs aren't being recognized as trust anchors. It seems only the Intermediate or Leaf certs work.
2023-02-22T12:11:58.365-0500 INFO 379 com.l7tech.common.http.prov.apache.components.SsgDefaultHttpClient: I/O exception (java.io.IOException) caught when connecting to the target host: SSL verification failed!
2023-02-22T12:11:58.366-0500 INFO 379 com.l7tech.common.http.prov.apache.components.SsgDefaultHttpClient: Retrying connect
2023-02-22T12:11:58.542-0500 INFO 379 com.l7tech.common.http.prov.apache.components.SsgDefaultHttpClient: I/O exception (java.io.IOException) caught when connecting to the target host: SSL verification failed!
2023-02-22T12:11:58.542-0500 INFO 379 com.l7tech.common.http.prov.apache.components.SsgDefaultHttpClient: Retrying connect
2023-02-22T12:11:58.729-0500 INFO 379 com.l7tech.common.http.prov.apache.components.SsgDefaultHttpClient: I/O exception (java.io.IOException) caught when connecting to the target host: SSL verification failed!
2023-02-22T12:11:58.729-0500 INFO 379 com.l7tech.common.http.prov.apache.components.SsgDefaultHttpClient: Retrying connect
2023-02-22T12:11:58.915-0500 INFO 379 com.l7tech.server.message: Processing request for service: test [/test]
2023-02-22T12:11:58.916-0500 WARNING 379 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: 4042: Problem routing to https://<HostName>. Error msg: Unable to obtain HTTP response from https://<HostName>: SSL verification failed!
2023-02-22T12:11:58.916-0500 WARNING 379 com.l7tech.server.MessageProcessor: 3016: Request routing failed with status 601 (Error in Assertion Processing)
2023-02-22T12:11:58.916-0500 WARNING 379 com.l7tech.server.message: Message was not processed: Error in Assertion Processing (601)
Environment
API Gateway 10.X
Resolution
Consider the following:
=ACTORS=
Client cert => child
Intermediate cert => parent
Root cert => grandparent
SCENARIO 1: The intermediate and client cert is added to the cert store. The client cert has a different hostname than the server name. The io.httpsHostVerify CWP is set to true (meaning it should fail on a hostname mismatch). Routing succeeds in this scenario.
[SCENARIO 1 FEEDBACK] Because the parent is the immediate signer of the child, the gateway allowed the routing. Even though the CN/hostname was mismatched, we trust the parent so we trust the child. In this scenario, the io.httpsHostVerify CWP is not in play (true or false, we do nothing with it).
SCENARIO 2: The root and client cert is added to the cert store. The client cert has a different hostname than the server name. The io.httpsHostVerify CWP is set to true (meaning it should fail on a hostname mismatch). Routing fails in this scenario.
[SCENARIO 2 FEEDBACK] When you remove the parent and add the grandparent, the trust is broken because the grandparent is not the immediate signer of the child. We don't trust the grandparent so we don't trust the child. In this scenario, we DO consult the io.httpsHostVerify CWP because the grandparent is seen as untrusted.
==================================
If you import all three certs (child/parent/grandparent), the gateway should allow the routing because all of the immediate signers are present and trusted.
Feedback
