As answered by @techraf, the re-encryption step from the proxy/firewall requires you to install an additional certificate (public key to match the private one the proxy has).
In effect, it’s a MITM attack, but one you agreed to.
The browser “trusts” the traffic, but the certificate chain is almost certainly different to one that you would see without the filter in place, since the signing chain now references the proxy/firewall signing certificate chain, not the one used at the traffic source.
You should be able to determine the traffic has been inspected, but the client is unlikely to be able to detect this without additional help. If you have an alternative route to the same site you might be able to request the original certificates directly and compare the cert chains.
Even if the signing chain is the same the fingerprint would be different.
Were someone to gain access to one of the private keys of a public certificate you already trust, you won’t need to install the extra cert & would find it quite hard to spot this. A fact probably not lost on enforcement agencies the world over. The only difference at the endpoint is (potentially) which signing & root certs were used to reseal the traffic.
Note that in the case of a firewall, no “proxy” configuration is involved, it can be done transparently.
