Добрый день!

Имею следующий код:

cpp = new PKIXBuilderParameters(trustSet, null);
cpp.setSigProvider(null);

List tempCerts = new LinkedList();
tempCerts.addAll(trustList);
tempCerts.add(certificate);
tempCerts.add(crl); //???

CollectionCertStoreParameters par = new CollectionCertStoreParameters(tempCerts);
CertStore store = CertStore.getInstance("Collection", par);
cpp.addCertStore(store);
X509CertSelector selector = new X509CertSelector();
selector.setCertificate((X509Certificate) certificate);
cpp.setTargetCertConstraints(selector);

cpp.setRevocationEnabled(false);
PKIXCertPathBuilderResult res = (PKIXCertPathBuilderResult) CertPathBuilder.getInstance("PKIX").build(cpp);
CertPath cp = res.getCertPath();
CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
cpp.setRevocationEnabled(true);
cpv.validate(cp, cpp);

Вопрос: нужно ли вносить crl (предварительно получив его) в список tempCerts для проверки валидности? crl получен так:

CertificateFactory cf = CertificateFactory.getInstance("X509");
crl = cf.generateCRL(new URL(crlUrl).openStream());

Вопрос возник потому, что в примерах КриптоПро (OCSPValidateCert) crl в список не заносится

Заранее спасибо

Прошу прокомментировать код, а именно строку омеченную ???

Вопрос: надо ли помещать CRL в список tempCerts для проверки или нет? В ваших примерах CRL в список не помещается. Он там нужен или нет? Или КриптоПро сама при построении цепочки подцепит CRL из корневого сертификата?

Отредактировано пользователем 18 ноября 2010 г. 18:06:01(UTC)  | Причина: Не указана

Спасибо за ответы, Iva!

Давайте я еще раз проговорю, а вы поправите если что не так.

Есть три способа проверки валидности сертификата:

1) статический заранее полученный CRL. В этом случае при инициализации CertPathBuilder и CertPathValidator надо поместить crl в list

2) CertPathBuilder и CertPathValidator сами берут crl с crldp корневого сертификата. Необходимо использовать свойство enableCRLDP. crl при этом хранить не нужно.

3) через OCSP протокол

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

Второй и третий способы проще для реализации - не надо обеспечивать обновление и хранение crl. При этом запрос будет обрабатываться дольше.

Отредактировано пользователем 19 ноября 2010 г. 2:47:19(UTC)  | Причина: Не указана

Сообщаю, что у меня работает приведенный в посте №1 вариант со статическим CRL без установки свойства

cpp.setRevocationEnabled(false);

Проверял на двух сертификатах (один валидный и один отозванный) - все работает.





При проверке динамического CRL получаю exception:

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Код:

//---------------------

cpp = new PKIXBuilderParameters(trustSet, null);
cpp.setSigProvider(null);

List tempCerts = new LinkedList();
tempCerts.addAll(trustList);
tempCerts.add(certificate);

CollectionCertStoreParameters par = new CollectionCertStoreParameters(tempCerts);
CertStore store = CertStore.getInstance("Collection", par);
cpp.addCertStore(store);
X509CertSelector selector = new X509CertSelector();
selector.setCertificate((X509Certificate) certificate);
cpp.setTargetCertConstraints(selector);

cpp.setRevocationEnabled(true);
PKIXCertPathBuilderResult res = (PKIXCertPathBuilderResult) CertPathBuilder.getInstance("PKIX").build(cpp);
CertPath cp = res.getCertPath();
CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
cpp.setRevocationEnabled(true);
cpv.validate(cp, cpp);

//---------------------

сертификат УЦ в доверенных присутствует, crl в браузере доступен. Свойства установлены:


javax.security.trustStore = C:\.keystore
javax.security.trustStorePassword = root
com.sun.security.enableCRLDP = true

В чем может быть проблема?

Отредактировано пользователем 22 ноября 2010 г. 15:59:43(UTC)  | Причина: Не указана