add option to ignore ssl cert problems
kimusan opened this issue · comments
Some corp networks injects an SSL cert (e.g. via Zscaler). This makes sshx bail with "unknownIssuer".
It would be great with a cmdline argument that tells it to ignore such errors.
Sorry, I'm not sure what injecting an SSL cert means? Can you clarify what the error message is and steps to reproduce?
I have a similar issue. We have an internal CA that is not publicly trusted. Even though, I trust it and I would like sshx to accept it. An option for accepting the OS's trust store or for me to specify a file or folder with trusted CA certs would be nice.
Sorry, I'm not sure what injecting an SSL cert means? Can you clarify what the error message is and steps to reproduce?
It is like a proxy. When i connect to the internet I actually connects to the proxy. The proxy then fetches the website on the internet. But instead of returning the ssl certificate from the website it returns another one that it controls. This makes it possible for the "proxy" to scan the traffic and identify malicious content.
It does however also mean that the certificate might not look like it is supposed to and hence sshx will fail with invalid issuer (the issuer of the cert is the proxy).
I have a similar issue. We have an internal CA that is not publicly trusted. Even though, I trust it and I would like sshx to accept it. An option for accepting the OS's trust store or for me to specify a file or folder with trusted CA certs would be nice.
Could you make a separate GitHub issue for this? I would like to ask more questions. The only TLS verification that sshx should do is with the remote server, https://sshx.io, which uses Let's Encrypt certificates, and that should be trusted by all public CA root lists.
Sorry, I'm not sure what injecting an SSL cert means? Can you clarify what the error message is and steps to reproduce?
It is like a proxy. When i connect to the internet I actually connects to the proxy. The proxy then fetches the website on the internet. But instead of returning the ssl certificate from the website it returns another one that it controls. This makes it possible for the "proxy" to scan the traffic and identify malicious content. It does however also mean that the certificate might not look like it is supposed to and hence sshx will fail with invalid issuer (the issuer of the cert is the proxy).
Got it. This makes sense, will think about how to support this better.
In some regard, TLS is doing its job here perfectly by not letting the middle-man intercept and decrypt the request. 😅