Due to the security built into TLS this can not be done by changing the existing TLS handshake in the proxy. Instead a TLS connection between the target server and the proxy and another TLS connection between the proxy and the client must be created. The latter connection cannot get the original certificate from the server, but the proxy must create a new one signed by its own CA. All certificate validations will be done by the proxy, so you need to trust the outbound proxy to do this properly. You also need to configure your application to trust the CA used by the proxy to create the new certificates.
Since TLS is terminated and recreated at the proxy there is no longer an end-to-end encryption. This means, that client certificates will not work in this setup transparently, i.e. you would need to move the sending of the correct client certificate to the proxy. Only few proxies support this.
If you can live with these limitations and if you only care about HTTPS traffic there is a lot of software which can do this. If you have one of the better firewalls or secure gateways the functionality is probably already there in the form of SSL inception capabilities. Apart from that you might use the free squid web proxy or test tools like mitmproxy. But note that especially the test tools not always validate the certificates properly. Also some solutions cannot deal properly with sites using Server Name Indication which makes these products unusable with lots of today's sites.
If your aim is not to deal with HTTPS traffic but with other protocols (i.e. IMAP, SMTP, SIP ... or custom protocols) the choice is much smaller and you might need to develop your own protocol specific version of such a proxy.