Hi im trying to config a HTTPS loadbalancer in GCP but when i made it
show me that:
Error: write EPROTO 140392502987240:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40 140392502987240:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:604:
I use GCP default as default politic ssl
And the certificate is valid:
My frontends
But is still not working, i dont know what other thing do.
SSL proxy load balancers and global external HTTP(S) load balancers do not support SSL versions 3.0(SSLV3) or earlier. So, try to use a newer and more secure version to call the HTTPS Load balancer. Check whether the certificate is valid and linked properly with the page.
EDIT:
SSL fatal error, handshake failure 40 indicates the secure connection failed to establish because the client and the server couldn't agree on connection settings. Usually because the client or the server is way too old, only supporting removed protocols/ciphers. Try adding the domain name of the server to connect and a TLS connection will be established.
Example:
$ openssl s_client -connect 104.26.3.5:443 -servername external.example.com
Related
Is it possible to directly expose a server behind a L4 load balancer, with a public certificate?
This server is inside a Kubernetes pod. There is a TCP loadbalancer service in front of it which creates the external L4 LB.
My problem is that the TLS traffic does not reach the container inside the pod. So if you succeeded with a similar configuration, I would be interested into knowing.
Update
I did not mention that the traffic is GRPC.
Here is what I did: I have a domain and a corresponding official certificate. I want to secure the grpc connection.
I tried two approches:
with google ESP container, I put the cert as an nginx secret, pass it to the container, set an ssl-port. Behind the ESP in the same pod, I have my grpc server
In this case I get a message like this on the client side:
D0610 14:38:46.246248584 32401 security_handshaker.cc:176] Security
handshake failed:
{"created":"#1591792726.246234613","description":"Handshake
failed","file":"../deps/grpc/src/core/lib/security/transport/security_handshaker.cc","file_line":291,"tsi_code":10,"tsi_error":"TSI_PROTOCOL_FAILURE"}
I see some TLS exchanges with wireshark but no log in esp.
without ESP, I put the cert in my GRPC server. There the GRPC server fails with something like this:
error:1408F10B:SSL routines:ssl3_get_record:wrong version number
In the google ESP documentation I see that I have to prove the domain belongs to me and upload the cert (but where)?
Update 2
As of today, I see no evidence that it is feasible.
IMO, the main issue is that the L4 has the IP corresponding to the domain name of the certificate. Hence the pods don't have the correct IP to prove that they can use the cert so their request towards roots are denied (I have no proof of that as I can't get debug info from nginx in the ESP. I have seen a request with the pure GRPC server solution though).
The issue was in TLS exchange.
By installing the cert in the ESP, it works fine with a web browser and the certificate is indicated valid, whereas with a GRPC client, the TLS handshake fails. Adding additional trace info helped.
By checking my certificate (not self signed but attached to my domain), I found that there is an intermediate certificate provided with it. I installed it along with the domain certificate (in the same crt file) and then it worked.
I don't know exactly why it is behaving like this but maybe it's due to the root_cert file in grpc client lib being too old.
By the way for a domain cert, there is no specific requirement regarding CN and subjectAltName for the certificate. It works without it. So it must only apply to self signed certs as I have seen elsewhere.
I had another issue that disturbed my task: be careful not to name the service port of the L4 load balancer with 'http2' inside. I had some side effect, making another deployment fail due to this. In fact when you do https, don't put http2 in the name.
Anyway it is now working and answers the request for the bounty. Thanks to all who tried to help :)
I am using AWS ELB as entry point (in Proxy mode) to load balance among 2 HAProxy-es behind it from where traffic goes further to MQTT broker.
Those 2 HAProxies are responsible for client TLS termination (2 way TLS).
Certificates kind of work. I've tested on local setup between 2 servers. I've been able to publish with 2-way TLS, properly terminate it, and publish message to mqtt. Problem arise when moving everything to AWS.
I am using self signed root CA, intermediate CA, server certificate and client certificates. Using Elliptic Curve...
Problem might be due to a servers CN. I think it has to be the same as hostname connecting to with tools like mosquitto_pub.
Error that I get is TLS error, whith debug -> ssl handshake failure. Somehow I am not able to produce more verbose errors. Using openssl with s_client and debug for max debug output. Which produce me ssl handshake failure.
I would really appreciate any hint/suggestion.
Thanks in advance.
Tomaz
I solved this by using subjectAltName feature. I edited openssl.cnf and add new section [alt_names] and reference it later on in configuration. Under alt_names I added 1 DNS key, and 2 IPs. Found with man x509v3_config.
Best,
Tomaz
I am forcing a dummy SSL for my localhost running through xampp. Now I am using web sockets which asks for 'wss:' instead of 'ws:'. But when using 'wss', I am getting the following Error:
WebSocket connection to 'wss://192.168.1.5/?aswin' failed: WebSocket opening handshake was canceled
I am new to this, I don't know what's causing this issue.
Remember to change the port number to a one different to the one you used for not secure connections. Some browsers get confused if suddenly a port becomes secure or viceversa.
Remember to use the hostname indicated in the certificate to connect and not the IP.
If you are using a self-signed certificate, use it for HTTPS so you can see the dialog for accepting that certificate. When accessing via WSS:// there is not certificate acceptance dialog, it will just fail to connect.
I've a WCF project and just started to integrate endpoints listening to https.
For testing I've created a self-signed certificate using this
article.
The certificate is valid:
Now I'm trying to consume the services that are listening to https, but the connection via OpenSSL command line tools fails:
CONNECTED(00000003)
write:errno=54
Also the -debug switch does not give any information.
Furthermore I've configured wcf tracing in order to resolve the error.
This gives me only information about the endpoint is listening to https but not anything about the connection error.
Can you please help me?
There was an issue with the certificate.
I've now created a CA certificate, intermediate (in order to support 2-step-validation) and the service certificate.
Furthermore it was necessary to link the certificate with the port of the service using netsh (netsh http add sslcert ipport=0.0.0.0:[your_port] certhash=[hash_of_cert] appid=[uuid]
I have 2 different ubuntu VPS instances each with different ip addresses.
One is assigned as a chef-server and the other acts as a workstation.
When I use the command
knife configure -i
I do get options to locate admin.pem and chf-validator.pem files locally.
I am also able to create knife.rb file locally.
WHile setting up knife, I get a question which asks me to enter 'chef-server url' so I enter 'https://ip_address/ of the vps instance
But in the end I get an error message
ERROR: SSL Validation failure connecting to host: "ip_address of my server host"- hostname "ip_address of my host" does not match the server certificate
ERROR: Could not establish a secure connection to the server.
Use knife ssl check to troubleshoot your SSL configuration.
If your Chef Server uses a self-signed certificate, you can use
knife ssl fetch to make knife trust the server's certificates.
I used 'knife ssl fetch' to fetch the trusted_certs from the chef-server but still it doesnt work.
CHef experts please help.
Your chef-server has a hostname, the selfsigned certificate is done with this hostname.
The error you get is due to the fact you call an IP adress where the certificate is done for a hostname.
Two way: disable ssl validation (you'll have a warning but it will works) or make a configuration (using your hostname files for exemple) to use the chef-server hostname instead of ip address.
This is a SSL configuration point you may have with other servers too.