Since the client chooses the session key and encrypts it with the certificate, the proxy can not use the certificate of the server. Since it does not have the private key to go with that certificate, it would be unable to decrypt the client's chosen key and would thus be unable to communicate on the connection. It instead has to clone the certificate details on the fly and create a new certificate to be used for that site.

Depending on the key exchange used, with RSA key exchange the client will essentially choose the session key (it's a bit more complicated than that, but irrelevant to this discussion) and encrypts it with the server public key (from the certificate). Since the proxy does not have the private key to go with that certificate, it would be unable to decrypt the client's chosen key and would thus be unable to communicate on the connection.

In a DH key exchange, the initial exchange could be completed, but the client would then challenge the proxy to respond with a verification that it has the private key associated with the certificate and the proxy would be unable to provide a response to this challenge.

The proxy must instead clone the certificate details on the fly and create a new certificate to be used for that site. This way, it has the private key that corresponds and can form it's own connection to the desired server. Because the proxy has a root trust on the systems it is servicing, the cert is accepted as valid, though if a system is used both on and off the proxy, certificate pinning may result in an error being detected due to the public key changing.