В каком порядке проверяются атрибуты сертификата TLS/SSL? Есть ли стандарт?

Question

Представьте себе SSL-сертификат со следующими параметрами - мы создадим наихудший из возможных сертификатов, сделав все возможное неправильно:

• Старый, уязвимый шифр
• Уязвимый алгоритм подписи
• Неправильная подпись (подпись не соответствует содержанию)
• Явно отозван (сертификат на CRL, который мы используем)
• CA явно помечен как ненадежный в хранилище сертификатов
• Неверное доменное имя /CN для подключения
• Истекший
• Дубликат другого сертификата для другого домена
• Сам подписан

Из всех этих состояний ошибок для сертификата, в каком порядке они проверяются пользовательским агентом?

Или, говоря иначе, если бы я использовал этот ужасный сертификат на веб-сайте, какое сообщение об ошибке я бы получил - и как только я это исправлю, что будет дальше, и так далее.

Все эти ошибки имеют различные последствия для безопасности соединения, поэтому некоторые ошибки объективно более страшны, чем другие, но существует ли где-то определенный стандарт, в котором указывается "приоритет" этих проблем? (То есть, говорить, что срок действия сертификата истек, глупо, если он используется не на том веб-сайте и использует неработающее шифрование)

Answer 1

В RFC 5246 говорится следующее о сообщении ServerHello:

Сервер отправит это сообщение в ответ на сообщение ClientHello, когда сможет найти приемлемый набор алгоритмов. Если он не может найти такое совпадение, он ответит предупреждением о сбое рукопожатия.

Следовательно, если шифры, предложенные клиентом, неприемлемы для сервера (при условии, что администратор сервера отключил слабые шифры, а клиент отправляет только слабые шифры), сервер прервет соединение, прежде чем отправит сертификат клиенту.

Если шифры приемлемы, сервер отправляет свой сертификат клиенту. Раздел 6 RFC 5280 описывает проверку пути сертификата. Однако об этом можно сказать следующее:

Соответствующие реализации этой спецификации не требуются для реализации этого алгоритма, но ДОЛЖНЫ обеспечивать функциональность, эквивалентную внешнему поведению, возникающему в результате этой процедуры. Любой алгоритм может использоваться конкретной реализацией, если он получает правильный результат.

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

К сожалению, ваши возможности, вероятно, ограничены:

• Сценарий создания сертификата и тестирования со всеми комбинациями из вашего списка выше и запустить его для всех библиотек;
• Прочитайте исходный код, если он доступен.