#java #security #encryption #ssl #ssl-certificate
#java #Безопасность #шифрование #ssl #ssl-сертификат
Вопрос:
В документации PKIX упоминается:
- Сертификат, представляющий TrustAnchor, не должен быть включен в путь сертификации
Мой вопрос в том, откуда взялось это ограничение? В RFC 5280 я нашел только:
- Сертификат НЕ ДОЛЖЕН появляться более одного раза в предполагаемом пути сертификации.
Подразумевает ли оператор (2) в RFC каким-либо образом оператор (1)? Потому что я этого не вижу.
Какую проблему создало бы наличие привязки доверия также в пути? В конце концов, сертификат TA может проверить себя.
Кто-нибудь, пожалуйста, может объяснить это?
Ответ №1:
Это скорее определение, IIUC. Допустимый путь сертификации определен в RFC 5280, и одним из условий является то, что его первый сертификат подписан привязкой доверия (и что имя эмитента сертификата совпадает с именем привязки доверия). (Привязки доверия не обязательно должны быть сертификатами.)
Комментарии:
1. Вы правы. Объект TA в java может быть инициализирован с помощью открытого ключа и имени. Но если первым в пути указан фактический сертификат TA (согласно 5280) Я не вижу проблемы. Он по-прежнему будет использовать свой собственный ключ для проверки. Причина, по которой я спрашиваю об этом, заключается в том, что в конкретном случае, использующем PKIX api, у меня оказался сертификат TA в качестве первого и единственного сертификата в пути проверки, а также тот же сертификат, переданный в качестве параметра TrustAnchor. Я получил исключение «Не удалось найти допустимый путь». Но сертификат был тем же самым! На этом этапе я теряюсь
2. Я предполагаю, что это просто так: привязка доверия может не быть частью пути сертификации. Я не вижу никакой проблемы в библиотеке, разрешающей это (и просто игнорирующей сертификат привязки доверия, если он является частью пути сертификации), но, похоже, что используемые вами API этого не разрешают. Я не думаю, что происходит что-то особенно глубокое; просто некоторое желание поддерживать соответствие API самим себе и стандартам.