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 10.100.152.100:80... * Connected to grpc-client-service.grpc.svc.cluster.local (10.100.152.100) 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.
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.
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.
Working with Grpc in AWS ECSasked 2 months ago
AppMesh mTLS - Unable to verify SSL encryption is established using SPIREasked 3 months ago
how to resolve [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate with Polly endpointasked 4 months ago
Supporting mutual TLS on specific resource pathsasked 3 months ago
Blue/Green deployments in ECS & Service Mesh for services without ELBAccepted Answerasked 2 years ago
CloudFront Authenticated Origin PullsAccepted Answerasked 2 years ago
Appmesh: Envoy times out after 15 secondsasked 18 days ago
How do I use Amazon CloudFront with AWS Elastic Beanstalk as the origin?Accepted AnswerEXPERTasked 2 years ago
Sagemaker Notebook - SSL failed validation when Boto3 session.client(verify=False)asked 22 days ago
Configuring End-to-End Encryptionasked 2 years ago