У меня проблема с настройкой прозрачного прокси-сервера Squid на брандмауэре pfsense. Я создал центр сертификации для HTTPS MITM, установил его в своем браузере, и он работает с большинством веб-сайтов.
Однако сайты вроде ubuntuusers.de использование сертификата Let's encrypt может вызвать проблемы. Странно то, что это кажется правильным: его CN - это домен, а их CA - это правильно Let's Encrypt Authority X3.
Однако, как только прокси-сервер Squid перехватывает сертификат и MITM делает его своим собственным, CN сертификата становится IP-номером ubuntuusers.de и, следовательно, браузеры, оба Хром и Fire Fox отклонить его, так как cn и domain don't fit (net::ERR_CERT_COMMON_NAME_INVALID)
Это происходит только на этом сайте, поэтому он должен что-то делать с этим сертификатом. У меня недостаточно опыта с сертификатами, чтобы понять, почему это происходит.
...
Common Name (CN) 213.95.41.4
Organization (O) <Not Part Of Certificate>
Organizational Unit (OU) <Not Part Of Certificate>
Serial Number 7C...
Issued By
Common Name (CN) myown-ca
...
Может, кто-нибудь сможет мне объяснить такое поведение?
Похоже, вы используете server-first SSL bumping, который согласно документы не может обрабатывать SNI на сервере и будет использовать IP-адрес сервера в качестве сертификата (поскольку у сервера больше не будет одного имени хоста). Начиная с Squid 3.5, появились новые механизмы, называемые peek и stare которые позволяют squid наблюдать за согласованием SNI для определения запрошенного имени хоста, каждое из которых имеет свои ограничения.