GateWay Ssl Error · Issue #6071 · istio/istio

link管理
链接快照平台
输入网页链接，自动生成快照
标签化管理网页链接
相关文章推荐
热心肠的茶叶 · How to fix git error: ...· 18 小时前 ·
礼貌的凳子 · curl error 56: ...· 18 小时前 ·
乐观的沙滩裤 · docker访问服务报错：curl: ...· 18 小时前 ·
阳刚的饭盒 · error: RPC failed; ...· 18 小时前 ·
睿智的甜瓜 · 报错：curl: (56) Recv ...· 18 小时前 ·
考研的海豚 · 发送到 Kindle · ...· 3 月前 ·
粗眉毛的熊猫 · 甄玉娆（电视剧《甄嬛传》中的角色）_百度百科· 5 月前 ·
要出家的移动电源 · MAX in std::u32 - Rust· 1 年前 ·
紧张的红金鱼 · 售49.9-58.8万元极氪009正式上市- ...· 1 年前 ·
自信的拖把 · 一块英伟达3090单挑180亿参数大模型，国 ...· 1 年前 ·
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account GitRevision: 6f9f420f0c7119ff4fa6a1966a6f6d89b1b4db84
I have this error when i try to reach a pods behind a Gateway (via https)
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 104.199.103.101:443
This may be related to this warning in the logs of the gateway pods
[2018-06-07 15:27:38.480][17][warning][config] external/envoy/source/server/listener_manager_impl.cc:254] adding listener '0.0.0.0:443': filter chain match rules require TLS Inspector listener filter, but it isn't configured, trying to inject it (this might fail if Envoy is compiled without it)
Any ideas?
Thanks
          @vadimeisenbergibm Does this look like it may be the same problem that you and @dcberg were investigating yesterday? If so, any resolution?
@hamon-e and @wjwinner Can you provide more details?
          I am having this issue specifically when using a AWS NLB with a Istio Gateway on HTTPS.
From istio-ingressgateway logs:
adding listener '0.0.0.0:443': filter chain match rules require TLS Inspector listener filter, but it isn't configured, trying to inject it (this might fail if Envoy is compiled without it)
The gateway and virtualservice are not working under that scenario (requests are not routed). Notice it does work with the following combinations:
AWS ELB (classic) and HTTPS
AWS NLB and HTTP
From istio-ingressgateway k8s service definition (notice the annotations to set up the NLB):
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: istio-system    
  labels:
    chart: ingressgateway-0.8.0
    release: istio
    heritage: Tiller
    istio: ingressgateway
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
      name: http
      nodePort: 31380
      port: 80
      name: https
      nodePort: 31390
      port: 443
      name: tcp
      nodePort: 31400
      port: 31400




    

Running Istio 0.8.0 - May 2018 Release (LTS) and Kubernetes 1.11.0.
          @vadimeisenbergibm The step 1 suggests the following:
kubectl get svc -n istio-system
$ echo INGRESS_HOST=$INGRESS_HOST, SECURE_INGRESS_PORT=$SECURE_INGRESS_PORT
I don't get it how sharing with you my ingress host will be of any help. I got this working with NLB and HTTP and I also got it working with ELB and HTTPS. It's the combination of NLB and HTTPS that is giving me the aforementioned warning and causing the gateway to not route the requests.
The result of that command above will be a AWS load balancer dns name, such as ae96ead38897911e8adab0a3d68bae34-2142157781.ap-southeast-1.elb.amazonaws.com and the port is 443
Thanks in advance for putting some time and sorry if I have misunderstood something.
          I'm also experiencing a similar issue.
