As noted by sneak, the client will receive a certificate generated by the proxy, not the original site certificate. The reason being that the proxy cannot impersonate a site with its certificate alone, it must have the corresponding private key.
The certificate is an integral part of the TLS* set up (i.e. it's not a "site seal" or similar nonsense). Its content (public key) is used by the client to encrypt the connection, only the matching private key can decrypt this to successfully complete the connection. The proxy can only present its look-alike certificate for which it does have a key, this will have (with a very high probability) a different fingerprint or hash.
[* There are lots of options when negotiating TLS, two of the main features authentication and encryption have "null" options, though these are not typically seen for HTTPS. If you use a null authentication method, no certificate is required, e.g. ADH]
The general method of such TLS interception is that the proxy will generate (on the fly, thereafter cached) a key and certificate which match the DNS name(s) of the destination, the certificate will be signed by a pseudo-CA, stored on the proxy, which will be "trusted" by your OS/browser.
The trust works like this (to simplify slightly):
- the server presents a certificate containing the public key, because the client uses the server's public key to subsequently encrypt the symmetric key, the TLS setup will fail if the server is unable to decrypt the message from the client (i.e. does not have the corresponding private key)
- the client verifies the server certificate details (DNS name, date range, optionally revocation, and possibly "usage" attributes)
- the client verifies the chain of trust up to a known (local copy) trust anchor (typically a self-signed root CA)
The reason the proxy can succeed is that your browser "trusts" the corporate pseudo-CA, usually by virtue of desktop policy, customised browser deployment or similar. The problem with the trust model is clear: conventionally any CA can sign a certificate for any name (and usually, delegate by way of a subordinate CA too). There are some mitigations for this, including DANE, CAA and key-pinning.
The minimum set of fields that will change between a legitimate certificate and a proxy-generated one will be the public key modulus and certificate signature. If present the SKID and AKID fields (being derived from the relevant keys) will also differ. Validation related fields (OCSP, CRLs) will also likely be stripped, though it would be technically possible to provide these services for the pseudo-CA also.
In reality though the generated certificate will probably only superficially resemble the real certificate (enough to pass the date and DNS name tests), and be directly signed by your company proxy's pseudo-CA. It is however entirely possible to reproduce a legitimate looking CA hierarchy, fetching the real certifiate, duplicating every other detail of the certificate chain (excepting modulus and key-derived AKID/SKID, and signatures). Once any detail of a certificate is changed, the computed fingerprint (digest) will also (with a high probability) change.
(With corrections for confusing of exponent/modulus, thanks to dave_thompson_085 for noting this.)
To summarise, any proxy-generated certificate:
- must superficially resemble the real certificate, the DNS parts (CN and/or subjectAltNames) must match
- is probably immediately obvious since the "issuer" field may give it away (though this is not always true)
- may have many other fields in common (serial number, date) but probably won't (serial numbers need special handling since they must never be reused per-CA)
- revocation (CRL, OCSP) details will probably be subverted or removed from the certificate
will should not be signed by a commercial CA (Trustwave engaged in this dubious practice in the past), will not have the same signature data, and will not have the same fingerprint
does the site's certificate in the browser change if you check it?
Yes, you can probably just inspect the Issuer field, or computed fingerprint, but you need to validate the entire chain to be certain.
can it still just visually output the server's certificate to the user, so that they are unaware, just by looking at the certificate, that interception is occurring?
No. The HTTPS server (be it a real web server, or a proxy) has no control over this (user-interface problems, rogue extensions, and faked location bars aside). What the browser displays is the certificate that was used during the TLS connection set up, it is not a file fetched over HTTP.
is checking a secure site's certificate enough to detect a man-in-the-middle, or do you have to look through all your trusted certificates on your corporate laptop to determine if any of them are unusual?"
It's probably obvious from the certificate alone, the generated certificate will likely be directly signed by the proxy's pseudo-CA certificate, and that will probably be easily identifiable by text fields (at least "Issuer") in the certificate. To be thorough, you should compare all certificate fingerprints or the AKID/SKID linkage.
FWIW, EV certificates get you a tiny little bit of extra protection here: the proxy cannot fake a true EV certificate because any competent browser will have a hard-coded list of EV capable CA certificates. (It doesn't solve the chicken-and-egg problem though: how do you know when to expect or require an EV certificate?)
The IETF's DANE is proposed as a more robust solution. It addresses the underlying problem with the trust model:
The public CA model upon which TLS has depended is fundamentally
vulnerable because it allows any of these CAs to issue a certificate
for any domain name.
In order to actually solve the problem, rather than kicking it a little further down the road, DANE requires DNSSEC.
There is also one simple countermeasure: client certificates, but that's not a general solution for various reasons.
Other (partial) solutions include:
There are others such as Convergence, Verikey [PDF], CertPatrol (Firefox plugin), Monkeysphere (multi-protocol)