SSL errors appearing in trace-level logs of envoy

I have deployed 2 istio enabled services on a GKE cluster.

istio version is 1.1.5 and GKE is on v1.15.9-gke.24

istio has been installed with global.mtls.enabled=true

serviceA communicates properly

serviceB apparently has TLS related issues.

I spin up a non-istio enabled deployment just for testing and exec into this test pod to curl these 2 service endpoints.

/ # curl -v serviceA
* Rebuilt URL to: serviceA/
*   Trying
* Connected to serviceA ( port 80 (#0)
> GET / HTTP/1.1
> Host: serviceA
> User-Agent: curl/7.57.0
> Accept: */*
< HTTP/1.1 200 OK
< content-type: application/json
< content-length: 130
< server: istio-envoy
< date: Sat, 25 Apr 2020 09:45:32 GMT
< x-envoy-upstream-service-time: 2
< x-envoy-decorator-operation: serviceA.mynamespace.svc.cluster.local:80/*
{"application":"Flask-Docker Container"}
* Connection #0 to host serviceA left intact

/ # curl -v serviceB
* Rebuilt URL to: serviceB/
*   Trying
* Connected to serviceB ( port 80 (#0)
> GET / HTTP/1.1
> Host: serviceB
> User-Agent: curl/7.57.0
> Accept: */*
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Execing into the envoy proxy of the problematic service and turning trace level logging on, I see this error

serviceB-758bc87dcf-jzjgj istio-proxy [2020-04-24 13:15:21.180][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/] [C1484] handshake error: 1
serviceB-758bc87dcf-jzjgj istio-proxy [2020-04-24 13:15:21.180][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/] [C1484] TLS error: 268435612:SSL routines:OPENSSL_internal:HTTP_REQUEST

The envoy sidecars of both containers, display similar information when debugging their certificates.

I verify this by execing into both istio containers, cd-ing to /etc/certs/ and running

openssl x509 -in root-cert.pem -noout -text

The two root-cert.pem are identical!

Since those 2 istio proxies have exactly the same tls configuration in terms of certs, why this cryptic SSL error on serviceB?

FWIW serviceB communicates with a non-istio enabled postgres service.

Could that be causing the issue?

curling the container of serviceB from within itself however, returns a healthy response.