istio: GateWay Ssl Error
Version: 0.8.0
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
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 5
- Comments: 64 (31 by maintainers)
Got exact the same issue:
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
@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).
I still experience this issue as well (istio version
1.0.0
)… (I had performed basic troubleshooting above in this thread)ingressgateway service
ingressgateway pod details:
(
OK
) Attempt 1: try to connect from a worker to the ingressgatewayClusterIp
:(
OK
)Attempt 2: trying to connect directly to the host port (over https):(OK)
Attempt 3: connecting via the ELB (over HTTP
):(NOT OK)
Attempt 4: connecting via the ELB (overHTTPS
):and finally my ELB configuration, created automatically by kubernetes LoadBalancer Service:
This is my gateway configuration:
Other facts:
All
the ports are open from the ELB security group to the kubernetes workersHTTPS
works at the ELB level without termination ie. if I use31380
over tcp as a backendHTTP
connections to the application work from the remoteAny help is greatly appreciated. Please let me know if you need additional information!
UPDATE
it seems a problem with
sni
? The following configuration works all fineStill same issue on 1.1.0 and same workarounds working describe by @edussx. Tested with File Mount-Based approach and using Secret Discovery Service.
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.@frankbu @jsenon I am having the same issue.
I followed this tutorial https://istio.io/docs/tasks/traffic-management/secure-ingress/ and my curl was not working if I only have port 443. It was giving me error: SSL_ERROR_SYSCALL
curl -v -HHost:ms-1234.byom-i344382.eu-central-1.x.x.com https://ms-1234.byom-i344382.eu-central-1.x.x.com:443/api/v2/predict --cacert /home/vagrant/exmaple/mtls-go-example/2_intermediate/certs/ca-chain.cert.pem
then I added port 80 and redirected the traffic to https and it started working.
I’m also experiencing a similar issue.
In my case using an
NLB
in combination withHTTPS
(I’ve tried anELB
as well with no better luck).What I see is:
and a very similar error is also thrown if I try to connect internally to the ClusterIp of the service:
Certificates have been created as suggested using https://github.com/nicholasjackson/mtls-go-example
This is the result of the suggested troubleshooting steps:
Thanks!
@anthonyhaussman I am glad it worked for you 😃
I still have the same issue in version 1.2.2. When I try to set a specific
host
in my Gateway, I have anSSL_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:Set up not working with specific hosts:
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?I’m on 1.0.6 and encountered the exactly same issue. There’re two workarounds I currently found that make tls work:
httpRedirect
and visit http port insteadhosts
key as wildcard*
and then tls works without redirection