Все, что я тут написал, в общем-то не ново. Но офисным крысам не очевидно. Так что - в плане ликбеза.
Вот, положим, ходите вы на hotmail (или, что б это было ближе нашему пользователю, mail.ru). Что б туда ходить, нужно логиниться. Что б никто и никогда не прочитал ваш пароль, вы пользуетесь HTTPS: то есть для Hotmail вы логинитесь через
https://login.live.com, для ЖЖ, например, ходите на
https://www.livejournal.com/login.bml,
а для Mail.Ru -
https://secure.mail.ru.
Теперь, положим, вы это делаете с рабочего компьютера. Конечно, понятно, конечно, что рабочий компьютер нельзя использовать для личного серфинга в интернет, если такое специально не оговорено, но все пользуются. Что происходит в этом случае?
Администратор устанавливает https proxy.
Обычно https proxy работают так: настройками разрешается метод CONNECT на порт 443, броузер говорит прокси, CONNECT, после чего прокси просто пересылает шифрованный трафик туда-сюда, не делая попыток в него заглянуть. Происходит обмен сертификатами, выработка сеансового ключа и т.д.
Положим, теперь, в компании используется WCCP и все проксирование происходит прозрачно (и, возможно, без ведома) для пользователя. Простота реализации на клиентах, политика безопасности - в общем можно массу аргументов сочинить для этого. В общем-то, тоже ничего особенного, прокси открывает tcp-соединение от имени клиента с https-сервером и гоняет трафик туда-сюда без проверки. HTTP трафик может инспектироваться, проверяться на вирусы, например, или может проводится проверка URL на всякие блэк-листы (что б офисный планктон в ЖЖ не сидел в рабочее время).
Такая ситуация не может устраивать службу безопасности, которая мечтает контроллировать трафик пользователей. Ясно, что может появиться масса желающих сделать туннель через HTTPS и гонять трафик в обход корпоративной системы контроля.
Выход тут - делать man-in-the-middle для HTTPS. В общем случае, увидев HTTPS, прокси может сам открыть HTTPS-соединение адресату, принять сертификат, сгенерировать сертификат с такими же данными полей (кроме подписи CA, конечно) и подсунуть его клиенту. Что может увидеть клиент? Максимум, что сертификат подписан недоверенным CA. Клиент ведь не знает, какой CA в оригинале подписал сертификат Web-сервера.
Теперь, предположим, что у нас развернута AD, доменные политики и проч. Администратор домена создает корпоративный root CA, сертификат которого распространяет политиками на все компьютеры организации (оно, даже, кажется, само так делает). Сертификаты, которые HTTPS-прокси будет подсовывать клиентам вместо настоящих сертификатов Web-серверов, подписывать в иерархии, во главе которой стоит собственный, доверенный enterprise CA. Клиент ничего не замечает, сетевой администратор читает почту генерального директора.
Все довольны.
PS. В X.509v3 теоретически есть mesh-топологии, как в OpenPGP, но на практике я их еще не видел.