In my case using an NLB in combination with HTTPS (I've tried an ELB as well with no better luck).
What I see is:
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 18.210.31.22:443
and a very similar error is also thrown if I try to connect internally to the ClusterIp of the service:
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 10.100.243.178:443
Certificates have been created as suggested using https://github.com/nicholasjackson/mtls-go-example
This is the result of the suggested troubleshooting steps:
Host would be an NLB address, port 443
$ kubectl exec -it -n istio-system $(kubectl -n istio-system get pods -l istio=ingressgateway -o jsonpath='{.items[0].metadata.name}') -- ls -al /etc/istio/ingressgateway-certs
total 8
drwxrwxrwt 3 root root   80 Jul 19 08:41 .
drwxr-xr-x 1 root root 4096 Jul 19 08:41 ..
drwxr-xr-x 2 root root   40 Jul 19 08:41 ..2018_07_19_08_41_16.761205109
lrwxrwxrwx 1 root root   31 Jul 19 08:41 ..data -> ..2018_07_19_08_41_16.761205109
Logs from the ingress gateway show:
[2018-07-19 08:59:53.102][52][warning][config] external/envoy/source/server/listener_manager_impl.cc:254] adding listener '0.0.0.0:443': filter chain match rules require TLS Inspector listener filter, but it isn't configured, trying to inject it (this might fail if Envoy is compiled without it)
[2018-07-19 08:59:53.103][52][info][upstream] external/envoy/source/server/lds_api.cc:62] lds: add/update listener '0.0.0.0_443'
[2018-07-19 08:59:58.255][52][warning][config] external/envoy/source/server/listener_manager_impl.cc:254] adding listener '0.0.0.0:443': filter chain match rules require TLS Inspector listener filter, but it isn't configured, trying to inject it (this might fail if Envoy is compiled without it)
[2018-07-19 08:59:58.256][52][info][upstream] external/envoy/source/server/lds_api.cc:62] lds: add/update listener '0.0.0.0_443'
Thanks!
          @claudio-benfatto Note that you do not have the key and the certificate in /etc/istio/ingressgateway-certs:
https://preliminary.istio.io/docs/tasks/traffic-management/secure-ingress/#troubleshooting
tls.crt and tls.key should exist in the directory contents.
          @vadimeisenbergibm really sorry, it somehow got cut off the copy-paste:
~ $ kubectl exec -it -n istio-system $(kubectl -n istio-system get pods -l istio=ingressgateway -o jsonpath='{.items[0].metadata.name}') -- ls -al /etc/istio/ingressgateway-certs
total 8
drwxrwxrwt 3 root root  120 Jul 19 14:37 .
drwxr-xr-x 1 root root 4096 Jul 19 14:27 ..
drwxr-xr-x 2 root root   80 Jul 19 14:37 ..2018_07_19_14_37_13.238515031
lrwxrwxrwx 1 root root   31 Jul 19 14:37 ..data -> ..2018_07_19_14_37_13.238515031
lrwxrwxrwx 1 root root   14 Jul 19 14:37 tls.crt -> ..data/tls.crt
lrwxrwxrwx 1 root root   14 Jul 19 14:37 tls.key -> ..data/tls.key
          @vadimeisenbergibm I've just finish to test without SSL and it's works with booking example.
Gateway:
Name:         bookinfo-gateway
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.istio.io/v1alpha3
Kind:         Gateway
Metadata:
  Creation Timestamp:  2018-07-20T22:08:26Z
  Generation:          1
  Resource Version:    10640
  Self Link:           /apis/networking.istio.io/v1alpha3/namespaces/default/gateways/bookinfo-gateway
  UID:                 6cd5d276-8c69-11e8-a24d-02c2dbb86c04
Spec:
  Selector:
    Istio:  ingressgateway
  Servers:
    Hosts:
    Port:
      Name:      http
      Number:    80
      Protocol:  HTTP
Events:          <none>
Svc :
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
  labels:
    chart: ingressgateway-0.8.0
    heritage: Tiller
    istio: ingressgateway
    release: istio
  name: istio-ingressgateway
  namespace: istio-system
spec:
  externalTrafficPolicy: Local
  ports:
  - name: http
    nodePort: 31380
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    nodePort: 31390
    port: 443
    protocol: TCP
    targetPort: 443
  - name: tcp
    nodePort: 31400
    port: 31400
    protocol: TCP
    targetPort: 31400
  selector:
    istio: ingressgateway
  sessionAffinity: None
  type: LoadBalancer
istio-ingressgateway       LoadBalancer   100.70.244.66    af90bcaXXXXX24d02c2dbb86c0-ec474XXX0.elb.eu-central-1.amazonaws.com   80:31380/TCP,443:31390/TCP,31400:31400/TCP                            9m        istio=ingressgateway
$ curl -s -o /dev/null -w "%{http_code}"  http://af90bcaXXXXX24d02c2dbb86c0-ec474XXX0.elb.eu-central-1.amazonaws.com/productpage                                                                
Hope this will help
          The situation I hit with this scenario was that the TLS cert config was not properly stored with the Gateway. You can use the istioctl to validate that the Gateway config has the TLS config. This is fixed in the latest prelim build.
