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 connection details, only the matching server 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
- the client verifies the server certificate details (DNS name, date range, optionally revocation)
- 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).
The minimum fields that will change between a legitimate certificate and a proxy-generated one will be the exponent and signature. 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, duplicating every other detail of the certificate chain (exponents and signatures excepted). Once any detail of a certificate is changed, the computed fingerprint (digest) will also change.
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 should give it away
- may have many other fields in common (serial number, SID, date) but probably won't
- will not be signed by a commercial CA, 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.
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)