Open thediveo opened 5 years ago
So I found that myself, may it be helpful to others (I have to disable server certificate verification at the moment, as I get an "E certificate is valid but its commonName does not match hostname"):
$ websocat --binary \
--ws-c-uri=wss://192.168.99.100:8443/api/v1/namespaces/default/pods/mypod:8000/proxy/ \
- \
ws-c:cmd:'socat - ssl:192.168.99.100:8443,verify=0,\
cafile=/home/foo/.minikube/ca.crt,\
cert=/home/foo/.minikube/client.crt,key=/home/foo/.minikube/client.key'
Yes, socat
and openssl s_client
are valid workarounds for websocat.
Anyway I'll count this issue as a vote to implement this feature natively.
When you might be getting at this in the future, please give some love also to the commonname
option: I've found now out that I need to explicitly set this with newer socat versions which otherwise get tripped up by some servers...
Do you mean the name for SNI or the name in the server certificate to check?
As far as I understand the situation with respect to the Kubernetes remote API, this is about the server certificate returned during SSL handshake and checking it against the server's CA certificate the client has.
In order to connect to a websocket service inside a pod in a minikube setup, I need to address the Kubernetes remote API which then demands a client certificate (
~/.minikube/client.crt
and~/.minikube/client.key
). I also have the server's CA (~/.minikube/ca.crt
).curl
allows to use these certs with the--cert
,--key
, and--cacert
options.Does
websocat
also support specifying the client cert and the server CA when accessing awss://
URL?