The other part is that your load balancer implementation must pass the expected SNI that matches the CN in the cert. If it does not then you will get a handshake error.
SSL Certificates are in place:

HTTP flow works fine
But! once I provision both Gateways -  HTTP and HTTPS. SSL connection begin to work

removing HTTP  leads to same error

(35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mydomain.com
          @vadimeisenbergibm I do not know who can help with AWS specific issues, so I added the help wanted label.
@loewenstein @christian-posta any idea with this AWS specific setup?
          Does the nlb and more precisely target still healthy ?
Does the security group on the node have correct filtering (normally applied by k8s lb creation) ?




    

 On 23 Jul 2018, at 7:23 PM, Andra Cismaru ***@***.***> wrote:
 @vadimeisenbergibm I do not know who can help with AWS specific issues, so I added the help wanted label.
 @loewenstein @christian-posta any idea with this AWS specific setup?
 You are receiving this because you were mentioned.
 Reply to this email directly, view it on GitHub, or mute the thread.
          it is ELB - Classic Load Balancer, created by k8s service by default

mean time will keep both 80 and 443 in Gateway configuration.

redirect to SSL works for me
  - port:
      number: 80
      name: http
      protocol: HTTP
      httpsRedirect: true
I've follow https://istio.io/docs/tasks/traffic-management/ingress/ to deploy httpbin with http firstly
I've follow https://istio.io/docs/tasks/traffic-management/secure-ingress/ for https implementation
I've adapt a new gateway to handle 443 AND 80
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key
    hosts:
    - "httpbinssl.xxx"
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "httpbinssl.istio.xxx"
https is working find (expect auto signed certificate warning):
curl -vv https://httpbinssl.xxx/status/200                                                                                                                                                                                                
*   Trying 18.18xxx...
* TCP_NODELAY set
* Connected to httpbinssl.xxx (18.18xxx) port 443 (#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/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.
And http still working:
curl -vv http://httpbinssl.xxx/status/200                                                                                                                                                                                                 
*   Trying 18.18xxx...
* TCP_NODELAY set
* Connected to httpbinssl.xxx (18.18xxx) port 80 (#0)
> GET /status/200 HTTP/1.1
> Host: httpbinssl.xxx
> User-Agent: curl/7.54.0
> Accept: */*
< HTTP/1.1 200 OK
< server: envoy
< date: Mon, 23 Jul 2018 19:58:15 GMT
< content-type: text/html; charset=utf-8
< access-control-allow-origin: *
< access-control-allow-credentials: true
< content-length: 0
< x-envoy-upstream-service-time: 4
* Connection #0 to host httpbinssl.xxx left intact
          [istio-1.0.2 (⎈ |cluster-2:default)]$ kubectl get po -n istio-system

NAME                                        READY     STATUS    RESTARTS   AGE

istio-citadel-86c9878bd9-skn8t              1/1       Running   0          46m

istio-egressgateway-6c7949d598-55b2r        1/1       Running   0          46m

istio-galley-656946f9d-vm65g                1/1       Running   0          46m

istio-ingressgateway-699794bf9c-lgb2q       1/1       Running   0          46m

istio-pilot-5f757f67d8-wwql8                2/2       Running   0          46m

istio-policy-6978f6fff4-wjpr8               2/2       Running   0          46m

istio-sidecar-injector-58996b77bd-5q4p7     1/1       Running   0          46m

istio-statsd-prom-bridge-55965ff9c8-8wh6p   1/1       Running   0          46m

istio-telemetry-bb6b55b67-pc79c             2/2       Running   0          46m

prometheus-7456f56c96-4hkmv                 1/1       Running   0          46m

[istio-1.0.2 (⎈ |cluster-2:default)]$ kubectl describe svc istio-ingressgateway -n istio-system
Name:                     istio-ingressgateway

Namespace:                istio-system

Labels:                   app=istio-ingressgateway

chart=gateways-1.0.1

heritage=Tiller

istio=ingressgateway

release=wishing-llama

Annotations:              

Selector:                 app=istio-ingressgateway,istio=ingressgateway

Type:                     LoadBalancer

IP:                       10.63.242.204

LoadBalancer Ingress:     35.233.137.254

Port:                     http2  80/TCP

TargetPort:               80/TCP

NodePort:                 http2  31380/TCP

Endpoints:                10.60.1.7:80

Port:                     https  443/TCP

TargetPort:               443/TCP

NodePort:                 https  31390/TCP

Endpoints:                10.60.1.7:443

Port:                     tcp  31400/TCP

TargetPort:               31400/TCP

NodePort:                 tcp  31400/TCP

Endpoints:                10.60.1.7:31400

Port:                     tcp-pilot-grpc-tls  15011/TCP

TargetPort:               15011/TCP

NodePort:                 tcp-pilot-grpc-tls  32603/TCP

Endpoints:                10.60.1.7:15011

Port:                     tcp-citadel-grpc-tls  8060/TCP

TargetPort:               8060/TCP

NodePort:                 tcp-citadel-grpc-tls  32050/TCP

Endpoints:                10.60.1.7:8060

Port:                     tcp-dns-tls  853/TCP

TargetPort:               853/TCP

NodePort:                 tcp-dns-tls  30567/TCP

Endpoints:                10.60.1.7:853

Port:                     http2-prometheus  15030/TCP

TargetPort:               15030/TCP

NodePort:                 http2-prometheus  32011/TCP

Endpoints:                10.60.1.7:15030

Port:                     http2-grafana  15031/TCP

TargetPort:               15031/TCP

NodePort:                 http2-grafana  32669/TCP

Endpoints:                10.60.1.7:15031

Session Affinity:         None

External Traffic Policy:  Cluster

Events:

Type    Reason                Age   From                Message
Normal  EnsuringLoadBalancer  46m   service-controller  Ensuring load balancer

Normal  EnsuredLoadBalancer   45m   service-controller  Ensured load balancer

[istio-1.0.2 (⎈ |cluster-2:default)]$  curl -v 35.230.58.76
Rebuilt URL to: 35.230.58.76/
Trying 35.230.58.76...
TCP_NODELAY set
connect to 35.230.58.76 port 80 failed: Connection refused
Failed to connect to 35.230.58.76 port 80: Connection refused
Closing connection 0

curl: (7) Failed to connect to 35.230.58.76 port 80: Connection refused
          This is still genuinely a problem, and only the wildcard solution suggested by #6071 (comment) helps when you want to setup up a mutual TLS ingress gateway by following this guide: https://istio.io/docs/tasks/traffic-management/secure-ingress/
The guide suggests that you can put in a FQDN in the hosts key when you're setting up a https protocol server in the Gateway  resource  but I've only ever had success in putting a wildcard *.
Note: I've had these problems against istio 1.0.2
          Same problem here on 1.0.5. I've tried many different configurations and the only one that works is when both http and https are enabled on the gateway but I don't want anything to be accessible on http. httpRedirect won't suffice as that then causes a "too many redirects" issue when enabling the cloudflare proxy and we absolutely need cloudflare.
          I'm on 1.0.6 and encountered the exactly same issue. There're two workarounds I currently found that make tls work:
like @eigokor said,  specify httpRedirect and visit http port instead
like @themanifold said, specify hosts key as wildcard * and then tls works without redirection
I'm on 1.0.6 and encountered the exactly same issue. There're two workarounds I currently found that make tls work:
like @eigokor said,  specify httpRedirect and visit http port instead
like @themanifold said, specify hosts key as wildcard * and then tls works without redirection
Does anyone found the fix for it?
httpsRedirect=true doesn't works for me, now I cant access the HTTP nor the HTTPS protocol of my application
I can't use "*" for hosts
Please can someone refer me the proper fix
Istio version: 1.1.6

k8s version: 1.13.6
          @venomwaqar I have other walk arounds for this. Just add --resolve flag if you're using curl:
--resolve HOST:PORT:ADDRESS  Force resolve of HOST:PORT to ADDRESS
Configuring a dns record for that IP should also work.
I guess it's  an SNI-related issue so either of:
specifying hostname using --resolve
using dns
http redirect
have a wildcard cert and specify hosts as *
makes gateway know which cert it should select. Therefore I think it's not an Istio-related bug.
          I am seeing the same issue where the httpsRedirect: true option is not working at all and HTTP traffic is not being redirected to HTTPS.
Does anyone have any idea what might be causing this and how to fix it?
          I still have the same issue in version 1.2.2.

When I try to set a specific host in my Gateway, I have an SSL_ERROR_SYSCALL but it works great with a wildcard.

I have a simple application who returns a token on a POST.

Here are my tests.

Set up working with hosts wildcard:
### With wildcard host
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: test-gateway
  namespace: test
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 443
      name: https-test
      protocol: HTTPS
      mode: SIMPLE
      credentialName: "wildcard-test-cmp-gg" ## Wildcard certificate *.test.cmp.gg
    hosts:
    - "*"
[~]> curl --resolve 'graphql-istio.test.cmp.gg:31390:kube-01.dev.cmp.com'  -vvv --header 'Host: graphql-istio.test.cmp.gg' -kX POST -d 'grant_type=password&[email protected]&password=ThePassord&client_id=1234&client_secret=1234' https://kube-01.dev.cmp.com:31390/oauth/token
Note: Unnecessary use of -X or --request, POST is already inferred.
* Resolve address 'kube-01.dev.cmp.com' found illegal!
* Couldn't parse CURLOPT_RESOLVE entry 'graphql-istio.test.cmp.gg:31390:kube-01.dev.cmp.com'!
*   Trying 192.168.1.1:31390...
* TCP_NODELAY set
* Connected to kube-01.dev.cmp.com (192.168.1.1) port 31390 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.test.cmp.gg
*  start date: May  2 21:16:09 2019 GMT
*  expire date: Jul 31 21:16:09 2019 GMT
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f2123fbf30)
> POST /oauth/token HTTP/2
> Host: graphql-istio.test.cmp.gg
> User-Agent: curl/7.65.1
> Accept: */*
> content-type: application/x-www-form-urlencoded
> Content-Length: 221
* We are completely uploaded and fine
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
< HTTP/2 200 
< server: istio-envoy
< date: Fri, 05 Jul 2019 08:36:46 GMT
< content-type: application/json; charset=utf-8
< content-length: 1200
< cache-control: no-store
< pragma: no-cache
< x-envoy-upstream-service-time: 230
< backend-response-time: 227
< name: oauth
< version: 1
< endpoint: /oauth/token
< x-datadog-sampling-priority: -1
{"access_token": OK}%
Set up not working with specific hosts:
### With specific host
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: test-gateway
  namespace: test
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 443
      name: https-test
      protocol: HTTPS
      mode: SIMPLE
      credentialName: "wildcard-test-cmp-gg" ## Wildcard certificate *.test.cmp.gg
    hosts:
    - "graphql-istio.test.cmp.gg"
[~]> curl --resolve 'graphql-istio.test.cmp.gg:31390:192.168.1.1' -vvv --header 'Host: graphql-istio.test.cmp.gg' -kX POST -d 'grant_type=password&[email protected]&password=ThePassord&client_id=1234&client_secret=1234' https://kube-01.dev.cmp.com:31390/oauth/token
Note: Unnecessary use of -X or --request, POST is already inferred.
* Added graphql-istio.test.cmp.gg:31390:192.168.1.1 to DNS cache
*   Trying 192.168.1.1:31390...
* TCP_NODELAY set
* Connected to kube-01.dev.cmp.com (192.168.1.1) port 31390 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to kube-01.dev.cmp.com:31390 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to kube-01.dev.cmp.com:31390
I am not interested to use the httpsRedirect method (I don't have http endpoint).

Do we have a status about this problem? SNI issue?
          @vadimeisenbergibm It was the case.

But shame on me, the problem was coming from my curl command.
The wrong command:
[~]> curl --resolve 'graphql-istio.test.cmp.gg:31390:192.168.1.1' -vvv --header 'Host: graphql-istio.test.cmp.gg' -kX POST -d 'grant_type=password&[email protected]&password=ThePassord&client_id=1234&client_secret=1234'      https://kube-01.dev.cmp.com:31390/oauth/token
The right command:
[~]> curl --resolve 'graphql-istio.test.cmp.gg:31390:192.168.1.1' -vvv --header 'Host: graphql-istio.test.cmp.gg' -kX POST -d 'grant_type=password&[email protected]&password=ThePassord&client_id=1234&client_secret=1234'      https://graphql-istio.test.cmp.gg:31390/oauth/token
So it working great. 👌
          @themanifold @spacejam101 this issue contains multiple problems reported by multiple people, some of the problems seem to be resolved. Could you please open new issues and describe the problems you experience? Then we will need to check your configuration, ask you to dump pilot configuration, and so on, so it will be the question of your specific configuration, your environment and your pilot configuration and logs.
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to
          @xlanor I solved it by creating the certificate manually and then uploading it as a secret. It seems the issue is in the certIssuer. I tested this in AWS and GCP. Generate your own certificates as secrets  and reference them in the gateway. Remember to put it in the same namespace as the sitio Gateway (sitio-system).