Будни X509

[klink0v]

... Попался мне тут в поле зрения один сильно китайский девайс. Не суть важно что он из себя представляет, главное знать что унутри у него неонка зашит некий X509-сертификат. Который оная вундервафля использует в качестве клиентского для реализации некоего аналога mTLS при обмене данными с сервером через эти наши интернеты.

Пресловутый клиентский сертификат является третьим в цепочке. Он подписан неким китайским же промежуточным сертификатом. А промежуточный, как водится, восходит к рутовому, которому доверяют сервера всей этой инфраструктуры. Всё "по классике". Вроде бы. Но есть нюанс. ©

Не знаю каким раком, но китайтсы умудрились сгенерировать вот этот "конечный" клиентский (leaf) сертификат так, что у него перепутан порядок полей в ASN.1-множестве "Issuer". То есть все по отдельности они совпадают с одноименными подразделами "Subject" родительского сертификата, но если конкатенировать (собрать, сериализовать) их в строки, то Subject и Issuer будут отличаться как раз по причине того самого "разнобоя". И да, поля AKI / SKI тем не менее у них совпадают, так что именно по этому отдельно взятому критерию проверка валидности проходит.

Как следствие, сервера разделились на две группы: одни пропускают и хавают эту смешную китайскую самодеятельность, а другие отбивают с мотивацией "вы чо тут мне ваще такое прислали". При этом ко второй категории "отбивающих" относятся в том числе и Javaписьные реализации, известные своей мягкостью / халатностью / пофигизмом при проведении проверок такого плана. А вот кем и на чём написаны одобряющие и поощряющие такое поведение серверные приложения, для меня остаётся загадкой. Потому что тот же Python выдвигает куда более строгие требования к X509-сертификатам если речь идёт о его стандартных библиотеках.

Вишенка же на торте заключается в том, что в качестве "третейского судьи" использовать уважаемый всеми OpenSSL не получится. Потому что в энтих всех мЫханизЬмах используется некая спецификация "SGP.22" имени GSMA (кому интересно, можете погуглить что это), которая идет вразрез с IETF-ом и его RFC 5280. И GSMA с**ть (плевать) хотела на IETF, так что полностью переопределила порядок работы X509v3-расширения "X509v3 Name Constraints". Поэтому "openssl verify" здесь вообще ни разу не помощник, ибо он сразу без разговоров отшивает все такие сертификаты по причине несоответствия тех самых Constraints, в то время как по мнению GSMA они вполне себе корректные.

В общем, клиенты катят на нас бочку, мол, мы козлы, поскольку отбиваем подобные китайские вундервафли с их странными сертификатами. Мы отвечаем, что это китайцы рукожопые, все вопросы к ним. Клиенты не верят. А я пошёл гуглить действительно ли порядок полей в Subject / Issuer должен учитываться при проверке сертификата (trust path). И нужно ли вообще их проверять если уже понятно что AKI / SKI совпали. И таки знаете что? Я не нашёл прям вот однозначного ответа на свой вопрос. Такого, чтобы прям вот американским по белому был бы прописан в каком-нибудь IETF RFC, на который можно железобетонно сослаться.

Да, есть последний абзац раздела 7.1 в RFC 5280 про совпадение DN-ов (Distinguished Names). Но можно ли его "притянуть за уши" в контекст сравнения Subject-Issuer лично мне не вполне очевидно. И повторюсь, так же неочевидно, а обязательно ли вообще проверять Subject-Issuer при совпадении AKI-SKI (Authority Key Identifier — Subject Key Identifier).

Чувствую, такими темпами придется потрошить исходные коды библиотеки OpenSSL чтобы понять что на этот счёт думают её разработчики. Где бы только взять на это время и силы.

А какие есть у вас мысли по этому поводу? Только пожалуйста не ссылки на StackOverflow, там везде я уже был. И не выхлоп чат-гопоты. А цитаты конкретных норм из конкретных IETF RFC.