Если мой веб-сервер (последняя версия Apache) имеет действительную (не истекшую или отозванную) цепочку сертификатов Verisign (корневой -> промежуточный -> лист / мой сервер), то делает ли сервер Отправить вся (?) цепочка до клиента? Веб-клиент (например, последняя версия Chrome) необходимость искать каждого из тех тем же сертификаты онлайн, особенно если клиент уже доверяет корневому ЦС?
Что произойдет, если клиент не сможет связаться с Verisign? (например, установка LAMP на ноутбуке без Wi-Fi).
Если вы читаете RFC 5246, глава 7.4.2 вы обнаружите, что:
certificate_list
Это последовательность (цепочка) сертификатов. Сертификат отправителя ДОЛЖЕН быть первым в списке. Каждый последующий сертификат ДОЛЖЕН напрямую удостоверять предыдущий. Поскольку для проверки сертификата требуется, чтобы корневые ключи распределялись независимо, самозаверяющий сертификат, указывающий корневой центр сертификации, МОЖЕТ быть исключен из цепочки при условии, что удаленный конец уже должен обладать им, чтобы проверить его в любом случае.
объясняет это довольно хорошо. Действительно ли сервер это делает, зависит от того, как его настроил системный администратор. Многие плохо настроенные серверы «уходят», не выполнив вышеуказанного, из-за того, что многие клиенты могут получить свои сертификаты CA, используя URL-адрес, указанный в расширении AIA.
Многие клиенты также кэшируют сертификаты, которые они получают / загружают, чтобы уменьшить нагрузку на выборку при каждой сборке цепочки. Chrome в Windows использует Microsoft CAPI для управления своими сертификатами (так же, как IE), который кэширует сертификаты. Chrome в Linux / OSX использует NSS Mozilla для управления своими сертификатами, которые также кэшируют сертификаты. Так что есть вероятность, что если вы использовали свой веб-сайт в Интернете, все сертификаты высшего ЦС будут кэшированы в вашей системе, и переход в автономный режим будет работать (в любом случае на некоторое время).
Однако некоторые центры сертификации используют OCSP для проверки отзыва. Если вы не в сети, то клиент OCSP не может связаться с респондентом OCSP для получения информации об отзыве. Что происходит в этом сценарии, зависит от конфигурации вашего клиентского программного обеспечения. По умолчанию большинство браузеров «мягко терпят неудачу» - то есть они игнорируют тот факт, что с респондентом OCSP невозможно связаться, и предполагают, что все в порядке. Некоторые из них могут быть настроены на «жесткий сбой», когда они не будут выполнять проверку отзыва, если с респондентом OCSP невозможно связаться.
То, что отправляет ваш сервер, конечно же, зависит от того, как вы его настроили.
Он отправит содержимое SSLCertificateChainfile файл, если он настроен, и содержимое вашего SSLCertificateFile.
Им не нужен корневой сертификат CA, но, вероятно, следует включать промежуточный сертификат, чтобы клиент мог установить цепочку доверия.
Я не знаю, что происходит в автономном сценарии, но когда вы в автономном режиме, вы все равно не можете использовать мои производственные службы, так что это не проблема, которую я потрудился исследовать. Пожалуйста, проверьте это сами.