Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
API Пути Сертификации JavaTM состоит из классов и интерфейсов для того, чтобы обработать пути сертификации (также известный как "цепочки сертификата"). Путь сертификации является упорядоченным списком сертификатов. Если путь сертификации встречает определенные правила проверки допустимости, он может использоваться, чтобы надежно установить отображение открытого ключа к предмету.
Этот API определяет интерфейсы и абстрактные классы для создания, здания, и проверки допустимости путей сертификации. Реализации могут быть включены в использовании основанного на провайдере интерфейса. API основан на архитектуре Провайдера криптографических служб, описанной в Справочнике Архитектуры Криптографии Java.
API также включает специфичные для алгоритма классы для создания и проверки допустимости путей сертификации X.509 согласно стандартам PKIX. Стандарты PKIX разрабатываются .
Этот API был первоначально определен, используя программа в качестве Запроса Спецификации JavaTM (JSR) 000055. API был включен в SDK JavaTM, запускающийся с Java 2 Standard Edition (JDK), v 1.4. Пожалуйста, отошлите к JSR 055 Домашних страниц для получения дополнительной информации о JSR.
Экспертная группа помогла улучшить и совершенствовать API, используя Процесс Сообщества Java и включает следующие элементы:
те, кто хочет разработать безопасные приложения, которые создают или проверяют путей сертификации.
те, кто хочет записать реализацию поставщика услуг для создания или проверки допустимости путей сертификации.
Сертификаты X.509 и Списки аннулированных сертификатов (CRL)
Как Реализовать Провайдера для Архитектуры Криптографии Java
Пользователи приложений с открытым ключом и систем должны быть уверены, что открытый ключ предмета является подлинным, то есть, что связанный закрытый ключ принадлежит предмету. Сертификаты с открытым ключом используются, чтобы установить это доверие. Открытый ключ (или идентификационные данные) сертификат является привязкой открытого ключа к идентификационным данным, которые в цифровой форме подписываются закрытым ключом другого объекта, часто называемого Центром сертификации (CA). Мы используем термин CA, чтобы обратиться к объекту, который подписывает сертификат для остатка от этого раздела.
Если у пользователя нет доверяемой копии открытого ключа CA, который подписал сертификат предмета с открытым ключом, то другой сертификат с открытым ключом, ручающийся за CA подписания, требуется. Эта логика может быть применена рекурсивно, пока цепочка сертификатов (или путь сертификации) не обнаруживается от доверительной привязки или пользующегося наибольшим доверием CA к целевому предмету (обычно называемый объектом конца). Пользующийся наибольшим доверием CA обычно определяется сертификатом, выпущенным к CA, которому непосредственно доверяет пользователь. Вообще, путь сертификации является упорядоченным списком сертификатов, обычно состоявших из сертификата объекта конца с открытым ключом и нуля или большего количества дополнительных сертификатов. У пути сертификации обычно есть одни или более кодировок, позволяя это быть безопасно переданным через сети и к различной архитектуре операционной системы.
Рисунок 1 иллюстрирует путь сертификации от открытого ключа пользующегося наибольшим доверием CA (CA 1) к целевому предмету (Элис). Путь сертификации устанавливает доверие открытому ключу Элис через промежуточный CA под названием CA2.
Путь сертификации должен быть проверен прежде, чем на него можно будет положиться, чтобы установить доверие открытому ключу предмета. Проверка допустимости может состоять из различных проверок на сертификатах, содержавшихся в пути сертификации, таких как проверка подписей и проверяя, что каждый сертификат не был отменен. Стандарты PKIX определяют алгоритм для того, чтобы проверить путей сертификации, состоящих из сертификатов X.509.
Часто у пользователя, возможно, нет пути сертификации от пользующегося наибольшим доверием CA до предмета. Предоставление услуг, чтобы создать или обнаружить пути сертификации является важной функцией открытого ключа, включенного системы. определяет LDAP (Легкий Протокол Доступа Каталога) определение схемы, которое облегчает открытие путей сертификации X.509, используя протокол службы каталогов LDAP.
Создание и проверка допустимости путей сертификации являются важной частью многих стандартных протоколов системы защиты, таких как SSL/TLS, S/MIME, и IPSEC. API Пути Сертификации JavaTM обеспечивает ряд классов и интерфейсов для разработчиков, которые должны интегрировать эту функциональность в их приложения. Этот API приносит пользу двум типам разработчиков: те, кто должен записать реализации поставщика услуг для определенного алгоритма здания или проверки допустимости пути сертификации; и те, кто должен получить доступ к стандартным алгоритмам для создания, здания, и проверки допустимости путей сертификации независимым от реализации способом.
Базовые классы API Пути Сертификации Java состоят из интерфейсов и классов, которые поддерживают функциональность пути сертификации в алгоритме - и реализации - независимый способ. API также включает ряд специфичных для алгоритма классов для стандартов PKIX, которые обсуждаются в разделе названные Классы PKIX. API основывается и расширяет существующий JavaTM Standard Edition (JDK) java.security.cert пакет для того, чтобы обработать сертификаты. Базовые классы могут быть разбиты в 4 категории class: Основной, Проверка допустимости, Здание, и Хранение:
Основные Классы Пути Сертификации
CertPath, CertificateFactory, CertPathParameters
Классы Проверки допустимости Пути сертификации
CertPathValidator, CertPathValidatorResult
Классы Создания Пути сертификации
CertPathBuilder, CertPathBuilderResult
CertStore, CertStoreParameters, CertSelector, CRLSelector
Следующие разделы описывают обычно используемые методы каждого class и интерфейса. Примеры использования для некоторых из классов вкрапляются всюду по руководству. Полная справочная документация для соответствующих классов API Пути Сертификации может быть найдена в:
Большинство классов и интерфейсов в API CertPath не ориентированы на многопотоковое исполнение. Однако, есть некоторые исключения, которые будут отмечены в этом руководстве и спецификации API. Многократные потоки, которые должны получить доступ к единственному неориентированному на многопотоковое исполнение объекту одновременно, должны синхронизироваться среди себя и обеспечить необходимую блокировку. Многократные потоки каждое управление отдельные объекты не должны синхронизироваться.
Основные классы пути сертификации обеспечивают фундаментальную функциональность для кодирования и представления путей сертификации. Ключевым основным class в API Пути Сертификации Java является CertPath, который инкапсулирует универсальные аспекты, совместно использованные всеми типами путей сертификации. Приложение использует экземпляр CertificateFactory class, чтобы создать объект CertPath.
CertPath class является абстрактный class для путей сертификации. Это определяет функциональность, совместно использованную всеми объектами пути сертификации. Различные типы пути сертификации могут быть реализованы, разделяя на подклассы CertPath class, даже при том, что у них могут быть различное содержание и схемы упорядочивания. Все объекты CertPath являются сериализуемыми, неизменными и ориентированными на многопотоковое исполнение и совместно используют следующие характеристики:
Тип
Это соответствует типу сертификатов в пути сертификации, например: X.509. Тип CertPath получается, используя метод:
public String getType()
См. Приложение A в Справочнике Архитектуры Криптографии Java для информации о стандартных типах сертификата.
Список сертификатов
Метод getCertificates возвращает список сертификатов в пути сертификации:
public abstract List<? extends Certificate> getCertificates()
Этот метод возвращает List нуля или большего количества объектов java.security.cert.Certificate. Возвращенный List и Certificates содержавший в пределах этого являются неизменными, чтобы защитить содержание объекта CertPath. Упорядочивание возвращенных сертификатов зависит от типа. Условно, сертификаты в объекте CertPath типа X.509 упорядочиваются, запускаясь с целевого сертификата и заканчиваясь сертификатом, выпущенным доверительной привязкой. Таким образом, выпускающий одного сертификата является предметом следующего. Сертификат, представляющий TrustAnchor не должен быть включен в путь сертификации. Непроверенный CertPath X.509 s, возможно, не следует за этим соглашением. CertPathValidator PKIX s обнаружит любое отклонение от этих соглашений, которые заставляют путь сертификации быть недопустимым и бросить CertPathValidatorException. Одни или более кодировок
Каждый CertPath объект поддерживает одни или более кодировок. Они - внешние закодированные формы для пути сертификации, используемого, когда стандартное представление пути необходимо вне виртуальной машины Java (передавая путь по сети к некоторой другой стороне). Каждый путь может быть закодирован в формате значения по умолчанию, байты которого возвращаются, используя метод:
public abstract byte[] getEncoded()
Альтернативно, метод getEncoded(String) возвращает определенное поддерживаемое кодирование, определяя формат кодирования как String (исключая: "PKCS7"). Список стандартных форматов кодирования определяется в Приложении A.
public abstract byte[] getEncoded(String encoding)
Кроме того, метод getEncodings возвращает iterator по поддерживаемому формату кодирования String s (формат кодировки по умолчанию возвращается сначала):
public abstract Iterator<String> getEncodings()
Все CertPath объекты также Serializable. CertPath объекты разрешаются в альтернативу CertPathRep объект во время сериализации. Это позволяет a CertPath объект, который будет сериализирован в эквивалентное представление независимо от его базовой реализации.
CertPath объекты сгенерированы от закодированного байтового массива или списка Certificates использующий a CertificateFactory. Альтернативно, a CertPathBuilder может использоваться, чтобы попытаться найти a CertPath от пользующегося наибольшим доверием CA до конкретной темы. Однажды a CertPath объект был создан, он может быть проверен, передавая это к validate метод CertPathValidator. Каждое из этих понятий объясняется более подробно в последующих разделах.
class CertificateFactory является механизмом class, который определяет функциональность фабрики сертификата. В выпусках до JDK v 1.4 это использовалось, чтобы генерировать Certificate и CRL объекты. Это было улучшено в JDK, v 1.4, чтобы также использоваться, чтобы генерировать путь сертификации (CertPath) объекты. CertificateFactory не должен быть перепутан с CertPathBuilder. CertPathBuilder (обсуждал позже) используется, чтобы обнаружить или найти путь сертификации, когда каждый не существует. Напротив, CertificateFactory используется, когда путь сертификации был уже обнаружен, и вызывающая сторона должна инстанцировать объекта CertPath от своего содержания, которое существует в другой форме, такой как закодированный байтовый массив или массив Certificates.
См. CertificateFactory раздел в Справочнике Архитектуры Криптографии Java для деталей о создании a CertificateFactory объект.
Экземпляр CertificateFactory генерирует объекты CertPath от a List из Certificate возражает или от InputStream это содержит закодированную форму a CertPath. Точно так же как a CertPath, каждый CertificateFactory поддерживает формат кодировки по умолчанию для путей сертификации (исключая: PKCS#7). Генерировать a CertPath возразите и инициализируйте это с данными, считанными из входного потока (в формате кодировки по умолчанию), используйте метод generateCertPath:
public final CertPath generateCertPath(InputStream inStream)
или от определенного формата кодирования:
public final CertPath generateCertPath(InputStream inStream,
String encoding)
Чтобы узнать, какие форматы кодирования поддерживаются, используйте метод getCertPathEncodings (кодировка по умолчанию возвращается сначала):
public final Iterator<String> getCertPathEncodings()
Чтобы генерировать объект пути сертификации от List объектов Certificate, используйте следующий метод:
public final CertPath generateCertPath(List<? extends Certificate> certificates)
A CertificateFactory всегда объекты CertPath возвратов, которые состоят из Certificates, которые имеют тот же самый тип как фабрика. Например, CertificateFactory типа X.509 возвращает объекты CertPath, состоящие из сертификатов, которые являются экземпляром java.security.cert.X509Certificate.
Следующий пример кода иллюстрирует генерирование пути сертификации от PKCS#7 закодированный ответ сертификата, сохраненный в файле:
// open an input stream to the file
FileInputStream fis = new FileInputStream(filename);
// instantiate a CertificateFactory for X.509
CertificateFactory cf = CertificateFactory.getInstance("X.509");
// extract the certification path from
// the PKCS7 SignedData structure
CertPath cp = cf.generateCertPath(fis, "PKCS7");
// print each certificate in the path
List<Certificate> certs = cp.getCertificates();
for (Certificate cert : certs) {
System.out.println(cert);
}
Вот другой пример кода, который выбирает цепочку сертификата от a KeyStore и преобразовывает это в a CertPath использование a CertificateFactory:
// instantiate a KeyStore with type JKS
KeyStore ks = KeyStore.getInstance("JKS");
// load the contents of the KeyStore
ks.load(new FileInputStream("./keystore"),
"password".toCharArray());
// fetch certificate chain stored with alias "sean"
Certificate[] certArray = ks.getCertificateChain("sean");
// convert chain to a List
List certList = Arrays.asList(certArray);
// instantiate a CertificateFactory for X.509
CertificateFactory cf = CertificateFactory.getInstance("X.509");
// extract the certification path from
// the List of Certificates
CertPath cp = cf.generateCertPath(certList);
Отметьте, что есть существующий метод в CertificateFactory именованный generateCertificates это анализирует последовательность Certificates. Для кодировок, состоящих из многократных сертификатов, использовать generateCertificates когда Вы хотите проанализировать набор возможно несвязанных сертификатов. Иначе, использовать generateCertPath когда Вы хотите генерировать a CertPath и впоследствии проверьте этого с a CertPathValidator (обсужденный позже).
Интерфейс CertPathParameters является прозрачным представлением набора параметров, используемых с определенным разработчиком пути сертификации или алгоритмом проверки допустимости. Его основная цель состоит в том, чтобы сгруппировать (и обеспечить безопасность типов для), все спецификации параметра пути сертификации. CertPathParameters интерфейс расширяется Cloneable взаимодействуйте через интерфейс и определяет a clone() метод, который не выдает исключение. Все конкретные реализации этого интерфейса должны реализовать и переопределить Object.clone() метод, в случае необходимости. Это позволяет приложениям клонировать любого CertPathParameters объект.
Объекты реализовывая интерфейс CertPathParameters передают как параметры методам классов CertPathBuilder и CertPathValidator. Как правило, конкретная реализация CertPathParameters интерфейс будет содержать ряд входных параметров, определенных для определенного пути сертификации, создают или алгоритм проверки допустимости. Например, PKIXParameters class является реализацией CertPathParameters интерфейс, который содержит ряд входных параметров для алгоритма проверки допустимости пути сертификации PKIX. Один такой параметр является набором пользующейся наибольшим доверием АВАРИИ, которой вызывающая сторона доверяет для того, чтобы привязать процесс проверки допустимости. Этот параметр среди других обсуждается более подробно в разделе, обсуждая PKIXParameters class.
API Пути Сертификации Java включает классы и интерфейсы для того, чтобы проверить путей сертификации. Приложение использует экземпляр CertPathValidator class, чтобы проверить объекта CertPath. В случае успеха результат алгоритма проверки допустимости возвращается в объекте, реализовывая интерфейс CertPathValidatorResult.
CertPathValidator class является механизмом class, используемый, чтобы проверить пути сертификации.
Как со всеми классами механизма, способ получить объект CertPathValidator для определенного алгоритма проверки допустимости состоит в том, чтобы вызвать один из getInstance статические методы фабрики на CertPathValidator class:
public static CertPathValidator getInstance(String algorithm)
public static CertPathValidator getInstance(String algorithm,
String provider)
public static CertPathValidator getInstance(String algorithm,
Provider provider)
algorithm параметр является именем алгоритма проверки допустимости пути сертификации (например, "PKIX"). Стандарт CertPathValidator имена алгоритма перечисляются в Приложении A. Как только объект CertPathValidator создается, пути могут быть проверены, вызывая метод validate, передавая его путь сертификации, который будет проверен и ряд специфичных для алгоритма параметров:
public final CertPathValidatorResult
validate(CertPath certPath, CertPathParameters params)
throws CertPathValidatorException,
InvalidAlgorithmParameterException
Если алгоритм проверки допустимости успешен, результат возвращается в объекте, реализовывая интерфейс CertPathValidatorResult. Иначе, CertPathValidatorException бросается. CertPathValidatorException содержит методы, которые возвращают CertPath, и если релевантный, индексирование сертификата, который заставил алгоритм перестать работать и корневое исключение или причина отказа.
Отметьте что CertPath и CertPathParameters переданный к методу validate должен иметь тип, который поддерживается алгоритмом проверки допустимости. Иначе, InvalidAlgorithmParameterException бросается. Например, экземпляр CertPathValidator, который реализует алгоритм PKIX, проверяет объектов CertPath типа X.509 и CertPathParameters это - экземпляр PKIXParameters.
Интерфейс CertPathValidatorResult является прозрачным представлением успешного результата или выводом алгоритма проверки допустимости пути сертификации. Его основная цель состоит в том, чтобы сгруппировать (и обеспечить безопасность типов для), все результаты проверки допустимости. Как CertPathParameters интерфейс, CertPathValidatorResult расширяется Cloneable и определяет a clone() метод, который не выдает исключение. Это позволяет приложениям клонировать любого CertPathValidatorResult объект.
Объекты реализовывая интерфейс CertPathValidatorResult возвращаются методом validate CertPathValidator (только, когда успешный; иначе a CertPathValidatorException бросается с описанием отказа). Как правило, конкретная реализация CertPathValidatorResult интерфейс будет содержать ряд выходных параметров, определенных для определенного алгоритма проверки допустимости пути сертификации. Например, PKIXCertPathValidatorResult class является реализацией CertPathValidatorResult интерфейс, который содержит методы, чтобы получить выходные параметры алгоритма проверки допустимости пути сертификации PKIX. Один такой параметр является допустимым деревом политики. Этот параметр среди других обсуждается более подробно в разделе, обсуждая PKIXCertPathValidatorResult class.
Вот упрощенный пример кода, который иллюстрирует, как создать a CertPathValidator и используйте это, чтобы проверить пути сертификации. Выборка предполагает что CertPath и CertPathParameters объекты, которые передают к validate метод был ранее создан; более полный пример будет иллюстрирован в разделе, описывающем классы PKIX.
// create CertPathValidator that implements the "PKIX" algorithm
CertPathValidator cpv = null;
try {
cpv = CertPathValidator.getInstance("PKIX");
} catch (NoSuchAlgorithmException nsae) {
System.err.println(nsae);
System.exit(1);
}
// validate certification path ("cp") with specified parameters ("params")
try {
CertPathValidatorResult cpvResult = cpv.validate(cp, params);
} catch (InvalidAlgorithmParameterException iape) {
System.err.println("validation failed: " + iape);
System.exit(1);
} catch (CertPathValidatorException cpve) {
System.err.println("validation failed: " + cpve);
System.err.println("index of certificate that caused exception: "
+ cpve.getIndex());
System.exit(1);
}
API Пути Сертификации Java включает классы для создания (или обнаружение) пути сертификации. Приложение использует экземпляр CertPathBuilder class, чтобы создать объект CertPath. В случае успеха результат создавания возвращается в объекте, реализовывая интерфейс CertPathBuilderResult.
CertPathBuilder class является механизмом class, используемый, чтобы создать путь сертификации.
Как со всеми классами механизма, способ получить объект CertPathBuilder для детали создает алгоритм, должен вызвать один из getInstance статический метод фабрики на CertPathBuilder class:
public static CertPathBuilder getInstance(String algorithm)
public static CertPathBuilder getInstance(String algorithm,
String provider)
public static CertPathBuilder getInstance(String algorithm,
Provider provider)
algorithm параметр является именем разработчика пути сертификации алгоритм (например, "PKIX"). Стандарт CertPathBuilder имена алгоритма перечисляются в Приложении A. Как только объект CertPathBuilder создается, пути могут быть созданы, вызывая метод build, передавая его специфичная для алгоритма спецификация параметра:
public final CertPathBuilderResult build(CertPathParameters params)
throws CertPathBuilderException,
InvalidAlgorithmParameterException
Если создавать алгоритм успешен, результат возвращается в объекте, реализовывая интерфейс CertPathBuilderResult. Иначе, CertPathBuilderException бросается содержащий информацию об отказе; например, базовое исключение (если любой) и сообщение об ошибке.
Отметьте что CertPathParameters переданный к методу build должен иметь тип, который поддерживается создавать алгоритмом. Иначе, InvalidAlgorithmParameterException бросается.
Интерфейс CertPathBuilderResult является прозрачным представлением результата или выводом разработчика пути сертификации алгоритм. Этот интерфейс содержит метод, чтобы возвратить путь сертификации, который был успешно создан:
public CertPath getCertPath()
Цель интерфейса CertPathBuilderResult состоит в том, чтобы сгруппировать (и обеспечить безопасность типов для), все создают результаты. Как CertPathValidatorResult интерфейс, CertPathBuilderResult расширяется Cloneable и определяет a clone() метод, который не выдает исключение. Это позволяет приложениям клонировать любого CertPathBuilderResult объект.
Объекты реализовывая интерфейс CertPathBuilderResult возвращаются методом build CertPathBuilder.
Вот упрощенный пример кода, который иллюстрирует, как создать a CertPathBuilder и используйте это, чтобы создать путь сертификации. Выборка предполагает что CertPathParameters объект, который передают к build метод был ранее создан; более полный пример будет иллюстрирован в разделе, описывающем классы PKIX.
// create CertPathBuilder that implements the "PKIX" algorithm
CertPathBuilder cpb = null;
try {
cpb = CertPathBuilder.getInstance("PKIX");
} catch (NoSuchAlgorithmException nsae) {
System.err.println(nsae);
System.exit(1);
}
// build certification path using specified parameters ("params")
try {
CertPathBuilderResult cpbResult = cpb.build(params);
CertPath cp = cpbResult.getCertPath();
System.out.println("build passed, path contents: " + cp);
} catch (InvalidAlgorithmParameterException iape) {
System.err.println("build failed: " + iape);
System.exit(1);
} catch (CertPathBuilderException cpbe) {
System.err.println("build failed: " + cpbe);
System.exit(1);
}
API Пути Сертификации Java также включает CertStore class для того, чтобы получить сертификаты и CRL от репозитария. Это полезно, потому что это позволяет вызывающей стороне определять репозитарий, который CertPathValidator или реализация CertPathBuilder должны использовать, чтобы найти сертификаты и CRL (см. метод addCertStores PKIXParameters для примера).
Реализация CertPathValidator может использовать объект CertStore, который вызывающая сторона определяет как механизм обратного вызова, чтобы выбрать CRL для того, чтобы выполнить проверки аннулирования. Точно так же a CertPathBuilder может использовать CertStore как механизм обратного вызова, чтобы выбрать certitificates и, выполняя проверки аннулирования, CRL.
CertStore class является механизмом class, используемый, чтобы обеспечить функциональность списка аннулированных сертификатов и списка аннулированных сертификатов (CRL) репозитарий. Это может использоваться CertPathBuilder и реализациями CertPathValidator, чтобы найти сертификаты и CRL или как сертификат общего назначения и механизм извлечения CRL.
В отличие от этого java.security.KeyStore class, который обеспечивает доступ к кэшу закрытых ключей и доверял сертификатам, a CertStore разрабатывается, чтобы обеспечить доступ к потенциально обширному репозитарию недоверяемых сертификатов и CRL. Например, реализация LDAP CertStore обеспечивает доступ к сертификатам и CRL, сохраненным в одном или более каталогах, используя протокол LDAP.
Все открытые методы объектов CertStore ориентированы на многопотоковое исполнение. Таким образом, многократные потоки могут одновременно вызвать эти методы на сингл CertStore объект (или больше чем один) без вредных воздействий. Это позволяет a CertPathBuilder искать CRL, одновременно ища дальнейшие сертификаты, например.
Как со всеми классами механизма, способ получить объект CertStore для определенного типа репозитария состоит в том, чтобы вызвать один из getInstance статические методы фабрики на CertStore class:
public static CertStore getInstance(String type,
CertStoreParameters params)
public static CertStore getInstance(String type,
CertStoreParameters params, String provider)
public static CertStore getInstance(String type,
CertStoreParameters params, Provider provider)
type параметр является именем типа репозитария сертификата (например, "LDAP"). Стандарт CertStore типы перечисляются в Приложении A. Параметры инициализации (params) являются определенными для типа репозитария. Например, параметры инициализации для основанного на сервере репозитария могут включать имя узла и порт сервера. InvalidAlgorithmParameterException бросается, если параметры недопустимы для этого CertStore ввести. getCertStoreParameters метод возвращается CertStoreParameters это использовалось, чтобы инициализировать a CertStore:
public final CertStoreParameters getCertStoreParameters()
Как только Вы создали объект CertStore, можно получить сертификаты от репозитария, используя метод getCertificates. Этот метод берет CertSelector (обсужденный более подробно позже) объект как параметр, который определяет ряд критериев отбора для того, чтобы определить, какие сертификаты должны быть возвращены:
public final Collection<? extends Certificate> getCertificates(CertSelector selector)
throws CertStoreException
Этот метод возвращает Collection объектов java.security.cert.Certificate, которые удовлетворяют критерии отбора. Пустой Collection возвращается, если нет никаких соответствий. A CertStoreException обычно бросается, если с неожиданным состоянием ошибки встречаются, такие как коммуникационный отказ с удаленным репозитарием.
Для некоторых реализаций CertStore, возможно, не выполнимо искать весь репозитарий сертификаты или CRL, которые соответствуют указанные критерии отбора. В этих экземплярах реализация CertStore может использовать информацию, которая определяется в селекторах, чтобы определить местоположение сертификатов и CRL. Например, CertStore LDAP, возможно, не ищет все записи в каталоге. Вместо этого это может только искать записи, которые, вероятно, будут содержать сертификаты, которые это ищет. Если обеспеченный CertSelector не предоставляет достаточную информацию для CertStore LDAP, чтобы определить, какие записи это должно заглянуть, CertStore LDAP может бросить CertStoreException.
Можно также получить CRL от репозитария, используя метод getCRLs. Этот метод берет CRLSelector (обсужденный более подробно позже) объект как параметр, который определяет ряд критериев отбора для того, чтобы определить, какие CRL должны быть возвращены:
public final Collection<? extends CRL> getCRLs(CRLSelector selector)
throws CertStoreException
Этот метод возвращает Collection объектов java.security.cert.CRL, которые удовлетворяют критерии отбора. Пустой Collection возвращается, если нет никаких соответствий.
Интерфейс CertStoreParameters является прозрачным представлением набора параметров, используемых с деталью CertStore. Его основная цель состоит в том, чтобы сгруппировать (и обеспечить безопасность типов для), все спецификации параметра хранения сертификата. CertStoreParameters интерфейс расширяется Cloneable взаимодействуйте через интерфейс и определяет a clone метод, который не выдает исключение. Реализации этого интерфейса должны реализовать и переопределить Object.clone() метод, в случае необходимости. Это позволяет приложениям клонировать любого CertStoreParameters объект.
Объекты реализовывая интерфейс CertStoreParameters передают как параметры методу getInstance CertStore class. Два класса, реализовывая интерфейс CertStoreParameters определяются в этом API: LDAPCertStoreParameters и классы CollectionCertStoreParameters.
LDAPCertStoreParameters class является реализацией CertStoreParameters, взаимодействует через интерфейс, и содержит ряд минимальных параметров инициализации (узел и номер порта сервера каталогов) для того, чтобы получить сертификаты и CRL от a CertStore из типа LDAP.
Пожалуйста, сошлитесь на документацию API LDAPCertStoreParameters для более подробной информации об этом class.
CollectionCertStoreParameters class является реализацией CertStoreParameters, взаимодействует через интерфейс, и содержит ряд параметров инициализации для того, чтобы получить сертификаты и CRL от a CertStore из Набора типа.
Пожалуйста, сошлитесь на документацию API CollectionCertStoreParameters для более подробной информации об этом class.
CertSelector и интерфейсы CRLSelector являются спецификацией набора критериев для того, чтобы выбрать сертификаты и CRL от набора или многочисленной группы сертификатов и CRL. Группа интерфейсов и обеспечивает безопасность типов для всех селекторных спецификаций. Каждый селекторный интерфейс расширяется Cloneable и определяет a clone() метод, который не выдает исключение. Это позволяет приложениям клонировать любого CertSelector или CRLSelector объект.
CertSelector и CRLSelector взаимодействуют через интерфейс, каждый определяет метод под названием match. Метод match берет Certificate или объект CRL как параметр и возвращает true, если объект удовлетворяет критерии отбора. Иначе, это возвращает false. Метод match для интерфейса CertSelector определяется следующим образом:
public boolean match(Certificate cert)
и для интерфейса CRLSelector:
public boolean match(CRL crl)
Как правило, объекты реализовывая эти интерфейсы передают как параметры к getCertificates и getCRLs методы CertStore class. Эти методы возвращают a Collection из Certificates или CRLs от CertStore репозитарий, которые соответствуют указанные критерии отбора. CertSelectors может также использоваться, чтобы определить ограничения проверки допустимости на цель или сертификат объекта конца в пути сертификации (см. например,
PKIXParameters.setTargetCertConstraints
метод.
class X509CertSelector является реализацией интерфейса CertSelector, который определяет ряд критериев для того, чтобы выбрать сертификаты X.509. Объект X509Certificate должен соответствовать все указанные критерии, которые будут выбраны методом match. Критерии отбора разрабатываются, чтобы использоваться реализацией CertPathBuilder, чтобы обнаружить потенциальные сертификаты, поскольку она создает путь сертификации X.509.
Например, setSubject метод X509CertSelector позволяет PKIX CertPathBuilder отфильтровывать X509Certificates, которые не соответствуют имя выпускающего предыдущего X509Certificate в частично завершенной цепочке. Устанавливая это и другие критерии в X509CertSelector объект, a CertPathBuilder в состоянии отбросить несоответствующие сертификаты и более легко найти путь сертификации X.509, который удовлетворяет требования, определенные в CertPathParameters объект.
Пожалуйста, обратитесь к для определений расширений сертификата X.509, упомянутых в этом разделе.
Объект X509CertSelector создается, вызывая конструктора по умолчанию:
public X509CertSelector()
Никакие критерии первоначально не устанавливаются (любой X509Certificate будет соответствовать).
Критерии отбора позволяют вызывающей стороне соответствовать на различных компонентах сертификата X.509. Несколько из методов для того, чтобы установить критерии отбора описываются здесь. Пожалуйста, сошлитесь на документацию API X509CertSelector для деталей о других методах.
Набор методов setIssuer критерий выпускающего:
public void setIssuer(X500Principal issuer)
public void setIssuer(String issuerDN)
public void setIssuer(byte[] issuerDN)
Указанное отличительное имя (в X500Principal, Строка или ASN.1 DER закодированная форма), должен соответствовать отличительное имя выпускающего в сертификате. Если ноль, любое отличительное имя выпускающего сделает. Отметьте то использование X500Principal представлять отличительное имя предпочитается, потому что это более эффективно и соответственно введено.
Точно так же набор методов setSubject подчиненный критерий:
public void setSubject(X500Principal subject)
public void setSubject(String subjectDN)
public void setSubject(byte[] subjectDN)
Указанное отличительное имя (в X500Principal, Строка RFC 2253 или ASN.1 DER закодированная форма), должен соответствовать подчиненное отличительное имя в сертификате. Если ноль, любое подчиненное отличительное имя сделает.
Метод setSerialNumber устанавливает serialNumber критерий:
public void setSerialNumber(BigInteger serial)
Указанный порядковый номер должен соответствовать порядковый номер сертификата в сертификате. Если ноль, любой порядковый номер сертификата сделает.
Метод setAuthorityKeyIdentifier устанавливает authorityKeyIdentifier критерий:
public void setAuthorityKeyIdentifier(byte[] authorityKeyID)
Сертификат должен содержать Ключевое расширение Идентификатора Властей, соответствующее указанное значение. Если ноль, никакая проверка не будет сделана на authorityKeyIdentifier критерии.
Метод setCertificateValid устанавливает certificateValid критерий:
public void setCertificateValid(Date certValid)
Указанная дата должна находиться в пределах срока действия сертификата для сертификата. Если ноль, любая дата допустима.
Метод setKeyUsage устанавливает keyUsage критерий:
public void setKeyUsage(boolean[] keyUsage)
Ключевое Расширение Использования сертификата должно позволить указанные ключевые значения использования (те, которые устанавливаются в истину). Если ноль, никакая проверка keyUsage не будет сделана.
Текущая стоимость для каждых из критериев отбора может быть получена, используя соответствующий метод get. Пожалуйста, сошлитесь на документацию API X509CertSelector для получения дальнейшей информации относительно этих методов.
Вот пример получения сертификатов X.509 от CertStore LDAP с X509CertSelector class.
Во-первых, мы создаем LDAPCertStoreParameters возразите, что мы будем использовать, чтобы инициализировать CertStore объект с именем узла и портом сервера LDAP:
LDAPCertStoreParameters lcsp = new
LDAPCertStoreParameters("ldap.sun.com", 389);
Затем, создайте объект CertStore, и передайте его LDAPCertStoreParameters объект, как в следующем операторе:
CertStore cs = CertStore.getInstance("LDAP", lcsp);
Этот вызов создает объект CertStore, который получает сертификаты и CRL от репозитария LDAP, используя схему, определенную в RFC 2587.
Следующий блок кода устанавливает X509CertSelector получать всех неистекших (с текущей даты и время) сертификаты объекта конца, выпущенные к конкретной теме с 1) ключевым использованием, которое позволяет цифровые подписи, и 2) подчиненное альтернативное имя с определенным адресом электронной почты:
X509CertSelector xcs = new X509CertSelector();
// select only unexpired certificates
xcs.setCertificateValid(new Date());
// select only certificates issued to
// 'CN=alice, O=xyz, C=us'
xcs.setSubject(new X500Principal("CN=alice, O=xyz, C=us"));
// select only end-entity certificates
xcs.setBasicConstraints(-2);
// select only certificates with a digitalSignature
// keyUsage bit set (set the first entry in the
// boolean array to true)
boolean[] keyUsage = {true};
xcs.setKeyUsage(keyUsage);
// select only certificates with a subjectAltName of
// 'alice@xyz.example.com' (1 is the integer value of
// an RFC822Name)
xcs.addSubjectAlternativeName(1, "alice@xyz.example.com");
Затем мы передаем селектор к методу getCertificates нашего объекта CertStore, который мы ранее создали:
Collection<Certificate> certs = cs.getCertificates(xcs);
PKIX CertPathBuilder может использовать подобный код, чтобы помочь обнаружить и отсортировать потенциальные сертификаты, отбрасывая тех, которые не встречают ограничения проверки допустимости или другие критерии.
class X509CRLSelector является реализацией интерфейса CRLSelector, который определяет ряд критериев для того, чтобы выбрать CRL X.509. Объект X509CRL должен соответствовать все указанные критерии, которые будут выбраны методом match. Критерии отбора разрабатываются, чтобы быть полезными для CertPathValidator или реализации CertPathBuilder, которая должна получить CRL от репозитария, чтобы проверить состояние аннулирования сертификатов в пути сертификации X.509.
Например, setDateAndTime метод X509CRLSelector позволяет PKIX CertPathValidator отфильтровывать X509CRLs, которые были выпущены после или истекают перед указанным временем. Устанавливая это и другие критерии в X509CRLSelector объект, это позволяет CertPathValidator отбрасывать несоответствующие CRL и более легко проверять, был ли сертификат отменен.
Пожалуйста, обратитесь к для определений полей CRL X.509 и расширений, упомянутых в этом разделе.
Объект X509CRLSelector создается, вызывая конструктора по умолчанию:
public X509CRLSelector()
Никакие критерии первоначально не устанавливаются (любой X509CRL будет соответствовать).
Критерии отбора позволяют вызывающей стороне соответствовать на различных компонентах CRL X.509. Большинство методов для того, чтобы установить критерии отбора описывается здесь. Пожалуйста, сошлитесь на документацию API X509CRLSelector для деталей об остающихся методах.
setIssuers и набор методов setIssuerNames issuerNames критерий:
public void setIssuers(Collection<X500Principal> issuers)
public void setIssuerNames(Collection<?> names)
Отличительное имя выпускающего в CRL должно соответствовать по крайней мере одно из указанных отличительных имен. setIssuers метод предпочитается как использование X500Principals, чтобы представить отличительные имена более эффективно и соответственно введен. Для setIssuerNames метод, каждой записью параметра names является или String или байтовый массив (представляющий имя, в RFC 2253 или ASN.1 DER закодированная форма, соответственно). Если ноль, любое отличительное имя выпускающего сделает.
Набор методов setMinCRLNumber И setMaxCRLNumber minCRLNumber и maxCRLNumber критерий:
public void setMinCRLNumber(BigInteger minCRL)
public void setMaxCRLNumber(BigInteger maxCRL)
У CRL должно быть расширение Числа CRL, значение которого больше чем или равно указанному значению, если метод setMinCRLNumber вызывают, и меньше чем или равный указанному значению, если метод setMaxCRLNumber вызывают. Если значение, которое передают к одному из этих методов, является нулем, соответствующая проверка не делается.
Метод setDateAndTime устанавливает dateAndTime критерий:
public void setDateAndTime(Date dateAndTime)
Указанная дата должна быть равной или позже чем значение thisUpdate компонента CRL и ранее чем значение nextUpdate компонента. Если ноль, никакая проверка dateAndTime не будет сделана.
Метод setCertificateChecking устанавливает сертификат, состояние аннулирования которого проверяется:
public void setCertificateChecking(X509Certificate cert)
Это не критерий. Скорее это - дополнительная информация, которая может помочь a CertStore найдите CRL, которые были бы релевантны, проверяя аннулирование на указанный сертификат. Если нуль определяется, то никакая такая дополнительная информация не предоставляется. Приложение должно всегда вызывать этот метод, проверяя аннулирование на определенный сертификат, поскольку это может обеспечить CertStore с большей информацией для того, чтобы найти корректные CRL и отфильтровать несоответствующие.
Текущая стоимость для каждых из критериев отбора может быть получена, используя соответствующий метод get. Пожалуйста, сошлитесь на документацию API X509CRLSelector для получения дальнейшей информации относительно этих методов.
Создание X509CRLSelector, чтобы получить CRL от репозитария LDAP подобно примеру X509CertSelector. Предположите, что мы хотим получить весь ток (с текущей даты и время) CRL, выпущенные определенным CA и с минимальным числом CRL. Во-первых, мы создаем объект X509CRLSelector и вызываем соответствующие методы, чтобы установить критерии отбора:
X509CRLSelector xcrls = new X509CRLSelector();
// select CRLs satisfying current date and time
xcrls.setDateAndTime(new Date());
// select CRLs issued by 'O=xyz, C=us'
xcrls.addIssuerName("O=xyz, C=us");
// select only CRLs with a CRL number at least '2'
xcrls.setMinCRLNumber(new BigInteger("2"));
Затем мы передаем селектор к методу getCRLs нашего объекта CertStore (создаваемый в примере X509CertSelector):
Collection<CRL> crls = cs.getCRLs(xcrls);
API Пути Сертификации Java также включает ряд специфичных для алгоритма классов, смоделированных для использования с алгоритмом проверки допустимости пути сертификации PKIX, определенным в : Список аннулированных сертификатов Инфраструктуры управления открытыми ключами и Список аннулированных сертификатов (CRL) Профиль.
Этот class представляет "пользующийся наибольшим доверием CA", который используется в качестве доверительной привязки для того, чтобы проверить путей сертификации X.509. Пользующийся наибольшим доверием CA включает открытый ключ CA, имени CA, и любых ограничений на набор путей, которые могут быть проверены, используя этот ключ. Эти параметры могут быть определены в форме доверяемого X509Certificate или как отдельные параметры.
Все TrustAnchor объекты являются неизменными и ориентированными на многопотоковое исполнение. Таким образом, многократные потоки могут одновременно вызвать методы, определенные в этом class на сингле TrustAnchor объект (или больше чем один) без вредных воздействий. Требование TrustAnchor объекты быть неизменным и ориентированный на многопотоковое исполнение позволяют им быть розданными к различным частям кода, не волнуясь о координировании доступа.
Отметьте, что, хотя этот class описывается как class PKIX, он может использоваться с другими алгоритмами проверки допустимости пути сертификации X.509.
Инстанцировать a TrustAnchor объект, вызывающая сторона должна определить "пользующийся наибольшим доверием CA" как доверяемое X509Certificate или пара и отличительного имени с открытым ключом. Вызывающая сторона может также дополнительно определить ограничения имени, которые применяются к доверительной привязке алгоритмом проверки допустимости во время инициализации. Отметьте, что поддержка ограничений имени на доверительные привязки не требуется алгоритмом PKIX, поэтому PKIX CertPathValidator или CertPathBuilder может хотеть не поддерживать этот параметр и вместо этого выдавать исключение. Используйте одного из следующих конструкторов, чтобы создать a TrustAnchor объект:
public TrustAnchor(X509Certificate trustedCert,
byte[] nameConstraints)
public TrustAnchor(X500Principal caPrincipal, PublicKey pubKey,
byte[] nameConstraints)
public TrustAnchor(String caName, PublicKey pubKey,
byte[] nameConstraints)
nameConstraints параметр является specifed как байтовым массивом, содержащим ASN.1 DER кодирование расширения NameConstraints. IllegalArgumentException бросается, если ограничения имени не могут декодироваться (не форматируются правильно).
Каждый из параметров может быть получен, используя соответствие, получают метод:
public final X509Certificate getTrustedCert()
public final X500Principal getCA()
public final String getCAName()
public final PublicKey getCAPublicKey()
public final byte[] getNameConstraints()
Отметьте что getTrustedCert возвраты метода null если доверительная привязка была определена как пара имени и открытый ключ. Аналогично, getCA, getCAName и getCAPublicKey возврат методов null если доверительная привязка была определена как X509Certificate. Этот class (который реализует интерфейс CertPathParameters) определяет набор входных параметров, определенных алгоритмом проверки допустимости пути сертификации PKIX. Это также включает несколько дополнительных полезных параметров.
X.509 CertPath возразите и объект PKIXParameters передаются как параметры методу validate экземпляра CertPathValidator, реализовывая алгоритм PKIX. CertPathValidator использует параметры, чтобы инициализировать алгоритм проверки допустимости пути сертификации PKIX.
Инстанцировать a PKIXParameters объект, вызывающая сторона должна определить "пользующийся наибольшим доверием CA ()" как определено алгоритмом проверки допустимости PKIX. Пользующаяся наибольшим доверием АВАРИЯ может быть определена, используя одного из двух конструкторов:
public PKIXParameters(Set<TrustAnchor> trustAnchors)
throws InvalidAlgorithmParameterException
public PKIXParameters(KeyStore keystore)
throws KeyStoreException, InvalidAlgorithmParameterException
Первый конструктор позволяет вызывающей стороне определять пользующуюся наибольшим доверием АВАРИЮ как a Set из TrustAnchor объекты. Альтернативно, вызывающая сторона может использовать второго конструктора и определить a KeyStore экземпляр, содержащий, доверял записям сертификата, каждую из которых рассмотрят как пользующийся наибольшим доверием CA.
Как только объект PKIXParameters был создан, вызывающая сторона может установить (или заменить текущую стоимость), различные параметры. Несколько из методов для того, чтобы установить параметры описываются здесь. Пожалуйста, сошлитесь на документацию API PKIXParameters для деталей о других методах.
Метод setInitialPolicies устанавливает начальные идентификаторы политики, как определено алгоритмом проверки допустимости PKIX. Элементы Set являются объектными идентификаторами (OID), представленные как String. Если initialPolicies параметр является нулем или не набором, любая политика является приемлемой:
public void setInitialPolicies(Set<String> initialPolicies)
Метод setDate устанавливает время, в течение которого должна быть определена законность пути. Если параметры date не устанавливаются или являются нулем, текущая дата используется:
public void setDate(Date date)
Метод setPolicyMappingInhibited устанавливает значение политики, отображающей запрещенный флаг. Значение по умолчанию для флага, если не определенный, является ложью:
public void setPolicyMappingInhibited(boolean val)
Метод setExplicitPolicyRequired устанавливает значение явной политики требуемый флаг. Значение по умолчанию для флага, если не определенный, является ложью:
public void setExplicitPolicyRequired(boolean val)
Метод setAnyPolicyInhibited устанавливает значение любой политики запрещенный флаг. Значение по умолчанию для флага, если не определенный, является ложью:
public void setAnyPolicyInhibited(boolean val)
Метод setTargetCertConstraints позволяет вызывающей стороне устанавливать ограничения на сертификат объекта конца или цель. Например, вызывающая сторона может определить, что целевой сертификат должен содержать определенное подчиненное имя. Ограничения определяются как a CertSelector объект. Если selector параметр является нулем или не набором, никакие ограничения не определяются на целевом сертификате:
public void setTargetCertConstraints(CertSelector selector)
Метод setCertStores позволяет вызывающей стороне определять a List из объектов CertStore, которые будут использоваться реализацией PKIX CertPathValidator, чтобы найти CRL для проверки допустимости пути. Это обеспечивает расширяемый механизм для того, чтобы он определил, где определить местоположение CRL. Метод setCertStores берет a List из CertStore возражает в качестве параметра. Первый CertStore s в списке может быть предпочтен тем, которые появляются позже.
public void setCertStores(List<CertStore> stores)
Метод setCertPathCheckers позволяет вызывающей стороне расширять алгоритм проверки допустимости PKIX, создавая специфичные для реализации средства проверки пути сертификации. Например, этот механизм может использоваться, чтобы обработать частные расширения сертификата. Метод setCertPathCheckers берет список PKIXCertPathChecker (обсуждал позже), объекты в качестве параметра:
public void setCertPathCheckers(List<PKIXCertPathChecker> checkers)
Метод setRevocationEnabled позволяет вызывающей стороне отключать проверку аннулирования. Проверка аннулирования включается по умолчанию, так как это - необходимая проверка алгоритма проверки допустимости PKIX. Однако, PKIX не определяет, как аннулирование должно быть проверено. Реализация может использовать CRL или OCSP, например. Этот метод позволяет вызывающей стороне отключать механизм проверки аннулирования значения по умолчанию реализации, если это не является соответствующим. Различный механизм проверки аннулирования может тогда быть определен, вызывая метод setCertPathCheckers, и передавая его a PKIXCertPathChecker это реализует альтернативный механизм.
public void setRevocationEnabled(boolean val)
Метод setPolicyQualifiersRejected позволяет вызывающей стороне включать или отключать обработку спецификатора политики. Когда объект PKIXParameters создается, этот флаг устанавливается в true. Эта установка отражает наиболее распространенное (и самый простой) стратегия обработки спецификаторов политики. Приложения, которые хотят использовать более сложную политику, должны установить этот флаг в false.
public void setPolicyQualifiersRejected(boolean qualifiersRejected)
Текущая стоимость для каждого из параметров может быть получена, используя соответствующий метод get. Пожалуйста, сошлитесь на документацию API PKIXParameters для получения дальнейшей информации относительно этих методов.
Этот class (который реализует интерфейс CertPathValidatorResult) представляет результат алгоритма проверки допустимости пути сертификации PKIX. Это содержит допустимую политику древовидный и подчиненный открытый ключ, следующий из алгоритма проверки допустимости, и включает методы (getPolicyTree() и getPublicKey()) для того, чтобы возвратить их. Экземпляры PKIXCertPathValidatorResult возвращаются методом validate объектов CertPathValidator, реализовывая алгоритм PKIX.
Пожалуйста, сошлитесь на документацию API PKIXCertPathValidatorResult для более подробной информации об этом class.
Алгоритм проверки допустимости PKIX определяет несколько выводов, связанных с обработкой политики сертификата. Большинство приложений не должно будет использовать эти выводы, но все провайдеры, которые реализуют алгоритм проверки допустимости или здания PKIX, должны поддерживать их.
PolicyNode интерфейс представляет узел допустимого дерева политики, следующего из успешного выполнения проверки допустимости пути сертификации PKIX. Приложение может получить корень допустимого дерева политики использование getPolicyTree метод PKIXCertPathValidatorResult. Деревья политики обсуждаются более подробно в .
getPolicyQualifiers метод PolicyNode возвраты a Set из PolicyQualifierInfo объекты, каждый из которых представляет спецификатор политики, содержавшийся в расширении Политик Сертификата соответствующего сертификата, которому применяется к эта политика.
Большинство приложений не должно будет исследовать допустимое дерево политики и спецификаторы политики. Они могут достигнуть своих целей обработки политики, устанавливая связанные с политикой параметры в PKIXParameters. Однако, допустимое дерево политики доступно для более сложных приложений, особенно те, которые обрабатывают спецификаторы политики.
Пожалуйста, обратитесь к PolicyNode и PolicyQualifierInfo Документация API для более подробной информации об этих классах.
Это - пример проверки допустимости пути сертификации с алгоритмом проверки допустимости PKIX. Пример игнорирует большую часть обработки исключений и предполагает, что путь сертификации и открытый ключ доверительной привязки были уже созданы.
Во-первых, создайте CertPathValidator, как в следующей строке:
CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
Следующий шаг должен создать объект TrustAnchor. Это будет использоваться в качестве привязки для того, чтобы проверить пути сертификации. В этом примере пользующийся наибольшим доверием CA определяется как открытый ключ, и имя (ограничения имени не применяются и определяются как null):
TrustAnchor anchor = new TrustAnchor("O=xyz,C=us", pubkey, null);
Следующий шаг должен создать объект PKIXParameters. Это будет использоваться, чтобы заполнить параметры, используемые алгоритмом PKIX. В этом примере мы передаем конструктору a Set содержа единственный элемент - TrustAnchor мы создали в предыдущем шаге:
PKIXParameters params = new PKIXParameters(Collections.singleton(anchor));
Затем, мы заполняем объект параметров с ограничениями или другими параметрами, используемыми алгоритмом проверки допустимости. В этом примере мы включаем флагу explicitPolicyRequired и определяем ряд начальных OID политики (содержание набора не показывают):
// set other PKIX parameters here
params.setExplicitPolicyRequired(true);
params.setInitialPolicies(policyIds);
Заключительный шаг должен проверить пути сертификации, используя входной набор параметра, который мы создали:
try {
PKIXCertPathValidatorResult result =
(PKIXCertPathValidatorResult) cpv.validate(certPath, params);
PolicyNode policyTree = result.getPolicyTree();
PublicKey subjectPublicKey = result.getPublicKey();
} catch (CertPathValidatorException cpve) {
System.out.println("Validation failure, cert["
+ cpve.getIndex() + "] :" + cpve.getMessage());
}
Если алгоритм проверки допустимости успешен, политика, древовидный и подчиненный открытый ключ, следующий из алгоритма проверки допустимости, получается, используя getPolicyTree и getPublicKey методы PKIXCertPathValidatorResult.
Иначе, CertPathValidatorException бросается, и вызывающая сторона может поймать исключение и напечатать некоторые детали об отказе, такие как сообщение об ошибке и индексирование сертификата, который вызвал отказ.
Этот class (который расширяет PKIXParameters class) определяет набор параметров, которые будут использоваться с CertPathBuilder s, которые создают пути сертификации, проверенные против алгоритма проверки допустимости пути сертификации PKIX.
Объект PKIXBuilderParameters передают как параметр методу build экземпляра CertPathBuilder, реализовывая алгоритм PKIX. Весь CertPathBuilder PKIX s должен возвратить пути сертификации, которые были проверены согласно алгоритму проверки допустимости пути сертификации PKIX.
Пожалуйста, отметьте что механизм что PKIX CertPathBuilder использование, чтобы проверить созданного пути является деталью реализации. Например, реализация могла бы попытаться сначала создать путь с минимальной проверкой допустимости и затем полностью проверить ее использующий экземпляр PKIX CertPathValidator, тогда как более эффективная реализация может проверить большего количества пути, поскольку это создает это, и отслеживание в обратном порядке к предыдущим этапам, если это встречается с отказами проверки допустимости или тупиками.
Создание объекта PKIXBuilderParameters подобно созданию объекта PKIXParameters. Однако, вызывающая сторона должна определить ограничения на цель или сертификат объекта конца, создавая объект PKIXBuilderParameters. Эти ограничения должны обеспечить CertPathBuilder с достаточной информацией, чтобы найти целевой сертификат. Ограничения определяются как a CertSelector объект. Используйте одного из следующих конструкторов, чтобы создать объект PKIXBuilderParameters:
public PKIXBuilderParameters(Set<TrustAnchor> trustAnchors,
CertSelector targetConstraints)
throws InvalidAlgorithmParameterException
public PKIXBuilderParameters(KeyStore keystore,
CertSelector targetConstraints)
throws KeyStoreException, InvalidAlgorithmParameterException
class PKIXBuilderParameters наследовал все параметры, которые могут быть установлены в PKIXParameters class. Кроме того, метод setMaxPathLength можно вызвать, чтобы установить границу максимального количества сертификатов в пути сертификации:
public void setMaxPathLength(int maxPathLength)
Параметр maxPathLength определяет максимальное количество не сам выпущенные промежуточные сертификаты, которые могут существовать в пути сертификации. Экземпляр CertPathBuilder, реализовывая алгоритм PKIX не должен создать пути дольше чем определенная длина. Если значение 0, путь может только содержать единственный сертификат. Если значение-1, длина пути неограничена (то есть, нет никакого максимума). Длина пути максимума значения по умолчанию, если не определенный, 5. Этот метод полезен, чтобы предотвратить CertPathBuilder от расходов ресурсов и время, создавая длинные пути, которые могут или, возможно, не удовлетворяют требования вызывающей стороны.
Если какой-либо из сертификатов CA в пути содержит Основное Ограничительное расширение, значение pathLenConstraint компонента расширения переопределяет значение параметра maxPathLength всякий раз, когда результатом является путь сертификации меньшей длины. Есть также соответствие getMaxPathLength метод для того, чтобы получить этот параметр:
public int getMaxPathLength()
Кроме того, метод setCertStores (наследованный от PKIXParameters class), обычно используется реализацией PKIX CertPathBuilder, чтобы найти Сертификаты для конструкции пути так же как CRL открытия для проверки допустимости пути. Это обеспечивает расширяемый механизм для того, чтобы он определил, где определить местоположение Сертификатов и CRL.
Этот class (то, который расширяет PKIXCertPathValidatorResult class и реализует интерфейс CertPathBuilderResult), представляет успешный результат алгоритма конструкции пути сертификации PKIX. Экземпляры PKIXCertPathBuilderResult возвращаются методом build объектов CertPathBuilder, реализовывая алгоритм PKIX.
Метод getCertPath экземпляра PKIXCertPathBuilderResult всегда возвращается, объект CertPath проверил использования алгоритма проверки допустимости пути сертификации PKIX. Возвращенный объект CertPath не включает пользующийся наибольшим доверием сертификат CA, который, возможно, использовался, чтобы привязать путь. Вместо этого используйте getTrustAnchor метод, чтобы добраться Certificate из пользующегося наибольшим доверием CA.
Пожалуйста, сошлитесь на документацию API PKIXCertPathBuilderResult для более подробной информации об этом class.
Это - пример создания пути сертификации, проверенного против алгоритма PKIX. Некоторые детали были не учтены, такие как обработка исключений, и создание доверительных привязок и сертификатов для того, чтобы заполнить CertStore.
Во-первых, создайте CertPathBuilder, как в следующем примере:
CertPathBuilder cpb = CertPathBuilder.getInstance("PKIX");
Этот вызов создает объект CertPathBuilder, который возвращает пути, проверенные против алгоритма PKIX.
Следующий шаг должен создать объект PKIXBuilderParameters. Это будет использоваться, чтобы заполнить параметры PKIX, используемые CertPathBuilder:
// Create parameters object, passing it a Set of
// trust anchors for anchoring the path
// and a target subject DN.
X509CertSelector targetConstraints = new X509CertSelector();
targetConstraints.setSubject("CN=alice,O=xyz,C=us");
PKIXBuilderParameters params =
new PKIXBuilderParameters(trustAnchors, targetConstraints);
Следующий шаг должен определить CertStore, который CertPathBuilder будет использовать, чтобы искать сертификаты и CRL. Для этого примера мы заполним Набор CertStore с сертификатами и CRL:
CollectionCertStoreParameters ccsp =
new CollectionCertStoreParameters(certsAndCrls);
CertStore store = CertStore.getInstance("Collection", ccsp);
params.addCertStore(store);
Следующий шаг должен создать путь сертификации, используя входной набор параметра, который мы создали:
try {
PKIXCertPathBuilderResult result =
(PKIXCertPathBuilderResult) cpb.build(params);
CertPath cp = result.getCertPath();
} catch (CertPathBuilderException cpbe) {
System.out.println("build failed: " + cpbe.getMessage());
}
Если CertPathBuilder не может создать путь, который встречает предоставленные параметры, он бросит CertPathBuilderException. Иначе, проверенный путь сертификации может быть получен из PKIXCertPathBuilderResult, используя getCertPath метод.
Этот раздел описывает мощный class, который позволяет пользователю расширять CertPathValidator PKIX или реализацию CertPathBuilder. Это - расширенная функция, которую не должно будет понять большинство пользователей. Однако, любой реализовывая поставщика услуг PKIX должен считать этот раздел.
PKIXCertPathChecker class является абстрактный class, который выполняется один или больше проверяет сертификат X.509. Разработчики должны создать конкретные реализации PKIXCertPathChecker class, когда необходимо динамически расширить CertPathValidator PKIX или реализацию CertPathBuilder во времени выполнения. Следующее является несколькими примерами того, когда реализация PKIXCertPathChecker полезна:
Если механизм аннулирования, предоставленный CertPathValidator PKIX или реализацией CertPathBuilder, не соответствует. Например, разработчик мог бы реализовать PKIXCertPathChecker, который использует OCSP , чтобы проверить, что сертификаты не были отменены.
Если пользователь хочет распознать сертификаты, содержащие критическое частное расширение. Так как расширение является частным, оно не будет распознано CertPathValidator PKIX или реализацией CertPathBuilder, и CertPathValidatorException будет брошен. В этом случае разработчик может реализовать PKIXCertPathChecker, который распознает и обрабатывает критическое частное расширение.
Если разработчик хочет записать информацию о каждом сертификате, обработанном в целях дисплея или отладке.
Если пользователь хочет отклонить сертификаты с определенными спецификаторами политики.
Метод setCertPathCheckers PKIXParameters class позволяет пользователю передавать a List из PKIXCertPathChecker возражает против CertPathValidator PKIX или реализации CertPathBuilder. Каждый из объектов PKIXCertPathChecker вызовут поочередно для каждого сертификата, обработанного CertPathValidator PKIX или реализацией CertPathBuilder.
У PKIXCertPathChecker class нет общедоступного конструктора. Это является намеренным, начиная с создания экземпляра PKIXCertPathChecker специфичная для реализации проблема. Например, конструктор для реализации PKIXCertPathChecker, которая использует OCSP, чтобы проверить состояние аннулирования сертификата, может потребовать имени узла и порта сервера OCSP:
PKIXCertPathChecker checker = new OCSPChecker("ocsp.sun.com", 1321);
Как только средство проверки инстанцировали, оно может быть добавлено как параметр, используя метод addCertPathChecker PKIXParameters class:
params.addCertPathChecker(checker);
Альтернативно, List средств проверки может быть добавлен, используя метод setCertPathCheckers PKIXParameters class.
PKIXCertPathChecker class абстрактен. У этого есть четыре метода (check, getSupportedExtensions, init, и isForwardCheckingSupported), который должны реализовать все конкретные подклассы.
Реализация PKIXCertPathChecker может быть тривиальной или сложной. Реализация PKIXCertPathChecker может быть не сохраняющей состояние или stateful. Реализация не сохраняющая состояние не поддерживает состояние между последовательными вызовами метода check. Например, PKIXCertPathChecker, который проверяет, что каждый сертификат содержит определенный спецификатор политики, является не сохраняющим состояние. Напротив, stateful реализация действительно поддерживает состояние между последовательными вызовами метода check. Метод check stateful реализации обычно зависит от содержания предшествующих сертификатов в пути сертификации. Например, PKIXCertPathChecker, который обрабатывает расширение NameConstraints, является stateful.
Кроме того, порядок, в котором, представляются сертификаты, обработанные реализацией поставщика услуг (передал) к PKIXCertPathChecker, очень важно, особенно если реализация является stateful. В зависимости от алгоритма, используемого поставщиком услуг, сертификаты могут быть представлены в реверсе или прямом порядке. Обратное упорядочивание означает, что сертификаты упорядочиваются от пользующегося наибольшим доверием CA (если есть) к целевому предмету, тогда как предварительная заявка означает, что сертификаты упорядочиваются от целевого предмета до пользующегося наибольшим доверием CA. Порядок должен быть сообщен реализации PKIXCertPathChecker, так, чтобы это знало, как обработать последовательные сертификаты.
Метод init инициализирует внутреннее состояние средства проверки:
public abstract void init(boolean forward)
Все stateful реализации должны очистить или инициализировать любое внутреннее состояние в средстве проверки. Это препятствует тому, чтобы реализация поставщика услуг вызвала средство проверки, которое находится в неинициализированном состоянии. Это также позволяет stateful средствам проверки быть снова использованными в последующих операциях, не повторно инстанцируя их. Параметр forward указывает на порядок сертификатов, представленных PKIXCertPathChecker. Если forward является true, сертификаты представляются от цели, чтобы доверять привязке; если false, от доверяет привязку, чтобы предназначаться.
Метод isForwardCheckingSupported возвращает boolean, который указывает, поддерживает ли PKIXCertPathChecker вперед проверку:
public abstract boolean isForwardCheckingSupported()
Все реализации PKIXCertPathChecker mustsupport обратная проверка. Реализация PKIXCertPathChecker maysupport вперед проверяющий.
Поддержка прямой проверки улучшает эффективность CertPathBuilders, которые создают вперед, так как это позволяет путям быть проверенными, поскольку они создаются. Однако, некоторый stateful PKIXCertPathCheckers может счесть это трудным или невозможным поддерживать вперед проверку.
Метод getSupportedExtensions возвращает неизменный Set OID String s для расширений X.509, которые поддерживает реализация PKIXCertPathChecker (то есть, распознает, в состоянии обработать):
public abstract Set<String> getSupportedExtensions()
Метод должен возвратить null, если никакие расширения не обрабатываются. Все реализации должны возвратить Set OID String s, который может обработать метод check.
A CertPathBuilder может использовать эту информацию, чтобы идентифицировать сертификаты с нераспознанными критическими расширениями, даже когда выполнение прямого создает с a PKIXCertPathChecker это не поддерживает вперед проверку.
Следующий метод выполняет проверку на сертификате:
public abstract void
check(Certificate cert, Collection<String> unresolvedCritExts)
throws CertPathValidatorException
Параметр unresolvedCritExts содержит набор OID как String s. Эти OID представляют набор критических расширений в сертификате, которые еще не были разрешены алгоритмом проверки допустимости пути сертификации. Конкретные реализации метода check должны удалить любые критические расширения, которые он обрабатывает от параметра unresolvedCritExts.
Если сертификат не передает проверку (ки), CertPathValidatorException должен быть брошен.
PKIXCertPathChecker class реализует интерфейс Cloneable. Все stateful реализации PKIXCertPathChecker должны переопределить метод clone в случае необходимости. Реализация по умолчанию вызовов метода clone метод Object.clone, который выполняет простого клона, копируя все поля исходного объекта к новому объекту. Реализация не сохраняющая состояние не должна переопределить метод clone. Однако, все stateful реализации должны гарантировать, что метод clone значения по умолчанию корректен, и переопределите его в случае необходимости. Например, PKIXCertPathChecker, который хранит состояние в массиве, должен переопределить метод clone, чтобы сделать копию массива, а не только ссылку на массив.
Причина, что объектами PKIXCertPathChecker является Cloneable, состоит в том, чтобы позволить реализации CertPathBuilder PKIX эффективно отслеживать в обратном порядке и пробовать другой путь, когда потенциальный путь сертификации достигает тупика или точки отказа. В этом случае реализация в состоянии восстановить предшествующие состояния проверки допустимости пути, восстанавливая клонированные объекты.
Это - пример реализации PKIXCertPathChecker не сохраняющей состояние. Это проверяет, существует ли частное расширение в сертификате и обрабатывает его согласно небольшому количеству правил.
import java.security.cert.Certificate;
import java.security.cert.X509Certificate;
import java.util.Collection;
import java.util.Collections;
import java.util.Set;
import java.security.cert.PKIXCertPathChecker;
import java.security.cert.CertPathValidatorException;
public class MyChecker extends PKIXCertPathChecker {
private static Set supportedExtensions =
Collections.singleton("2.16.840.1.113730.1.1");
/*
* Initialize checker
*/
public void init(boolean forward)
throws CertPathValidatorException {
// nothing to initialize
}
public Set getSupportedExtensions() {
return supportedExtensions;
}
public boolean isForwardCheckingSupported() {
return true;
}
/*
* Check certificate for presence of Netscape's
* private extension
* with OID "2.16.840.1.113730.1.1"
*/
public void check(Certificate cert,
Collection unresolvedCritExts)
throws CertPathValidatorException
{
X509Certificate xcert = (X509Certificate) cert;
byte[] ext =
xcert.getExtensionValue("2.16.840.1.113730.1.1");
if (ext == null)
return;
//
// process private extension according to some
// rules - if check fails, throw a
// CertPathValidatorException ...
// {insert code here}
// remove extension from collection of unresolved
// extensions (if it exists)
if (unresolvedCritExts != null)
unresolvedCritExts.remove("2.16.840.1.113730.1.1");
}
}
Каждый объект PKIXCertPathChecker должен быть инициализирован реализацией поставщика услуг прежде, чем начать алгоритм создавания или проверки допустимости, например:
List<PKIXCertPathChecker> checkers = params.getCertPathCheckers();
for (PKIXCertPathChecker checker : checkers) {
checker.init(false);
}
Для каждого сертификата, которого это проверяет, реализация поставщика услуг должна вызвать метод check каждого объекта PKIXCertPathChecker поочередно, передавая это сертификат и любые остающиеся неразрешенные критические расширения:
for (PKIXCertPathChecker checker : checkers) {
checker.check(cert, unresolvedCritExts);
}
Если какой-либо check s бросает CertPathValidatorException, a CertPathValidator реализация должна завершить процедуру проверки допустимости. Однако, реализация CertPathBuilder может просто зарегистрировать отказ и продолжать искать другие потенциальные пути. Если весь check s успешен, реализация поставщика услуг должна проверить, что все критические расширения были разрешены и в противном случае полагают, что проверка допустимости перестала работать. Например:
if (unresolvedCritExts != null &&
!unresolvedCritExts.isEmpty())
{
// note that a CertPathBuilder may have an enclosing
// try block to catch the exception below and continue on error
throw new CertPathValidatorException
("Unrecognized Critical Extension");
}
Как обсуждено в предыдущем разделе, реализация CertPathBuilder, возможно, должна отследить в обратном порядке, когда потенциальный путь сертификации достигает тупика или точки отказа. Отслеживание в обратном порядке в этом контексте подразумевает возврат предыдущему сертификату в пути и проверке другие потенциальные пути. Если реализация CertPathBuilder проверит пути, поскольку это создает это, то это должно будет восстановить предыдущее состояние каждого PKIXCertPathChecker. Это может сделать это, делая клонов объектов PKIXCertPathChecker прежде, чем каждый сертификат будет обработан, например:
/* clone checkers */
List newList = new ArrayList(checkers);
ListIterator li = newList.listIterator();
while (li.hasNext()) {
PKIXCertPathChecker checker = (PKIXCertPathChecker) li.next();
li.set(checker.clone());
}
Используя a PKIXCertPathChecker настроить проверку допустимости пути сертификата относительно straightfoward.
Во-первых, рассмотрите код, который проверяет пути сертификата:
Set<TrustAnchor> trustAnchors = getTrustAnchors();
CertPath cp = getCertPath();
PKIXParameters pkixp = new PKIXParameters(trustAnchors);
pkixp.setRevocationEnabled(false);
CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
PKIXCertPathValidatorResult pcpvr =
(PKIXCertPathValidatorResult)cpv.validate(cp, pkixp);
Если проверка допустимости перестала работать, validate() метод выдает исключение.
Фундаментальные шаги следующие:
PKIXParameters с доверительными привязками.CertPathValidator проверить пути сертификата.В этом примере, getTrustAnchors() и getCertPath() методы, которые получают корневые сертификаты CA и путь сертификации.
getTrustAnchors() метод в примере должен возвратить a Set из TrustAnchors, которые представляют корневые сертификаты CA, которые Вы хотите использовать для проверки допустимости. Вот одна простая реализация, которая загружает единственный корневой сертификат CA из файла:
public Set<TrustAnchor> getTrustAnchors()
throws IOException, CertificateException {
InputStream in = new FileInputStream("x509_ca-certificate.cer");
CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate c = (X509Certificate)cf.generateCertificate(in);
in.close();
TrustAnchor anchor = new TrustAnchor(c, null);
return Collections.singleton(anchor);
}
Точно так же вот простая реализация getCertPath() это загружает путь сертификата из файла:
public CertPath getCertPath() throws IOException, CertificateException {
CertificateFactory cf = CertificateFactory.getInstance("X.509");
InputStream in = new FileInputStream("certpath.pkcs7");
CertPath cp = cf.generateCertPath(in, "PKCS7");
in.close();
return cp;
}
Отметьте, что PKCS#7 не требует определенного порядка на сертификаты в файле, таким образом, этот код только работает на проверку допустимости пути сертификации, когда сертификаты упорядочиваются, начиная с объекта проверяться и прогрессируя назад к корню CA. Если сертификаты не находятся в правильном порядке, Вы должны сделать некоторую дополнительную обработку. CertificateFactory имеет a generateCertPath() метод, который принимает a Collection, который полезен для этого типа обработки.
PKIXCertPathCheckerЧтобы настроить проверку допустимости пути сертификации, добавьте a PKIXCertPathChecker следующим образом. В этом примере, SimpleChecker a PKIXCertPathChecker подкласс. Новые строки показывают полужирным.
Set<TrustAnchor> trustAnchors = getTrustAnchors();
CertPath cp = getCertPath();
PKIXParameters pkixp = new PKIXParameters(trustAnchors);
pkixp.setRevocationEnabled(false);
SimpleChecker sc = new SimpleChecker();
pkixp.addCertPathChecker(sc);
CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
PKIXCertPathValidatorResult pcpvr =
(PKIXCertPathValidatorResult)cpv.validate(cp, pkixp);
SimpleChecker элементарный подкласс PKIXCertPathChecker. check() метод вызывают для каждого сертификата в пути сертификации, который проверяется. SimpleChecker использование AlgorithmConstraints реализация, чтобы исследовать алгоритм подписи и открытый ключ каждого сертификата.
import java.security.AlgorithmConstraints;
import java.security.CryptoPrimitive;
import java.security.Key;
import java.security.cert.*;
import java.util.*;
public class SimpleChecker extends PKIXCertPathChecker {
private final static Set<CryptoPrimitive> SIGNATURE_PRIMITIVE_SET =
EnumSet.of(CryptoPrimitive.SIGNATURE);
public void init(boolean forward) throws CertPathValidatorException {}
public boolean isForwardCheckingSupported() { return true; }
public Set<String> getSupportedExtensions() { return null; }
public void check(Certificate cert,
Collection<String> unresolvedCritExts)
throws CertPathValidatorException {
X509Certificate c = (X509Certificate)cert;
String sa = c.getSigAlgName();
Key key = c.getPublicKey();
AlgorithmConstraints constraints = new SimpleConstraints();
if (constraints.permits(SIGNATURE_PRIMITIVE_SET, sa, null) == false)
throw new CertPathValidatorException("Forbidden algorithm: " + sa);
if (constraints.permits(SIGNATURE_PRIMITIVE_SET, key) == false)
throw new CertPathValidatorException("Forbidden key: " + key);
}
}
Наконец, SimpleConstraints довольно серьезное AlgorithmConstraints реализация, которая позволяет только алгоритмы RSA и требует, чтобы ключи составили 2048 битов или больше.
import java.security.AlgorithmConstraints;
import java.security.AlgorithmParameters;
import java.security.CryptoPrimitive;
import java.security.Key;
import java.security.interfaces.RSAKey;
import java.util.Set;
public class SimpleConstraints implements AlgorithmConstraints {
public boolean permits(Set<CryptoPrimitive> primitives,
String algorithm, AlgorithmParameters parameters) {
return permits(primitives, algorithm, null, parameters);
}
public boolean permits(Set<CryptoPrimitive> primitives, Key key) {
return permits(primitives, null, key, null);
}
public boolean permits(Set<CryptoPrimitive> primitives,
String algorithm, Key key, AlgorithmParameters parameters) {
if (algorithm == null) algorithm = key.getAlgorithm();
if (algorithm.indexOf("RSA") == -1) return false;
if (key != null) {
RSAKey rsaKey = (RSAKey)key;
int size = rsaKey.getModulus().bitLength();
if (size < 2048) return false;
}
return true;
}
}
Этот раздел предназначается для опытных программистов, желающих создать их собственные пакеты провайдера, предоставляющие реализации службы пути сертификации. Этот раздел предполагает, что Вы считали документ: Как Реализовать Провайдера для Архитектуры Криптографии Java.
Следующие классы механизма определяются в API Пути Сертификации Java:
CertPathValidator - используемый, чтобы проверить путей сертификации
CertPathBuilder - используемый, чтобы создать пути сертификации
CertStore - используемый, чтобы получить сертификаты и CRL от репозитария
Кроме того, существование ранее CertificateFactory механизм class был улучшен в JDK, v 1.4, чтобы поддерживать генерацию путей сертификации.
Интерфейсы приложения, предоставленные механизмом class, реализуются с точки зрения "Интерфейса Поставщика услуг" (SPI). Имя каждого SPI class является тем же самым как тем из соответствующего механизма class, сопровождаемый "Spi". Например, SPI class, соответствующий механизму CertPathValidator class, является CertPathValidatorSpi class. Каждый SPI class абстрактен. Чтобы предоставить реализацию определенного типа службы, для определенного алгоритма или типа, провайдер должен разделить соответствующий SPI на подклассы class и обеспечить реализации для всех абстрактных методов. Например, CertStore class обеспечивает доступ к функциональности получения сертификатов и CRL от репозитария. Фактическая реализация, предоставленная в подклассе CertStoreSpi, состояла бы в том что для определенного типа репозитария сертификата, такого как LDAP.
Разработчики должны следовать за необходимыми шагами, перечисленными в, Как Реализовать Провайдера для документа Архитектуры Криптографии Java. Вот немного дополнительных правил следовать для определенных шагов:
Шаг 3: Запишите свой "Мастер класс", подкласс Провайдера
Они - свойства, которые должны быть определены для служб пути сертификации, где именем алгоритма заменяют algName, и тип certstore для storeType:
CertPathValidator.algName
CertPathBuilder.algName
CertStore.storeType
См. Приложение A для стандартных имен, которые определяются для algName и storeType. Значение каждого свойства должно быть полностью определенным именем class, реализовывая указанный алгоритм, или тип certstore. Таким образом, это должно быть имя пакета, сопровождаемое именем class, где эти два разделяются периодом. Например, провайдер устанавливает CertPathValidator.PKIX свойство, чтобы иметь значение "sun.security.provider.certpath.PKIXCertPathValidator" следующим образом:
put("CertPathValidator.PKIX", "sun.security.provider.certpath.PKIXCertPathValidator")
Кроме того, атрибуты службы могут быть определены для служб пути сертификации. Эти атрибуты могут использоваться в качестве фильтров для того, чтобы выбрать поставщиков услуг. См. Приложение A для определения некоторых стандартных атрибутов службы. Например, провайдер может установить ValidationAlgorithm атрибут службы к имени RFC или спецификации, которая определяет алгоритм проверки допустимости PKIX:
put("CertPathValidator.PKIX ValidationAlgorithm", "RFC3280");
Шаг 8: Задокументируйте своего Провайдера и его Поддерживаемые Службы
Поставщики услуг пути сертификации должны задокументировать следующую информацию для каждого SPI:
Фабрики сертификата
Провайдер должен задокументировать, какие типы путей сертификации (и номера версий сертификатов в пути, если релевантный) могут быть созданы фабрикой. Провайдер должен описать упорядочивание сертификатов в пути сертификации, так же как содержание.
Провайдер должен задокументировать список поддерживаемых форматов кодирования. Это не технически необходимо, так как клиент может запросить их, вызывая метод getCertPathEncodings. Однако, документация должна описать каждый формат кодирования более подробно и ссылку любые стандарты когда применимый.
Блоки проверки допустимости Пути сертификации
Провайдер должен задокументировать любую релевантную информацию относительно реализации CertPathValidator, включая типы путей сертификации, которых это проверяет. В частности реализация CertPathValidator PKIX должна задокументировать следующую информацию:
Разработчики Пути сертификации
Провайдер должен задокументировать любую релевантную информацию относительно реализации CertPathBuilder, включая типы путей сертификации, которые это создает и проверяются ли они. В особенности реализация CertPathBuilder PKIX должна задокументировать следующую информацию:
Все реализации CertPathBuilder должны оказать дополнительную поддержку отладки, чтобы проанализировать и исправить потенциальные проблемы создания пути. Должны быть задокументированы детали о том, как получить доступ к этой отладочной информации.
Хранилища сертификата/CRL
Провайдер должен задокументировать, какие типы сертификатов и CRL (и номера версий, если релевантный) получаются CertStore.
Провайдер должен также задокументировать любую релевантную информацию относительно реализации CertStore (такой как используемые протоколы или поддерживаемые форматы). Например, реализация CertStore LDAP должна описать, какие версии LDAP поддерживаются и какие стандартные атрибуты используются для того, чтобы найти сертификаты и CRL. Это должно также задокументировать, если результаты кэшей реализации, и как долго (то есть, при каких условиях они обновленный).
Если реализация возвращает сертификаты и CRL в определенном порядке, она должна описать алгоритм сортировки. Реализация должна также задокументировать любого дополнительного или параметры инициализации значения по умолчанию.
Наконец, реализация должна задокументировать, если и как она использует информацию в CertSelector, или CRLSelector возражает, чтобы найти сертификаты и CRL.
Вот некоторые общие типы взаимозависимостей алгоритма в реализациях службы пути сертификации:
Проверка допустимости Пути сертификации и Алгоритмы Подписи
Реализация CertPathValidator часто требует, чтобы использование алгоритма подписи проверило цифровую подпись каждого сертификата. Метод setSigProvider PKIXParameters class позволяет пользователю определять определенного провайдера Signature.
Разработчики Пути сертификации и Фабрики Сертификата
Реализация CertPathBuilder будет часто использовать CertificateFactory, чтобы генерировать путь сертификации от списка сертификатов.
CertStores и Фабрики Сертификата
Реализация CertStore будет часто использовать CertificateFactory, чтобы генерировать сертификаты и CRL от их кодировок. Например, реализация CertStore LDAP может использовать CertificateFactory X.509, чтобы генерировать сертификаты X.509 и CRL от их ASN.1 закодированная форма.
API Пути Сертификации содержит два интерфейса, представляющие прозрачные спецификации параметров, CertPathParameters и интерфейсов CertStoreParameters.
Две реализации интерфейса CertPathParameters включаются, PKIXParameters и классы PKIXBuilderParameters. Если Вы работаете с проверкой допустимости пути сертификации PKIX и параметрами алгоритма, можно использовать эти классы. Если Вы будете нуждаться в параметрах для различного алгоритма, то Вы должны будете предоставить свою собственную реализацию CertPathParameters для того алгоритма.
Две реализации интерфейса CertStoreParameters включаются, LDAPCertStoreParameters и классы CollectionCertStoreParameters. Эти классы должны использоваться с LDAP и Набором реализации CertStore, соответственно. Если Вы будете нуждаться в параметрах для различного типа репозитария, то Вы должны будете предоставить свою собственную реализацию CertStoreParameters для того типа.
CertPathParameters и CertStoreParameters интерфейсы каждый определяет a clone метод, который должны переопределить реализации. Типичная реализация выполнит "глубокую" копию объекта, так, что последующие изменения к копии не будут влиять на оригинал (и наоборот). Однако, это не абсолютное требование для реализаций CertStoreParameters. Мелкая реализация копии clone является более подходящим для приложений, которые должны содержать ссылку на параметр, содержавшийся в CertStoreParameters. Например, с тех пор CertStore.getInstance делает клона указанного CertStoreParamters, мелкая копия clone позволяет приложению содержать ссылку на и позже высвобождать средства детали CertStore параметр инициализации, вместо того, чтобы ожидать механизма сборки "мусора". Это должно быть сделано с предельной заботой, начиная с CertStore май все еще использоваться другими потоками.
API Пути Сертификации содержит два интерфейса, представляющие прозрачные спецификации результатов, CertPathValidatorResult и интерфейсов CertPathBuilderResult.
Одна реализация для каждого из интерфейсов включается: PKIXCertPathValidatorResult и классы PKIXCertPathBuilderResult. Если Вы реализуете поставщиков услуг пути сертификации PKIX, можно использовать эти классы. Если Вы будете нуждаться в результатах пути сертификации для различного алгоритма, то Вы должны будете предоставить свой собственный CertPathValidatorResult или реализацию CertPathBuilderResult для того алгоритма.
Реализация PKIX CertPathValidator или CertPathBuilder может счесть полезным сохранить дополнительную информацию в PKIXCertPathValidatorResult или PKIXCertPathBuilderResult, таком как отладка трассировок. В этих случаях реализация должна реализовать подкласс соответствующего результата class с методами, чтобы получить релевантную информацию. Эти классы должны быть поставлены с классами провайдера, например, как часть файла JAR провайдера.
CertStoreException подклассы GeneralSecurityException.Как ранее упомянуто, PKIX CertPathValidator или CertPathBuilder не обязан поддерживать nameConstraints параметр TrustAnchor class. Реализации должны бросить InvalidAlgorithmParameterException если этот параметр не поддерживается.
Этот раздел описывает улучшения, которые были добавлены, чтобы поддерживать метки времени подписи.
До Java SE 5.0, подпись, сгенерированная jarsigner содержавший никакая информация о w курице подпись была сгенерирована. Без другой доступной информации, systems/deployers (включая пользователей Плагина Java) часто базировал их оценку законности подписанного файла JAR на законности сертификата подписания. Когда сертификат подписания истекает, systems/deployers приходят к заключению, что подпись, и следовательно, файл JAR, истекла. Поскольку сертификаты подписания обычно истекают ежегодно, это вызвало клиентов существенные проблемы, вынуждая их оставить развернутые файлы JAR ежегодно.
Запуск в Java SE 5.0, jarsigner может генерировать подписи, которые включают метку времени, таким образом включая systems/deployer (включая Плагин Java), чтобы проверить, был ли файл JAR подписан, в то время как сертификат подписания был все еще допустим. Кроме того, API были добавлены в Java SE 5.0, чтобы позволить приложениям получать информацию о метке времени.
В следующий раз улучшения и дополнения поддерживаются:
jarsigner инструмент может теперь генерировать и сохранить метку времени подписи, подписывая файл JAR. Кроме того, jarsigner поддерживает альтернативные механизмы подписания. Это поведение является дополнительным и управляется пользователем во время подписания через опции, описанные ниже.
Следующий jarsigner опции поддерживают метки времени подписи:
-tsa url
Если "-tsa http://example.tsa.url" появляется на командной строке, подписывая файл JAR тогда, метка времени сгенерирована для подписи. URL, http://example.tsa.url, идентифицирует расположение Властей Добавления метки времени (TSA). Это переопределяет любой URL, найденный через -tsacert опция. -tsa опция не требует, чтобы сертификат TSA с открытым ключом присутствовал в keystore.
Генерировать метку времени, jarsigner связывается с TSA, используя Протокол Метки времени (TSP), определенный в . В случае успеха маркер метки времени, возвращенный TSA, сохранен наряду с подписью в файле сигнатурного блока.
-tsacert alias
Если "-tsacert alias" появляется на командной строке, подписывая файл JAR тогда, метка времени сгенерирована для подписи. alias идентифицирует сертификат TSA с открытым ключом в keystore, который является в настоящий момент в действительности. Сертификат записи исследуется на Подчиненное информационное расширение Доступа, которое содержит URL, идентифицирующий расположение TSA.
Сертификат TSA с открытым ключом должен присутствовать в keystore при использовании -tsacert.
-altsigner class
Определяет, что используется альтернативный механизм подписания. Полностью определенное имя class идентифицирует файл class, который расширяется com.sun.jarsigner.ContentSigner abstract class. Путь к этому файлу class определяется -altsignerpath опция. Если -altsigner опция используется, jarsigner использует механизм подписания, обеспеченный указанным class. Иначе, jarsigner использует его механизм подписания значения по умолчанию.
Например, чтобы использовать механизм подписания, обеспеченный названным class com.sun.sun.jarsigner.AuthSigner, используйте jarsigner опция "-altsigner com.sun.jarsigner.AuthSigner"
-altsignerpath classpathlist
Определяет путь к файлу class (имя файла class определяется с -altsigner опция, описанная выше), и любые файлы JAR это зависит от. Если файл class находится в файле JAR, то это определяет путь к тому файлу JAR, как показано в примере ниже.
Абсолютный путь или путь относительно текущего каталога могут быть определены. Если classpathlist содержит разнообразные пути или файлы JAR, они должны быть разделены двоеточием (:) на Солярисе и точке с запятой (;) на Windows. Эта опция не необходима, если class уже находится в пути поиска.
Пример определения пути к файлу фляги, который содержит файл class:
-altsignerpath /home/user/lib/authsigner.jar
Отметьте, что имя файла JAR включается.
Пример определения пути к файлу фляги, который содержит файл class:
-altsignerpath /home/user/classes/com/sun/tools/jarsigner/
Отметьте, что имя файла JAR опускается.
В Java SE 5.0, Плагин Java был улучшен, чтобы проверить метки времени подписи (при наличии), проверяя файлов JAR. Плагин Java больше не будет представлять диалоговое окно, когда он встретится с или отменяемым сертификатом с истекшим сроком, проверяя подписанной фляги, при условии, что метка времени подписи подтверждает, что подпись была сгенерирована до даты аннулирования или истечения.
Сертификат TSA должен быть доступным от keystore Плагина или хранилищ сертификата, когда Плагин проверяет файла JAR, содержащего метку времени подписи.
Плагин возвращается к 1.4.x поведение, если подпись не содержит метку времени.
Безопасность и API JAR были улучшены, чтобы позволить приложениям получить доступ к информации о метке времени.
Два новых класса были добавлены к пакету java.security. Этими классами является , который поддерживает информацию, связанную с подписывающим лицом, и , которая представляет информацию, связанную с меткой времени подписи.
Новые методы были добавлены к class и class, чтобы предоставить доступ к этой новой, дополнительной информации.
API Пути Сертификации Java требует и использует ряд стандартных имен для алгоритмов проверки допустимости пути сертификации, кодировок и типов хранения сертификата. Стандартные имена, ранее найденные здесь в Приложении A и в других спецификациях безопасности (JCA/JSSE/etc). были объединены в документе Стандартных имен. Определенная информация о провайдере может быть найдена в Документации Провайдера солнца.
Пожалуйста, отметьте, что поставщик услуг может хотеть определять новое имя для собственного или нестандартного алгоритма, который не упоминается в документе Стандартных имен. Однако, чтобы предотвратить коллизии имени, рекомендуется, чтобы имя было снабжено префиксом обратное имя Интернет-домена организации провайдера (например: com.sun.MyCertPathValidator).
Провайдер "SUN" поддерживает следующие стандартные алгоритмы, типы и кодировки:
CertificateFactory: X.509
CertPath введите с кодировками PkiPath и PKCS7CertPathValidator: Алгоритм PKIXCertPathBuilder: Алгоритм PKIXCertStore: LDAP и Набор CertStore типыCertificateFactory механизм class был улучшен, чтобы поддерживать генерацию X.509 CertPath объекты. PKCS7 и кодировки PkiPath поддерживаются. PKCS#7 реализация поддерживает подмножество (только SignedData, тип ContentInfo поддерживается). Сертификаты в CertPath упорядочиваются в прямом направлении (от цели доверять привязке). Каждый сертификат в CertPath имеет тип java.security.cert.X509Certificate, и версии 1, 2 и 3 поддерживаются.
Провайдер "SUN" предоставляет реализацию PKIX CertPathValidator механизм class. Реализация проверяет CertPaths типа X.509 и реализаций алгоритм проверки допустимости пути сертификации определил в . Эта реализация устанавливает ValidationAlgorithm атрибут службы к "RFC3280".
В Java SE 7 выпусков слабые криптографические алгоритмы могут быть отключены в провайдере "SUN", используя свойство безопасности. jdk.certpath.disabledAlgorithms свойство является списком отключенных алгоритмов, который применяется к проверке пути сертификата. Значение по умолчанию jdk.certpath.disabledAlgorithms MD2. Это означает, что никакой алгоритм подписи, включающий MD2, не будет использоваться, чтобы проверить сертификат. У приложения D есть примеры значений для jdk.certpath.disabledAlgorithms.
У Профиля Сертификата и CRL PKIX есть много дополнительных функций. Провайдер "SUN" реализует поддержку отображения политики, доступа информации о полномочиях и расширений сертификата точки распределения CRL, расширения CRL точки распределения издания, и причины код и расширения записи CRL выпускающего сертификата. Это не реализует поддержку самого нового CRL или подвергает информационные расширения сертификата доступа. Это также не включает поддержку самого нового CRL и расширений CRL Индикатора CRL дельты и недействительной даты и содержит расширения записи CRL системы команд.
Реализация поддерживает механизм проверки аннулирования CRL, который приспосабливает разделу 6.3 из Сертификата PKIX и Профиля CRL. OCSP также в настоящий момент поддерживается как созданный в механизме проверки аннулирования. См. Приложение C для большего количества деталей о реализации и конфигурации и как это работает в соединении с CRL.
Реализация не поддерживает nameConstraints параметр TrustAnchor class и validate метод бросает InvalidAlgorithmParameterException если это определяется.
CertPathBuilder механизм class. Реализация создает CertPaths типа X.509. Каждый CertPath проверяется согласно алгоритму PKIX, определенному в . Эта реализация устанавливает ValidationAlgorithm атрибут службы к "RFC3280".
Реализация требует что targetConstraints параметр a PKIXBuilderParameters объект является экземпляром X509CertSelector и подчиненный критерий устанавливается в ненулевое значение. Иначе build метод бросает InvalidAlgorithmParameterException.
Реализация создает CertPath объекты в прямом направлении, используя алгоритм в глубину. Это отслеживает в обратном порядке к предыдущим состояниям и пробует альтернативные пути, когда потенциальный путь решается быть недопустимым или превышает PKIXBuilderParameters
maxPathLength параметр.
Проверка допустимости пути выполняется тем же самым способом как CertPathValidator реализация. Реализация проверяет большей части пути, поскольку это создается, чтобы устранить недопустимые пути ранее в процессе. Проверки проверки допустимости, которые не могут быть выполнены на сертификатах, упорядоченных в прямом направлении, задерживаются и выполняются на пути после того, как он был создан (но прежде, чем он будет возвращен к приложению).
Как с CertPathValidator, jdk.certpath.disabledAlgorithms свойство безопасности может использоваться, чтобы исключить криптографические алгоритмы, которые не считают безопасными.
Когда два или больше потенциальных сертификата обнаруживаются, который может привести к обнаружению пути, который встречает указанные ограничения, реализация использует следующие критерии, чтобы расположить по приоритетам сертификаты (в примерах ниже, чтобы принять a TrustAnchor отличительное имя "ou=D, ou=C, o=B, c=A" определяется):
TrustAnchors (исключая: issuerDN = "ou=D, ou=C, o=B, c=A").TrustAnchors, упорядоченный близостью к привязке (исключая: issuerDN = "ou=E, ou=D, ou=C, o=B, c=A").TrustAnchors, упорядоченный близостью к привязке (исключая: issuerDN = "ou=C, o=B, c=A".TrustAnchors, упорядоченный близостью к привязке (исключая: issuerDN = "ou=G, ou=C, o=B, c=A").Эта реализация была протестирована с LDAP и Набором CertStore реализации включаются в этот выпуск провайдера "SUN".
Отладка поддержки может быть включена, устанавливая java.security.debug свойство к certpath. Например:
java -Djava.security.debug=certpath BuildCertPath
Это напечатает дополнительную отладочную информацию к стандартной ошибке.
CertStore механизм class: Набор и LDAP.
CertStore реализация может содержать любые объекты, которые являются экземпляром java.security.cert.Certificate или java.security.cert.CRL.
Сертификаты и CRL не возвращаются ни в каком определенном порядке и не будут содержать копии.
CertStore реализация получает сертификаты и CRL из каталога LDAP, используя схему LDAP, определенную в . Атрибут службы LDAPSchema устанавливается в "RFC2587".
Реализация выбирает сертификаты от различных расположений, в зависимости от значений предмета, выпускающего, и basicConstraints критериев отбора, определенных в X509CertSelector. Это выполняет так многие из следующих операций насколько возможно:
Ищет сертификаты в атрибуте "userCertificate" подчиненного DN.
Ищет сертификаты в прямом элементе атрибута "crossCertificatePair" подчиненного DN И в атрибуте "caCertificate" предмета.
Ищет сертификаты в обратном элементе атрибута "crossCertificatePair" DN's выпускающего И в атрибуте "caCertificate" DN's выпускающего.
В каждом случае сертификаты проверяются, используя X509CertSelector.match() прежде, чем добавить их к получающемуся набору.
Если ни одно из условий, определенных выше, не применяется, то исключение выдается, чтобы указать, что было невозможно выбрать сертификаты, используя предоставленные критерии. Отметьте, что, даже если один или больше условий применяются, возвращенный Набор может все еще быть пустым, если нет никаких сертификатов в каталоге.
Реализация выбирает CRL от выпускающего DNs, определенный в setCertificateChecking, addIssuerName или setIssuerNames методы X509CRLSelector class. Если никакой выпускающий, DNs были определены, используя один из этих методов, реализация, не выдает исключение, указывающее на это, было невозможно выбрать CRL, используя предоставленные критерии. Иначе, CRL ищутся следующим образом:
Реализация сначала создает список имен выпускающего. Если сертификат был определен в setCertificateChecking метод, это использует выпускающего того сертификата. Иначе, это использует определенное использование имен выпускающего addIssuerName или setIssuerNames методы.
Затем, реализация выполняет итерации через список имен выпускающего. Для каждого имени выпускающего это ищет сначала в атрибуте "authorityRevocationList" выпускающего и затем, если никакой CRL соответствия не был найден там в атрибуте "certificateRevocationList" выпускающего. Одно исключение к вышеупомянутому - это, если имя выпускающего было получено из сертификата, определенного в setCertificateChecking метод, это только проверяет атрибут "authorityRevocationList" выпускающего, если указанный сертификат является сертификатом CA.
Все CRL проверяются, используя X509CRLSelector.match() прежде, чем добавить их к получающемуся набору.
Если никакие CRL, удовлетворяющие критерии отбора, не могут быть найдены, пустой Набор возвращается.
sun.security.certpath.ldap.cache.lifetime к значению в секундах. Значение 0 отключает кэш полностью. Значение -1 означает неограниченное время жизни.
com.sun.security.enableCRLDP к значению true.
Если установлено в истину, реализация Sun PKIX использует информацию в расширении Точек Распределения CRL сертификата (в дополнение к CertStores, которые определяются), чтобы найти CRL, если точка распределения является отличительным именем X.500 или URI типа ldap, http, или протоколом передачи файлов.
com.sun.security.enableAIAcaIssuers к значению true.
Если установлено в истину, реализацию Sun PKIX CertPathBuilder использует информацию в расширении сертификата AIA (в дополнение к CertStores, которые определяются), чтобы найти сертификат CA издания, если это - URI типа ldap, http, или протокол передачи файлов.
Клиентская поддержка Онлайнового Протокола Состояния Сертификата (OCSP) как определено в поддерживается с JDK 5.0. Проверкой OCSP управляют следующие пять свойств безопасности:
| Имя свойства | Описание |
|---|---|
| ocsp.enable | Значение этого свойства является любой истиной или ложью. Если это правда, проверка OCSP включается, делая проверку аннулирования сертификата; если ложь или не набор, проверка OCSP отключается. |
| ocsp.responderURL | Значением этого свойства является URL, который идентифицирует расположение респондента OCSP. Вот пример. ocsp.responderURL=http://ocsp.example.net:80 По умолчанию расположение респондента OCSP определяется неявно от проверяемого сертификата. Свойство используется, когда расширение Доступа информации о Властях (определенный в RFC 3280) отсутствует в сертификате или когда это требует переопределения. |
| ocsp.responderCertSubjectName | Значение этого свойства является подчиненным именем сертификата респондента OCSP. Вот пример. ocsp.responderCertSubjectName="CN=OCSP Responder, O=XYZ Corp" По умолчанию сертификат о респонденте OCSP является сертификатом выпускающего проверяемого сертификата. Это свойство идентифицирует сертификат о респонденте OCSP, когда значение по умолчанию не применяется. Его значение является строковым отличительным именем (определенный в RFC 2253), который идентифицирует сертификат в наборе сертификатов, предоставленных во время проверки допустимости пути свидетельства. В случаях, где одно только подчиненное имя не достаточно, чтобы однозначно определить сертификат, тогда оба, свойства ocsp.responderCertIssuerName И ocsp.responderCertSerialNumber должны использоваться вместо этого. То, когда th является свойством, устанавливается, тогда те два свойства игнорируются. |
| ocsp.responderCertIssuerName | Значение этого свойства является именем выпускающего сертификата респондента OCSP. Вот пример. ocsp.responderCertIssuerName="CN=Enterprise CA, O=XYZ Corp" По умолчанию сертификат о респонденте OCSP является сертификатом выпускающего проверяемого сертификата. Это свойство идентифицирует сертификат о респонденте OCSP, когда значение по умолчанию не применяется. Его значение является строковым отличительным именем (определенный в RFC 2253), который идентифицирует сертификат в наборе сертификатов, предоставленных во время проверки допустимости пути свидетельства. Когда это свойство устанавливается тогда, свойство ocsp.responderCertSerialNumber должно также быть установлено. Отметьте, что это свойство игнорируется, когда свойство ocsp.responderCertSubjectName было установлено. |
| ocsp.responderCertSerialNumber | Значение этого свойства является порядковым номером сертификата респондента OCSP, Вот пример. ocsp.responderCertSerialNumber=2A:FF:00 По умолчанию сертификат о респонденте OCSP является сертификатом выпускающего проверяемого сертификата. Это свойство идентифицирует сертификат о респонденте OCSP, когда значение по умолчанию не применяется. Его значение является строкой шестнадцатеричных цифр (двоеточие, или разделители пространства могут присутствовать), который идентифицирует сертификат в наборе сертификатов, предоставленных во время проверки допустимости пути свидетельства. Когда это свойство устанавливается тогда, свойство ocsp.responderCertIssuerName должно также быть установлено. Отметьте, что это свойство игнорируется, когда свойство ocsp.responderCertSubjectName было установлено. |
Эти свойства могут быть установлены или статично в файле $JAVA_HOME/jre/lib/security/java.security Среды выполнения Java, или динамически использовании метода java.security.Security.setProperty().
По умолчанию проверка OCSP не включается. Это включается, устанавливая свойство ocsp.enable в "true". Использование остающихся свойств является дополнительным. Отметьте, что, включая OCSP проверка только имеет эффект, если проверка аннулирования была также включена. Проверка аннулирования включается через метод PKIXParameters.setRevocationEnabled() .
OCSP проверяющие работы в соединении со Списками аннулированных сертификатов (CRL) во время проверки аннулирования. Ниже сводка взаимодействия OCSP и CRL. Failover к CRL происходит, только если с проблемой OCSP встречаются. Failover не происходит, если респондент OCSP подтверждает или что сертификат был отменен или что это не было отменено.
| PKIXParameters RevocationEnabled (default=true) | ocsp.enable (default=false) | Поведение |
|---|---|---|
| истина | истина | Проверка аннулирования, используя OCSP, failover к использованию CRL |
| истина | ложь | Проверка аннулирования, используя CRL только |
| ложь | истина | Никакая проверка аннулирования |
| ложь | ложь | Никакая проверка аннулирования |
jdk.certpath.disabledAlgorithms свойство безопасности содержит список криптографических алгоритмов, которые не будут использоваться во время обработки пути сертификации. Точный синтаксис свойства описывается в jre/lib/security/java.security файл, но кратко получается в итоге здесь.
Свойство безопасности содержит список криптографических алгоритмов, которые не должны использоваться. Имена алгоритма разделяются запятыми. Кроме того можно также определить ограничения на размеры ключа.
Например, следующая строка в java.security определяет, что MD2 и алгоритмы DSA не должны использоваться для обработки пути сертификации. Кроме того RSA отключается для размеров ключа меньше чем 2048 битов.
jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
