By using AWS re:Post, you agree to the Terms of Use
/AppMesh mTLS - Unable to verify SSL encryption is established using SPIRE/

AppMesh mTLS - Unable to verify SSL encryption is established using SPIRE


I'm in the process of setting up a prototype mesh with mTLS. I've gotten to the point where I have my services coupled with envoy sidecars and the sidecars are receiving certificates from SPIRE. I've been following along with this article and am now running into an issue.

In their steps, they perform a curl command from a container outside of the mesh and get some TLS negotiation messages. When I try to do the same thing, I get the following:

bash-4.2# curl -v -k https://grpc-client-service.grpc.svc.cluster.local:80/
*   Trying
* Connected to grpc-client-service.grpc.svc.cluster.local ( port 80 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Any advice on where I should start to troubleshoot this issue?

Here's a rough overview of my setup: There are two pods that represent a client and a server service. The client has a web interface that allows the user to input text. The client takes the input text and submits that to the server service. The server service responds with an echo message that has some extra formatting so you know it came from the server. I've got both pods wrapped in virtual services that connect directly to virtual nodes. I was able to successfully test this with a basic mesh setup prior to adding the SPIRE workload parameters to the services. Within the envoy sidecars, I can see that the SPIRE server is indeed issuing certificates.

1 Answers

If your client applications are also trying to negotiate TLS in addition to the proxy, this issue might occur.

TLS in App Mesh currently supports the proxies negotiating TLS between themselves, while the applications speak plain-text to the proxies.

There is a roadmap item for allowing the downstream (client) applications to negotiate TLS instead of the proxy. Please refer this github comment for more info.

Having said that, this implementation with AppMesh and SPIFFE/SPIRE involves multiple components. Therefore, I advise you to reach out to the AWS Premium Support for troubleshooting the issue using this link.

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions