Проверка Сертификата X.509 с Java и Bouncycastle

С точки зрения программиста, для проверки сертификата X.509 требуется несколько вещей.

1. Набор «якорей доверия» — корневых сертификатов ЦС, на которые вы полагаетесь. Они должны быть защищены от подделки, чтобы злоумышленник не заменил сертификат ЦС своей собственной подделкой. Открытые ключи в этих сертификатах используются для проверки цифровых подписей на других сертификатах.
2. Коллекция промежуточных сертификатов. Приложение может хранить их коллекцию, но большинство протоколов, таких как SSL и S/MIME, использующих сертификаты, имеют стандартный способ предоставления дополнительных сертификатов. Хранение их не требует особого ухода; их целостность защищена подписью корневого ЦС.
3. Сведения об отзыве. Даже если сертификат был выдан центром сертификации, он мог быть отозван преждевременно, поскольку закрытый ключ был раскрыт или конечная сущность изменила свое удостоверение. (Например,человек меняет работу и сертификат с названием его старой компании в нем отзывается.) CPL или веб-сервис, такой как OCSP, можно использовать для получения обновления о состоянии сертификата.

При наличии этих входных данных можно использовать встроенную поддержку PKIX для построения и проверки пути к сертификату.

/* Givens. */
InputStream trustStoreInput = ...
char[] password = ...
List<X509Certificate> chain = ...
Collection<X509CRL> crls = ...

/* Construct a valid path. */
KeyStore anchors = KeyStore.getInstance(KeyStore.getDefaultType());
anchors.load(trustStoreInput, password);
X509CertSelector target = new X509CertSelector();
target.setCertificate(chain.get(0));
PKIXBuilderParameters params = new PKIXBuilderParameters(anchors, target);
CertStoreParameters intermediates = new CollectionCertStoreParameters(chain)
params.addCertStore(CertStore.getInstance("Collection", intermediates));
CertStoreParameters revoked = new CollectionCertStoreParameters(crls);
params.addCertStore(CertStore.getInstance("Collection", revoked));
CertPathBuilder builder = CertPathBuilder.getInstance("PKIX");
/* 
 * If build() returns successfully, the certificate is valid. More details 
 * about the valid path can be obtained through the PKIXBuilderResult.
 * If no valid path can be found, a CertPathBuilderException is thrown.
 */
PKIXBuilderResult r = (PKIXBuilderResult) builder.build(params);

Важно отметить, что если путь не может быть найден, вы не получите много информации о причине. Это может расстраивать, но это так по замыслу. В общем, есть много потенциальных путей. Если все они потерпят неудачу по разным причинам, как строитель пути решит, о чем сообщить в качестве причины?

Хорошо, идея CA заключается в следующем:

• CA - это люди, которым все доверяют. Для этого в вашем браузере / почтовом клиенте / даже на моем мобильном телефоне доступен выбор доверенных центров сертификации. В вашем случае ваш открытый корневой ключ (сертификат) должен быть в вашем приложении.
• Пользователи отправляют в ЦС запросы на сертификат в формате PEM с открытым ключом. Центры сертификации проводят некоторую (я намеренно оставляю эту двусмысленную) форму проверки конечного пользователя, такую ​​как взимание с них денег или, в случае сертификатов расширенной проверки (зеленые), проверки биографических данных.
• Если центр сертификации не считает, что запрос пользователя действителен, он каким-то образом сообщает об этом.
• Если они это делают, они подписывают открытый ключ и создают сертификат, содержащий эту информацию. Здесь вы обрабатываете cert-req и превращаете его в сертификат X.509.
• Другие пользователи сталкиваются с нашим фиктивным пользователем и хотят знать, могут ли они им доверять. Таким образом, они смотрят на сертификат и обнаруживают, что он подписан цифровой подписью того, кого они имеют в своем списке доверенных лиц.Итак, из того факта, что они доверяют корневому ЦС, и только корневой ЦС может подписывать (через свой закрытый ключ) открытый ключ этого пользователя, а ЦС доверяет пользователю, мы делаем вывод, что новый пользователь может доверять mr fictious.

На программном уровне это реализуется путем чтения сертификата X.509 и определения того, кем должен быть ЦС. Учитывая отпечаток этого CA, вы находите его в своей базе данных и проверяете подпись. Если он совпадает, у вас есть цепочка доверия.

Это работает, потому что, как я уже сказал, только центр сертификации может создать цифровую подпись, но любой может ее проверить. Это полная противоположность концепции шифрования. Что вы делаете, так это «шифруете с помощью закрытого ключа» данные, которые хотите подписать, и проверяете, что «расшифровка с помощью открытого ключа» соответствует имеющимся у вас данным.