0 votes
by (150 points)

Want to translate between the old servers TLS 1.0 to the browser supported TLS 1.2.

Using the tlsproxy application and get this log message when trying to connect:

02-10 12:30:53.164 INF Tunnel(17)[#0 '1443-'][OUT]:
Fatal Alert:UnknownCa was sent.

02-10 12:30:53.169 ERR Tunnel(25)[#0 '1443-']:
Cannot start tunnel due to Rebex.Net.TlsException: Server 
certificate was rejected by the verifier because of an unknown
certificate authority.
 ---> Rebex.Net.TlsException: Server certificate was rejected by
the verifier because of an unknown certificate authority.

Both my cert used for incoming connections and the cert on the remote server are self signed.

This is the tunnel config I'm using:

Tunnel #0: '1443-'
 *  IN: (TLS - TLS12)
 * OUT: (TLS - TLS10)
 * Server-names: '', SNI-preserve: 'True'
 * Certificate: 'C:\testing.pfx', DH-key-size: '', Idle-timeout: 120

Is there a way to ignore that the certs are self signed?

Applies to: Rebex TLS

1 Answer

0 votes
by (70.4k points)
selected by
Best answer

It is not supported in the current version officially.

However, we already added possibility to utilize certificate validations. But it is not finalized yet, so it is not public.
You can use this undocumented config.yaml setting:

validationOptions: AcceptAll

Or when adding new tunnel using command line interface use:

--validation-options AcceptAll

We will finalize this in a future release.

Please note that AcceptAll setting will completely skip certificate validation (which is similar to disabling TLS). This can be acceptable if the TLS Proxy and the target server are in the same protected private network (or when the proxy is running on the same machine as the target server). However, it is unsafe and I strongly discourage to do this if the communication between the proxy and the target server goes over unsecure network (such as internet).

What I would do personally:
- Issue self-signed root for my company.
- Issue certificate for target server with only available usage of Server Authentication.
- Add the self-signed company root certificate to Trusted Root Certificates on machine the proxy is running - this will cause the proxy succeeds when validating target server's certificate, keeping the connection between proxy and target server secure.
- Keep the self-signed root locked on an USB stick in a company vault; or the self-signed root with associated private key can be deleted, only public part of the certificate needs to be stored (deleting is the most secure solution - if new server certificate needs to be issued, new self-signed root must be issued as well and added to trusted roots by administrator).

The above discusion will solve the error on proxy side. If the client is having similar issue with self-signed certificate (connection between client and proxy) the client must handle the error (not the proxy).

You can:
- Disable TLS on proxy and set up clients to connect without TLS.
- Disable certificate check on client (which is not suggested, because it is practially same as disabling TLS).
- Add proxy certificate to known certificates in the client app (if the client app has such functionality).
- Use solution as suggested above (install self-signed company root on client machine).