Я администрирую корпоративный веб-прокси под управлением Squid 3.5.10 на CentOS 7 (устройство Diladele), выполняю SSL bumping, и у меня возникают проблемы с добавлением новых сертификатов CA в системное хранилище доверенных сертификатов, что приводит к тому, что наши пользователи не возможность получить доступ к нескольким сайтам, защищенным SSL, которые они должны иметь. Один из этих сайтов https://www.sexierdating.com/ (Да, это то, на что это похоже, но наша политика - не заботиться о том, что люди просматривают во время обеденных перерывов, если это разрешено законом).
Сообщение об ошибке от Squid обычное X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY, что означает, что по какой-то причине Squid не доверяет сертификату целевого сервера или не может его проверить. До сих пор получение корневого сертификата ЦС в формате PEM со страниц поддержки ЦС, размещение его в /etc/pki/ca-trust/source/anchors, Бег update-ca-trust и перезапуска Squid было достаточно, чтобы решить проблему, но не в моем текущем случае. Пакет ca-сертификатов находится в текущей версии, так как я только что выполнил полное обновление yum на машине.
Все домены, с которыми у меня в настоящее время возникают проблемы, имеют сертификат "Go Daddy Secure Certificate Authority - G2". Я скачал все сертификаты с их страницы поддержки (https://certs.godaddy.com/repository/), установил их как описано выше, перезагрузил squid, но ошибка не исчезла. Я даже смотрел update-ca-trust с strace, чтобы увидеть, действительно ли он собирает правильные файлы PEM - и это так.
Что меня немного смущает, так это то, что страница загрузки certs.godaddy.com, похоже, использует тот же корневой и промежуточный сертификат, что и некоторые из проблемных доменов, но эта страница отлично работает через Squid. Когда я сравниваю сертификаты в Firefox, я не вижу разницы в общей спецификации и алгоритмах, но все же один работает, а другие нет.
Я на грани своего остроумия и надеюсь, что кто-то может подтолкнуть меня в правильном направлении, чтобы решить эту проблему .. Я не могу добавить исключения прокси для каждой второй страницы с сертификатом GoDaddy ..
Хранилища ЦС на машинах и в браузерах включают сертификаты корневого ЦС.
Сайты НИКОГДА не должны получать сертификаты от корневых центров сертификации, а от посредника.
Ответственность за возврат как собственного сертификата, так и сертификата-посредника лежит на веб-сайте, поэтому браузеры могут связать посредника с одним из корневых сертификатов, которому он доверяет.
В приведенном вами примере веб-сайта они не включают промежуточный сертификат, поэтому ваши пользователи не могут доверять сайту. Это можно увидеть с помощью сканирования ssllabs здесь: https://www.ssllabs.com/ssltest/analyze.html?d=www.sexierdating.com. Как видите, он отправляет только один сертификат вместо двух и из-за этого получает неполное предупреждение. Раскрытие раздела «Пути сертификатов» показывает всю цепочку и позволяет вам загрузить этот посредник, если вы хотите его установить.
Следует отметить, что часто браузеры справляются с этой ситуацией - либо потому, что они будут иметь общие промежуточные данные, кэшированные при посещении других сайтов, либо потому, что они будут пытаться найти отсутствующий промежуточный сертификат. Очень часто эти неправильные конфигурации не замечаются большинством пользователей и операторов сайтов. Гадать, что здесь наталкивается на ssl, не совсем удобно для обработки этих ошибок.
В этом отличие от certs.godaddycom (https://www.ssllabs.com/ssltest/analyze.html?d=certs.godaddy.com), который отправляет полную цепочку. На самом деле у него обратная проблема, и он отправляет слишком много сертификатов, поскольку нет необходимости отправлять корневой сертификат (но, возможно, это существует по историческим причинам, как вы можете видеть, есть два пути цепочки сертификатов, один из которых требует корневого сертификата для быть подписанным другим сертификатом, который, вероятно, используется старыми браузерами, у которых нет нового корневого сертификата в своих хранилищах доверенных сертификатов).
В любом случае ваши варианты:
Без сомнения, я бы выбрал вариант 1, если бы это был я :-)