Under active interception, what do the issuer and certification path of a site's certificate reveal, and why is that suspicious?
The issuer is the interceptor's CA (here the mitmproxy sub-CA under CKTECK), and the path runs up to the company root instead of the public CA the site really uses; a university or bank site certified by your employer's CA makes no sense.
Comparing the certificate shown in the browser with what you would expect is the most direct way to spot interception:
- Issuer: the CA that signed the leaf. A real public website is certified by a public CA (Let's Encrypt, DigiCert, Sectigo, …). Under interception, it is the proxy's CA.
- Certification path: fake leaf
ilias.hslu.ch, then mitmproxy sub-CA, then CKTECK CA, then the CKTECK root. - Does it make sense? No. The HSLU has no relationship with CKTECK, so a CKTECK CA vouching for an HSLU site means somebody re-signed the traffic.
Visiting other sites gives the same picture: mitmproxy generates a fresh certificate per site, all from the same issuer. The browser trusts them all because it trusts that issuer.
Caveat: in many companies this is legitimate, declared TLS inspection on the firewall. The check tells you that traffic is inspected; whether that is acceptable is a policy question.
Go deeper:
Wikipedia: Chain of trust — reading a certification path from leaf to root.
Qualys SSL Labs: SSL Server Test — shows a site's real certificate chain from outside your network, for comparison.