Должны ли промежуточные сертификаты добавляться в качестве TrustAnchors при проверке цепочек сертификатов?

Question

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

Скажите, что у меня есть цепь Intermediate -> Intermediate -> Leaf. Меня не волнует root, я хочу проверить до определенного момента в цепочке. Это может быть root или просто фрагмент более длинной цепочки, при условии, что он не поврежден.

Для уточнения; Я хочу проверить эту цепочку независимо от конечного root. Root -> Intermediate 1 -> Intermediate 2 -> Leaf должен быть действительным, а также только Intermediate 1 -> Intermediate 2 -> Leaf. Единственное отличие здесь должно быть (?) В том, что считается TrustAnchor.

Чтобы сделать это, я следовал этой Oracle документации .

Вот мой код фрагмент:

public boolean validateChain(final X509Certificate... certificates) {
    try {
        final CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");


        final X509Certificate intermediateCertificate = certificates[0];
        final X509Certificate leaf = certificates[1];

        final List<X509Certificate> path = Collections.singletonList(leaf);
        final CertPath certPath = certificateFactory.generateCertPath(path);

        Set<TrustAnchor> anchors = new HashSet<>();
        anchors.add(new TrustAnchor(intermediateCertificate, null));

        final X509Certificate root = this.certificate;
        anchors.add(new TrustAnchor(root, null));

        PKIXParameters params = new PKIXParameters(anchors);
        params.setRevocationEnabled(false);

        CertPathValidator validator = CertPathValidator.getInstance("PKIX");
        validator.validate(certPath, params);

        return true;
    } catch (final GeneralSecurityException e) {
        LOG.error("Could not validate certificate chain", e);
    }
    return false;
}

Не обращайте внимания на элементарную обработку массивов, я улучшу это. Эта реализация предполагает, что мой базовый класс был реализован, и это всегда root, по которому проверяются предоставленные сертификаты.

Это правильный способ сделать это? Я не очень понимаю различие между TrustAnchor и сертификатами, помещенными в CertPath.

Если я добавлю сертификат с именем intermediateCertificate в конструкцию CertPath, выполнение завершится неудачно с:

Причина: java .security.cert.CertPathValidatorException: проверка цепочки имени субъекта / эмитента завершилась неудачно

Скажите, если я хочу проверить цепочку с 10 сертификатами, должен только лист сертификат должен быть помещен в CertPath, а все остальные сертификаты, указанные выше в цепочке, считаются TrustAnchors?

Если кто-то может пролить свет на это различие, я был бы очень признателен.

Дополнительно Редактирование информации:

Я знаю, что моя цепочка действительна, потому что я проверил всю свою цепочку, используя OpenSSL. Это вся моя цепочка, в которой каждый файл содержит только публичную c часть сертификата.

openssl verify -CAfile root.pem -untrusted intermediate1.pem -untrusted intermediate2.pem leaf.pem

Я также проверил частичную цепочку:

openssl verify -no-CApath -partial_chain -trusted intermediate1.pem -trusted intermediate2.pem leaf.pem

Оба эти ответить leaf.pem: OK.

Answer 1

Мне придется ответить на мой вопрос, потому что я только что понял, и это была ошибка на моей стороне, но я также могу ответить на поставленный вопрос.

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

Если я читаю право RF C 5280 , то доверие root при работе с сертификатами x509 это просто ключ c, который вы проверяете, что цепочки сертификатов достигают этого источника и следуют заданным ограничениям Т.е. не имеет значения, является ли ваш доверительный якорь root или нет.

Фрагмент в моем исходном сообщении правильный, но у меня есть инициализатор stati c в моем классе, который устанавливает провайдера безопасности :

Security.addProvider(new BouncyCastleProvider());

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

public boolean validateChain(final X509Certificate... certificates) {
    try {
        final CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509", BouncyCastleProvider.PROVIDER_NAME); // <--- Here's the addition

        final List<X509Certificate> path = Arrays.asList(certificates);
        final CertPath certPath = certificateFactory.generateCertPath(path);

        PKIXParameters params = new PKIXParameters(Set.of(new TrustAnchor(this.certificate, null)));
        params.setRevocationEnabled(false);

        CertPathValidator validator = CertPathValidator.getInstance("PKIX");
        validator.validate(certPath, params);

        return true;
    } catch (final GeneralSecurityException e) {
        LOG.error("Could not validate certificate chain", e);
    }
    return false;
}

В этом случае this.certificate - это root. У меня есть класс, который создает объект для обработки сертификатов с поддержкой CA.

Answer 2

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

. Например, если вы доверяете сертификату, выпущенному Let's Encrypt, и вы доверяете Root CA и промежуточному звену, риск доверять всем проблемам сертификатов с помощью сертификатов Let's Encrypt.

Важно проверить цепочку и только лист доверия , если вы хотите убедиться, что доверяете общению. TrustAnchors предназначены только для

СА, пользующихся наибольшим доверием

Так что доверять листу нормально. Это только мое мнение.