SSL Handshake error with 2-way SSL backend

Not applicable

I am trying to create a proxy to a backend that requires Client Authorization. Using curl from the message processor host, I tested the handshake using the certificate & key files that were put into the jar which is in the keystore & alias referenced in my proxy. As a test, we have also confirmed that the proxy works if the backend does not require client auth. I enabled debug on the message processor but it did not reveal much more than the error below. Any ideas?

16:00:31.684 [SSL Compliance Test NIO Thread] ERROR SSL_COMPLIANCE - STATIC-TARGET[/organizations/org/environments/dev-int/apiproxies/PROXY], SSLDetails[enabled:true, clientAuthEnabled:true, keyStore:dev-int_client-keystore, keyAlias:dev-int_key, trustStore:ref://dev-int_truststoreRef, crlStorenull, commonName:null, useWildCardMatch: false,ciphers: [], protocols: [], ignoreValidations: false] Remote side closed connection

Solved Solved
1 9 2,447
1 ACCEPTED SOLUTION

Not applicable

We determined that the target server was not presenting the entire certificate chain in it's list of acceptable client certificates. After adding the intermediate and root certificates to the server's truststore Apigee was able to select and send the proper client cert and establish a connection.

View solution in original post

9 REPLIES 9

Can you provide the HTTPTargetConnection you are using in the proxy. Feel free to anonymize it as required.

Here it is:

<HTTPTargetConnection>
<URL>https://site.domain.com:8205/</URL>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyStore>dev-int_client-keystore</KeyStore>
<KeyAlias>dev-int_key</KeyAlias>
<TrustStore>ref://dev-int_truststoreRef</TrustStore>
</SSLInfo>
</HTTPTargetConnection>

For reference here is the curl I used to test the cert:

curl -vk --cert dev-int.cer --key dev-int.key https://site.domain.com:8205 2>&1 | grep 200
< HTTP/1.1 200 OK

You cannot test the certificate with -k curl option. That's --insecure option which ignores any tls errors.

@ylesyuk the results are the same if I provide the cacert that is in my proxy's truststore:

curl -v --cacert target_cert.cer --cert dev-int.cer --key dev-int.key https://site.domain.com:8205 2>&1 | grep 200<br>< HTTP/1.1 200 OK

Hi @cmoser

Did you try using a target server with the same ssl info object ? Also try extracting a tcp dump at client side to see if the ssl handshake messages were exchanged properly


I tried adding a target server with the same results. I will work on getting the packet capture. Thanks!

Not applicable

Using openssl, I also tried testing specific protocols and ciphers:

openssl s_client -msg -CAfile target_cert.cer -cert dev-int.cer -key dev-int.key -tls1 -cipher DHE-RSA-AES256-SHA -connect site.domain.com:8205 | grep TLS
>>> TLS 1.0 Handshake [length 0035], ClientHello
<<< TLS 1.0 Handshake [length 0051], ServerHello
<<< TLS 1.0 Handshake [length 0429], Certificate
depth=0 CERT
verify return:1
<<< TLS 1.0 Handshake [length 020c], ServerKeyExchange
<<< TLS 1.0 Handshake [length 0156], CertificateRequest
<<< TLS 1.0 Handshake [length 0004], ServerHelloDone
>>> TLS 1.0 Handshake [length 076e], Certificate
>>> TLS 1.0 Handshake [length 0086], ClientKeyExchange
>>> TLS 1.0 Handshake [length 0106], CertificateVerify
>>> TLS 1.0 ChangeCipherSpec [length 0001]
>>> TLS 1.0 Handshake [length 0010], Finished
<<< TLS 1.0 ChangeCipherSpec [length 0001]
<<< TLS 1.0 Handshake [length 0010], Finished
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Protocol : TLSv1

But adding the following to my SSLInfo did not change the behavior:

<Ciphers>
<Cipher>TLS_DHE_RSA_WITH_AES_256_CBC_SHA</Cipher>
</Ciphers>
<Protocols>
<Protocol>TLSv1</Protocol>
</Protocols>

Not applicable

We determined that the target server was not presenting the entire certificate chain in it's list of acceptable client certificates. After adding the intermediate and root certificates to the server's truststore Apigee was able to select and send the proper client cert and establish a connection.

michaelveit
Participant III

In my case it failed as I was uploading all certificates of the trust chain in a single PEM file. Trying empty lines in-between certificates, or changing from CRLF to LF line breaks did not help.

The truststore issue only occurred in connection from message processor to endpoint! Virtual host did not run into this issue.

Solution was to upload all certificates separately into the truststore:

  • One call to create the truststoere
  • Serveral calls to upload all certificates into the truststore
  • One call to create the reference for the truststore
  • Use truststore reference in your proxies

The mechanism for uploading all certs in a single file according to official documentation does not work and runs into SSL handshake errors:

https://docs.apigee.com/api-platform/system-administration/creating-keystores-and-truststore-cloud-u...

It was really time consuming to drill down this error, as any usage from openssl, curl or other Apigee components succeed, but only the message processor fails with the single PEM file approach.