Запрос OCSP для промежуточного сертификата без сертификата эмитента - PullRequest
0 голосов
/ 07 сентября 2018

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

Я написал свою логику цикла, предполагая, что последний сертификат является корневым (CA) сертификатом в цепочке, а не отправлять какой-либо запрос OCSP для него;

    int certificateChainSize= x509Certificates.length;

    // Verifies certificate chain respectively (issuer certificate required).
    CertificateResult response = null;

    try {
        for (int i = 0; i < certificateChainSize-1 ; i++) {
            response = client.verify(x509Certificates[i], x509Certificates[i+1]);
        }
    } catch (OcspException e) {
        e.printStackTrace();
    }

Когда я тестировал TLS и получал перехват Wireshark, я понял, что Google Chrome как клиент отправляет цепочку сертификатов без рута. В следствии; Промежуточный сертификат не запрашивается из-за логики цикла, потому что мой код предполагал, что промежуточный сертификат является корневым. Мне нужен сертификат эмитента для проверки любого сертификата в цепочке. Есть ли механизм проверки без сертификата эмитента (в случае: корневой сертификат).

1 Ответ

0 голосов
/ 07 сентября 2018

Я думаю, ваш дизайн имеет недостатки.

Нет необходимости проверять сертификат на сервере OCSP, если у вас нет корневого сертификата, потому что цепочка ненадежна, а проверка OCSP не имеет смысла.

В основных криптографических библиотеках проверка отзыва происходит как последний шаг, когда создаются все возможные цепочки сертификатов, выбирается лучшая цепочка, и она успешно проверяется на соответствие различным правилам валидации (большинство из них описаны в §6RFC 5280 ).Только когда все проверки успешны, клиент пытается проверить аннулирование для каждого сертификата в цепочке.Успешное построение и проверка цепочки будет означать, что у вас уже есть доверенный корневой сертификат, поскольку действительные цепочки создаются для корневого сертификата.

Кроме того, как было сказано в предыдущем потоке Принудительно отправлять Chromeвсе сертификаты в цепочке во время TLS :

Для максимальной совместимости все реализации ДОЛЖНЫ быть готовы обрабатывать потенциально посторонние сертификаты и произвольные заказы из любой версии TLS, за исключением сертификата конечного объектакоторый ДОЛЖЕН быть первым.

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

response = client.verify(x509Certificates[i], x509Certificates[i+1]);

вернет неожиданные результаты, потому что ее ввод неверен.

что вы действительно должны сделать: позволить криптографической библиотеке ОС (которая поставляется какчасть операционной системы), чтобы сделать самую тяжелую работу.Я настоятельно рекомендую не изобретать свои собственные крипто и использовать проверенные инструменты.У каждой ОС есть API, которые будут создавать, упорядочивать и проверять цепочки сертификатов и возвращать вам лучший.Вы должны использовать эту цепочку в качестве ввода кода проверки OCSP, и ваш цикл for будет считаться надежным (в зависимости от внутренней логики метода verify).

Как я уже сказал, если процесс построения цепочки завершится неудачно, нет особых оснований для выполнения проверки OCSP.

...