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.