Truststore not working even if the proper certificate is loaded

We have a new Virtualhost using 2-way-tls. And this new VHost has an existing reference to the actual truststore. But when I added a new certificate (second certificate) to the truststore, the api calls wont proceed and enter the API proxy and instead give me the ff. error.

<html>
<head>
 <title>400 The SSL certificate error</title>
</head>
<body>
 <center>
 <h1>400 Bad Request</h1>
 </center>
 <center>The SSL certificate error</center>
 <hr>
 <center>server</center>
</body>
</html> 

I've already checked and verified that the Virtualhost is pointing to the correct reference, the reference points to the correct truststore, the truststore contains the correct 2nd self signed certificate, and that the request I'm sending to the API has an attached self signed certificate in it that was minted with the root certificate we uploaded in the truststore. What else can we do to solve this problem?. Do we need to restart the apigee edge routers for this to work?. But we already use a reference in our Truststore. 😕

Solved Solved
0 9 884
1 ACCEPTED SOLUTION

Not applicable

Even you use the reference you have to restart rmps else you can refresh the reference as I said. The document says not required, but in practice it's required. We had almost 1 month discussion with Apigee support on this and finally, the refresh of reference workaround worked for us.

View solution in original post

9 REPLIES 9

ylesyuk
Participant V

> Do we need to restart the apigee edge routers for this to work?.

> But we already use a reference in our Truststore. 😕

Agree, with references you don't need to restart Routers.

> What else can we do to solve this problem?.

The error message is not too useful. It still can be many different reasons.

so two/three commands to run with all three parameters, considering you're troubleshooting mTLS:

openssl s_client

or

openssl s_server

with -CAfile, -cert, -key

to ensure that correct server and client certificates are served.

curl with -vvv and -debug and with --cert, --key, and --cacert

to get more diagnostics info on what is wrong with certificates.

I tried sending the request with a curl ....... --key ./keyfile.key --cert ./certificatefile.crt

And the ff. is the redacted output.

* TCP_NODELAY set
* Connected to api02.apigateway.uat.bdo.com.ph (18.138.118.224) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:

*  [HIDDEN]
*  SSL certificate verify ok.



> [Hidden]
< Connection: close
<
<html>
<head><title>400 The SSL certificate error</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The SSL certificate error</center>
<hr><center>server</center>
</body>
</html>
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):

Is there something wrong with this output?

Not applicable

Yes, in general if you add a certificate you need to restart the rmps to make it work.

As you are using reference, you need to refresh your reference. That is you need to do a PUT call on the reference, so that it will get refreshed. The same issue we faced and resolved as I wrote.

Not applicable

Even you use the reference you have to restart rmps else you can refresh the reference as I said. The document says not required, but in practice it's required. We had almost 1 month discussion with Apigee support on this and finally, the refresh of reference workaround worked for us.

Are you refering to this Apigee Management API to refresh the reference?

Yes, that would be the one. You either use the management api to force the refresh, or point the reference to a new truststore in the UI

Yes, that one you can use to refresh the reference. This will do reference reload and you can avoid restart.

Hi thanks, this work for me. Thank god we didn't have to restart the edge router as thats what is in the documentation and had to make a support ticket just to do it. Hopefully they could add this in the documentastion as we have no idea whatsover how to refresh the certificate cache without restarting routers. Turns out this the other way we could refresh the cache w/o restart. ♥♥♥

Yes, the restart was a headache for us, as we cannot do that in prod. Finally, we found this as a workaround after multiple tries.

Yes Apigee should add this note in the docuemnt.