Листовой сертификат действителен, цепочка истекла: читайте глубину

Ошибка истечения срока может принадлежать издателю, а не листу. Прочитайте глубину проверки и входные данные доверия, прежде чем обновлять сертификат, который всё ещё выглядит действующим.

Вы проверяете сертификат сервера, видите на часах ещё месяцы, а клиент по-прежнему отклоняет соединение с сообщением об истечении срока. Дата, которую вы читаете, принадлежит листу, а жалоба может касаться чего-то более глубокого в пути. Проверка идёт по цепочке, и любой сертификат, выбранный этим проходом, может не пройти собственное окно действительности. Прочитайте, какой именно не прошёл, прежде чем что-либо обновлять.

Глубина называет сертификат, который не прошёл

В диагностике OpenSSL глубина 0 — это целевой сертификат, а глубина 1 — издатель, который его подписал; большие числа продолжаются к якорю доверия. Истечение срока, о котором сообщено на глубине 1, не опровергается действующим notAfter на листе, поэтому повторная проверка видимого сертификата никогда не объяснит ошибку.

Запишите отпечаток неудачного сертификата вместе с его subject, потому что разные сертификаты могут носить одно и то же имя CA. Перекрёстное подписывание создаёт именно такую ситуацию: один и тот же орган появляется более одного раза, с разными датами действия, и проверяющий выбрал тот, которого вы не ожидали. Знакомая метка — не идентификатор, а отпечаток — это то, что отличает два объекта с одинаковым именем.

Обратите внимание и на продукты с более чем одной ролью сертификата. В OpenVPN Access Server сертификаты, защищающие веб-интерфейсы, отделены от используемых для VPN-подключений, поэтому браузер, открывающий страницу администратора, ничего не доказывает о пути туннеля.

Входные данные доверия — не то же самое, что кандидаты цепочки

Дайте проверяющему два входа отдельно и явно. Файл доверия содержит якоря, которые вы принимаете; недоверенный пакет содержит промежуточные сертификаты, предлагаемые для построения пути. Смешивать их — это способ, которым люди случайно повышают промежуточный сертификат до корня, а затем удивляются, почему та же ошибка преследует их между машинами.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Отключение пути и хранилища по умолчанию с -no-CApath -no-CAstore сохраняет тест честным: результат тогда зависит от указанных вами файлов, а не от того, чему рабочая станция случайно доверяет. Справочник по проверке OpenSSL документирует эти параметры и создаваемую ими диагностику.

-show_chain печатает построенную цепочку, когда проверка успешна, что полезно для подтверждения того, что путь — тот, который вы задумали. Когда она не удаётся, сохраните сообщённые глубину и subject; эти два поля подскажут следующему читателю, какой сертификат проверять.

Чего это не делает — не воспроизводит политику каждого клиента. Pin, ограничение назначения или проверка идентичности, специфичная для клиента, живёт в клиенте, а не в этой команде. Именно эти настройки нужно проверять, когда на сервере проверка проходит, а соединение всё равно не устанавливается. Держите два диагноза отдельно, иначе вы обновите здоровый сертификат, гоняясь за ошибкой pinning.

Что доказывает проверка и что оставляет за рамками

Это проверка пути и назначения по отношению к файлу доверия, который вы предоставили. Для проверки имени HTTPS добавьте ожидаемое имя хоста через соответствующую опцию; для VPN-подключения сохраните настроенные проверки идентичности клиента и используйте тот материал доверия, который этот клиент действительно читает.

То, что отправляет сервер, — это набор кандидатов, а не путь, который в итоге построит ваш клиент. Локальное доверие и правила построения библиотеки вместе формируют результат, поэтому один и тот же ответ может пройти проверку на одной машине и не пройти на другой. Сравните поддерживаемое хранилище доверия и реализацию TLS у неудачного клиента с таковыми у работающего, прежде чем предполагать идентичную оценку. Разница там объясняет многие сообщения «не работает только на этом ноутбуке».

Чтобы увидеть окно каждого сертификата, а не по одному, выведите их как набор:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Вторая команда перечисляет subject и издателей, не декодируя каждый файл вручную, так вы замечаете промежуточный сертификат, чья дата уже прошла, пока лист ещё выглядит нормально.

Исправьте путь, не ослабляя проверку

Когда предоставляется просроченный промежуточный или устаревший перекрёстно подписанный сертификат, получите текущую поддерживаемую цепочку издателя и разверните её через документированный процесс работы с сертификатами сервиса. Когда клиенту не хватает предназначенного поддерживаемого якоря, обновите его управляемую конфигурацию доверия или клиентское программное обеспечение. Сопротивляйтесь сокращению — помечать каждый сертификат в пакете как корень только для того, чтобы заглушить сообщение.

Обработка корня заслуживает замечания, потому что сводки часто её преувеличивают. RFC 5280 рассматривает якорь как вход, находящийся за пределами предполагаемого пути, тогда как OpenSSL документирует проверки действительности, включающие его корневой сертификат CA. Оба утверждения верны для своих систем; обобщение поведения истечения корня одной библиотеки на каждого клиента даёт уверенные неверные ответы.

После изменения принудительно запустите новую аутентификацию на затронутом клиенте и подтвердите, что конкретное сообщение об истечении исчезло. Обновляйте лист только если сам лист непригоден. Отключение проверок времени или восстановление исторического перекрёстного сертификата не создаёт действительный текущий путь; это лишь откладывает следующую ошибку.

Похожие статьи