Сервер TLS-was-SSL должен отправлять цепочку сертификатов в правильном порядке в рукопожатии, но некоторые этого не делают, и большинство клиентов, включая OpenSSL, по-прежнему будут обрабатывать его правильно, сопоставляянаверх эмитента = имена субъектов, если листовой сертификат (конечный объект) равен первый .Обратите внимание на след процесса проверки:
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Extended Validation Secure Server CA
verify return:1
depth=0 serialNumber = HRB 73508, jurisdictionC = DE, businessCategory = Private Organization, C = DE, postalCode = 50825, ST = Nordrhein-Westfalen, L = K\C3\B6ln, street = Lichtstra\C3\9Fe 25, O = Eyeo GmbH, OU = COMODO EV SSL, CN = www.adblockplus.org
verify return:1
Вы можете видеть, что сертификаты использовались в правильном порядке сверху вниз, даже если они не были получены в правильном порядке снизу вверх.
Это неправильное поведение достаточно распространено, TLS 1.3 был изменен, чтобы официально разрешить его.Сравните TLS 1.2 в RFC 5246 7.4.2 :
certificate_list ... Сертификат отправителя ДОЛЖЕН быть первым в списке.Каждый следующий сертификат ДОЛЖЕН непосредственно подтверждать предыдущий.Поскольку проверка сертификата требует, чтобы корневые ключи распространялись независимо, самозаверяющий сертификат, который определяет корневой центр сертификации, МОЖЕТ быть исключен из цепочки, при условии, что удаленный конец должен уже иметь его для проверки его в любом случае.
до TLS 1.3 в RFC 8446 4.4.2 , добавлено выделение:
... Сертификат отправителя ДОЛЖЕН быть указан в первом CertificateEntry всписок.Каждый следующий сертификат ДОЛЖЕН непосредственно сертифицировать тот, который непосредственно предшествует ему.Поскольку проверка сертификата требует, чтобы доверительные привязки были распределены независимо, сертификат, который указывает доверенную привязку, МОЖЕТ быть исключен из цепочки при условии, что известно, что поддерживаемые одноранговые узлы обладают любыми пропущенными сертификатами.
Примечание: до TLS 1.3,при заказе «certificate_list» каждый сертификат должен был сертифицировать тот, который непосредственно предшествует ему;однако некоторые реализации допускают некоторую гибкость.Серверы иногда отправляют как текущий, так и устаревший промежуточный продукт для целей перехода, а другие просто неправильно настроены, но эти случаи, тем не менее, могут быть проверены надлежащим образом.Для максимальной совместимости все реализации ДОЛЖНЫ быть готовы обрабатывать потенциально посторонние сертификаты и произвольные заказы из любой версии TLS, за исключением сертификата конечного объекта, который ДОЛЖЕН быть первым.
(И то же самоеtrue в другом направлении для клиентских сертификатов, но они используются очень редко, а серверные сертификаты - почти всегда.)