Вопрос или проблема
Почему некоторым SSL-клиентам нужна полная цепочка сертификатов, а другим — нет? [дубликат]
Я настраивал частный репозиторий Docker и по ошибке включил серверный сертификат без полной цепочки сертификатов.
Я могу получить доступ к репозиторию (https://privserver1.64hosts.com:5004/) с помощью Chrome, и Chrome сообщает, что SSL-сертификат действителен и показывает всю цепочку сертификатов.
Но при попытке доступа к тому же репозиторию с помощью docker login privserver1.64hosts.com:5004 (введите любое имя пользователя/пароль), я получаю ошибку x509: сертификат подписан неизвестным удостоверяющим центром.
Когда я пытаюсь openssl s_client -showcerts -connect privserver1.64hosts.com:5004, он также сообщает, что не может проверить сертификат.
С другой стороны, curl https://privserver1.64hosts.com:5004 каким-то образом удается проверить сертификат.
Все клиенты работают на одном и том же компьютере с Windows, так что это не связано с различными CA сертификатами, установленными на разных клиентах.
Проблема легко решается использованием сертификата с полной цепочкой, но мне интересно, почему некоторые SSL-клиенты (docker, openssl) требуют полной цепочки сертификатов на сервере, а другие (Chrome, curl) — нет? SSL-соединение — это SSL-соединение, почему такая разница?
Разные приложения обрабатывают цепочки сертификатов и валидацию сертификатов по-разному.
Chrome часто имеет доступ к локальному хранилищу доверенных корневых сертификатов, которое может включать промежуточные сертификаты. Chrome может использовать свое локальное хранилище для заполнения пробелов, если ему предоставляется неполная цепочка сертификатов. Он также использует доступ к информации о удостоверяющем центре (AIA) RFC 3280. Все это делается для удобства пользователей, чтобы они могли получать доступ к веб-сайтам, даже если сервер неправильно настроен.
Curl обычно использует CA сертификаты системы для проверки SSL сертификатов. В некоторых случаях, если промежуточный сертификат уже кэширован системой или существует в хранилище сертификатов, curl может быть в состоянии проверить сертификат, даже если полная цепочка не предоставлена.
Docker более строг в том, как он обрабатывает проверку SSL сертификатов. Он ожидает, что полная цепочка сертификатов будет предоставлена. Это связано с тем, что Docker выполняет произвольный код из онлайн-репозитория и может иметь доступ к монтированным томам или внутренней сети без песочницы, предоставляемой браузером.
openssl также, как правило, требует, чтобы сервер предоставлял полную цепочку сертификатов. Он не выполняет автоматическую загрузку отсутствующих промежуточных сертификатов.
Итог: различные приложения имеют разные требования к безопасности, некоторые предназначены для удобства пользователей и работают в песочнице, чтобы предотвратить случайные ошибки… другие более строгие из-за доступа приложений.
Клиенты, ориентированные на конечного пользователя, такие как браузеры, активно ищут в базах данных CA промежуточные сертификаты, чтобы справиться с неполными цепочками. Это дополнительная функция, которую необходимо реализовать поверх стандартной проверки сертификатов.
По сравнению с этим, клиенты, которые проще или в основном предназначены для технических специалистов, обычно ожидают полную цепочку и не будут самостоятельно искать промежуточные сертификаты.
Ответ или решение
Разные SSL-клиенты обрабатывают сертификаты и проверку цепочек сертификатов по-разному, что объясняет, почему одни клиенты требуют полную цепочку сертификатов, а другие — нет.
### 1. Поведение браузеров (например, Chrome)
Браузеры, такие как Chrome, имеют доступ к локальному хранилищу доверенных корневых сертификатов, которое может включать промежуточные сертификаты. Они могут использовать это хранилище для заполнения отсутствующих промежуточных сертификатов, если сервер предоставляет неполную цепочку сертификатов. Это сделано для удобства пользователя, чтобы устранить проблемы с доступом к сайтам даже в случае некорректной конфигурации на стороне сервера. Кроме того, браузеры могут активно искать промежуточные сертификаты в общедоступных базах данных.
### 2. Curl и OpenSSL
Curl, как правило, использует системные корневые сертификаты для проверки SSL-сертификатов. В некоторых случаях, если промежуточный сертификат уже кэширован в системе или присутствует в хранилище сертификатов, Curl может успешно проверить сертификат даже при отсутствии полной цепочки.
Инструмент OpenSSL, вместе с Curl, также обычно строг в требованиях к предоставленной цепочке сертификатов. OpenSSL не осуществляет автоматическое извлечение отсутствующих промежуточных сертификатов и требует, чтобы сервер предоставил полную цепочку.
### 3. Docker
Docker более строго относится к верификации SSL-сертификатов, чем браузеры. Он ожидает, что сервер предоставит полную цепочку, поскольку Docker может выполнять произвольный код из онлайн-репозиториев и иметь доступ к масштабируемым ресурсам внутри сети без песочницы, предоставляемой браузером. Поскольку Docker может взаимодействовать с внутренними сетями и ресурсами с более высокими правами, он требует более строгих мер безопасности, чтобы предотвратить возможные атаки.
### Заключение
Таким образом, различие в требованиях к сертификатам объясняется тем, что разные приложения создавались с разными целями и контекстами использования. Инструменты, ориентированные на конечного пользователя, часто имеют дополнительные функции для поиска промежуточных сертификатов и упрощения процесса верификации. В то время как инструменты, предназначенные для разработчиков или более технических пользователей, обычно ожидают, что полная цепочка будет предоставлена изначально, отражая более строгий подход к безопасности.