certificate – EJBCA отказывается генерировать сертификаты с ошибкой: не разрешено использовать тот же ключ –

На чтение 24 мин. Опубликовано
Содержание
  1. Что происходит на практике
  2. Ca / форум браузера
  3. Certificate – ejbca отказывается генерировать сертификаты с ошибкой: не разрешено использовать тот же ключ –
  4. Etsi eidas
  5. Google, apple и godaddy отзовут более 1 млн сертификатов из-за ошибки
  6. Pkcs # 11 hsm
  7. Tlsv1.3
  8. Выпускаем собственные сертификаты
  9. Высокая производительность и емкость
  10. Вышел ejbca 3.11
  11. Двусторонний tls
  12. Дизайн
  13. Криптографические примитивы
  14. Множество протоколов интеграции и api
  15. Несколько алгоритмов
  16. Несколько экземпляров цс
  17. Общие критерии
  18. Поддержка приложений и оборудования
  19. Протокол статуса онлайн-сертификата
  20. Протоколы и стандарты
  21. Различные форматы сертификатов
  22. Система pki (три) – установка ejbca – русские блоги
  23. Функции
  24. Хранилище общей безопасности
  25. Итоги

Что происходит на практике

  1. Client Hello – клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.

    Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA – Риверт-Шамир-Адлеман, DH – Диффи-Хеллмана, ECDH – Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES – Advanced Encryption Standard, 3DES – Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 – Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).

    Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.

  2. Server Hello – сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.

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

  3. Certificate – сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.

    Что представляет из себя сертификат? Сертификат – это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.

    Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, – вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.

    Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA – Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом – это цепочка подписания.

    Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).

  4. Server Key Exchange – этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Ys=gслучайно выбранное сервером числоmod p, где mod – это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Yc=gслучайно выбранное клиентом числоmod p. После этого сервер считает Ycслучайно выбранное сервером числоmod p, а клиент Ysслучайно выбранное клиентом числоmod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:

  5. Server Hello Done – сервер сообщает, что начальный этап установки соединения завершен

  6. Client Key Exchange – как было уже сказано выше, когда сервер передал числа p, g, Ys в Server Key Echange, клиент передает свое число Yc в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret – предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.

  7. Change Cipher Spec – клиент говорит серверу, что он готов перейти на защищенное соединение.

  8. Finished – клиент зашифровывает симметричным ключом первое сообщение с MAC.

  9. Change Cipher Spec – сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.

  10. Finished – аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение

  11. После этого соединение считается установленным, и происходит передача полезной информации

  12. close_notify – служебное сообщение, которое одна сторона отправляет другой, как уведомление о том, что считаетсоединение разорванным и не будет принимать больше сообщения. Другая сторона в ответ обязана послать аналогичное сообщение close_notify.

Ca / форум браузера

EJBCA может выдавать сертификаты сервера TLS, соответствующие основным требованиям CA / Browser Forum  (in) , а также сертификаты EV (Extended Validation или Certificate Extended Validation  (in) ) в соответствии с рекомендациями EV CA / Browser Forum, и, таким образом, позволяет соответствующие центры сертификации соблюдают «  корневую программу  » веб-браузеров.

Certificate – ejbca отказывается генерировать сертификаты с ошибкой: не разрешено использовать тот же ключ –

Мы использовали статическое значение usernameTest в качестве имени пользователя, чтобы запросить EJBCA для создания сертификатов X.509; после создания сертификатов с использованием этого satic-имени пользователя мы изменили его на уникальное значение, однозначно идентифицирующее каждый сертификат (поскольку использование статического имени пользователя считается обновлением, поскольку имя пользователя одинаково для всех сертификатов (*)), но теперь EJBCA отказывается генерировать сертификаты и все еще ссылка на старое статическое имя пользователя usernameTest; мы получаем эту ошибку:

Про сертификаты:  Термостатический клапан Данфосс RA-N RTR-N, Danfoss купить в Москве, наличие, низкие цены, оперативная доставка

Пользователю “250320092916” не разрешено использовать тот же ключ, что и пользователю (-ам) usernameTest.

Мы отозвали все сертификаты, ранее созданные для имени пользователя usernameTest, но мы по-прежнему получаем это сообщение об ошибке от EJBCA. Есть ли способ удалить имя пользователя usernameTest?

У каждого сертификата есть уникальное имя субъекта и имя пользователя.

Версия EJBCA – ejbca-6.2.0 .

(*): Все сертификаты, созданные в графическом интерфейсе администрирования EJBCA, связаны с одним и тем же именем пользователя.

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

Лучший ответ

Проблема решена ; проблема не в том, что ссылка на usernameTest все еще находится в EJBCA , а в том, что тот же ключ (открытый ключ RSA) используется для запроса другого пользователя (‘250320092916’).

Кажется, это известное ограничение при использовании симулятора HSM PTK-C из серии Safenet ProtectServer; симулятор перезапускает свой случайный генератор, когда мы повторно инициализируем его (я подозреваю, что я злоупотребляю), что означает, что он всегда будет генерировать одни и те же ключи в том же порядке (что приводит к таким ошибкам).

Но также ошибка сообщения не ясна; если говорить о «ключе» без указания, это приводит к путанице с subjectDN или другими атрибутами, передаваемыми в EJBCA, поскольку в качестве сообщения об ошибке это может быть «открытый ключ» или «ключ RSA», … вместо ключа;)

Etsi eidas

Характеристики издания «Бизнес» в EJBCA позволяют – путем установки – иметь органы , которые могут быть квалифицированы как Европейское соответствие eIDAS ( E lectronic Id entification имеет й доверие S ervices) на ETSI (Европейский институт стандартов), то есть в соответствии с стандарту ETSI EN 319 411-2.

Google, apple и godaddy отзовут более 1 млн сертификатов из-за ошибки

Причиной проблемы стала некорректная настройка компаниями центра сертификации EJBCA.

GoDaddy, Apple и Google ошибочно выпустили более 1 миллиона цифровых сертификатов с серийными номерами, содержащими 63 бита вместо 64 бит, как того требуют нормы CA/Browser Forum для выпуска сертификатов. Теперь компании вынуждены отозвать не соответствующие стандартам отрасли сертификаты. В настоящее время неясно, какое число удостоверяющих центров (УЦ) коснулась проблема, поэтому не исключено, что количество некорректных сертификатов может быть значительно больше.

Причиной проблемы стала некорректная настройка компаниями центра сертификации EJBCA (Enterprise Java Beans Certificate Authority), используемого многими удостоверяющими центрами для генерирования сертификатов. По умолчанию EJBCA генерирует сертификаты с серийными номерами, содержащими 64 бита в соответствии с базовыми требованиями, указанными в руководстве CA/Browser Forum «Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates» («Базовые требования для выдачи и управления доверенными сертификатами»). Однако из-за ошибки генерировались сертификаты с серийными номерами в 63 бита, что является нарушением отраслевых стандартов.

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

По словам представителей GoDaddy, компания выпустила около 300 тыс. некорректных сертификатов, в Apple назвали цифру 878 тыс. сертификатов (из них 558 тыс. все еще действительны), а в Google сообщили, что с 2021 года техногигант выпустил более 100 тыс. сертификатов, но на данный момент только 7,1 тыс. остаются действительными. В настоящее время Apple и Google находятся в процессе отзыва сертификатов, по словам представителей GoDaddy, компания отзовет все сертификаты в течение следующих 30 дней.

мы рассказываем о главных новостях из мира IT, актуальных угрозах и событиях, которые оказывают влияние на

, бизнес глобальных корпораций и безопасность пользователей по всему миру. Узнай первым как

Pkcs # 11 hsm

Используя стандартный PKCS 11 API вы можете использовать большинство HSM, совместимых с PKCS # 11, для защиты закрытых ключей центров сертификации и OCSP.

Tlsv1.3

Стоит отметить, что все выше написанное относится к TLSv1.2, которая начинает понемногу устаревать. В 2021 году была разработана новая версия 1.3 в которой: были запрещены уже ненадежные алгоритмы, ускорен процесс соединения, переработан протокол рукопожатия и др.

Выпускаем собственные сертификаты

Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем “password” длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:

openssl genrsa -aes256 -passout pass:password -out CA-private-key.key 4096

Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:

Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте “CN=Certificate authority” (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password – все поля, кроме CN опциональны), приватный ключ и пароль от него:

openssl req -new -key CA-private-key.key -passin pass:password -subj "/CN=Certificate authority/" -out CA-certificate-signing-request.csr t $3

Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.

openssl x509 -req -in CA-certificate-signing-request.csr -signkey CA-private-key.key -passin pass:password -days 1 -out CA-self-signed-certificate.pempemE

Теперь у нас есть сертификат, которому в будущем будут доверять наши клиент и сервер. Похожим образом сделаем приватные ключи и запросы на подпись сертификата для них:

openssl genrsa -aes256 -passout pass:password -out Server-private-key.key 4096
openssl req -new -key Server-private-key.key -passin pass:password -subj "/CN=localhost/" -out Server-certificate-signing-request.csrt $3

openssl genrsa -aes256 -passout pass:password -out Client-private-key.key 4096
openssl req -new -key Client-private-key.key -passin pass:password -subj "/CN=Client/" -out Client-certificate-signing-request.csr

Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.

openssl x509 -req -in Server-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -CAcreateserial -days 1 -out Server-certificate.pemt $4
openssl x509 -req -in Client-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -days 1 -out Client-certificate.pem

После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем “password”:

openssl pkcs12 -export -in Server-certificate.pem -inkey Server-private-key.key -passin pass:password -passout pass:password -out Server-keystore.p12

Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:

keytool -import -file CA-self-signed-certificate.pem -keystore Server-truststore.p12 -storetype PKCS12 -storepass password -noprompt

Для удобства, все описанные выше действия упакованы в bash script.

Про сертификаты:  Ресурс работы оборудования

Высокая производительность и емкость

Вы можете создать PKI, способную выдавать миллиарды сертификатов со скоростью несколько сотен в секунду.

Вышел ejbca 3.11

29-го ноября, как и ожидалось, вышел EJBCA 3.11

EJBCA — это OpenSource ПО для создания Certification Authority уровня предприятия. Отличается полной реализацией функционала CA и поддерживает крупные СУБД. С точки зрения пользователя, EJBCA предоставляет два вида интерфейса для управления жизненным циклом сертификатов: консольный и развитый веб-интерфейс. Также в EJBCA реализованы протоколы OCSP и SCEP, позволяющие в том числе взаимодействовать с интеллектуальным сетевым и криптографическим оборудованием.

EJBCA Написан на языке Java, имеет собственный документированный API, запускается на большинстве широко распространёных серверов приложений (JBoss, Glassfish, Weblogic, OC4J). К сожалению, в этом списке не нашлось места для IBM WebSphere.

Стабильный релиз 3.11 — переходный, его основным назначением является максимальное асимптотическое приближение к тестовой кодовой базе с целью дальнейшей стабилизации последней и выпуска 4-й версии.

Тем не менее, в 3.11 есть и некоторые интересные изменения:

  • отныне можно вовсе не использовать хранилища сертификатов и аккаунтов пользователей, благодаря чему можно работать вообще без привязки к каким-либо источникам данных;
  • сервис протокола OCSP стал универсальным средством проверки доверия сертификатам, предоставляя своим клиентам по запросу кроме собственно возможностей OCSP также «традиционные» CRL-списки и сертификат(ы) CA;
  • обновлена схема базы данных с целью обеспечения совместимости со всеми поддерживаемыми реализациями СУБД;
  • улучшена поддержка Glassfish, в результате чего стало возможным запускать EJBCA под Glassfish с поддержкой СУБД Oracle;
  • веб-интерфейс дополнен полезной возможностью указывать множество дополнительных информативных атрибутов при изменении настроек пользователей;
  • появился Guide по супер-быстрой установке EJBCA 3.11 на Ubuntu 10.04 LTS (в пику гораздо более длинному стандартному QuickStart Guide’у).

В данном релизе, как и всегда, к вашим услугам:

  • очень простая пошаговая документация со множеством примеров;
  • широкий круг поддерживаемых платформ;
  • отличная поддержка стандартов (например, очень приятно, что полноценно поддерживается LDAP);
  • активное сообщество пользователей.

>>> Сайт программы

Двусторонний tls

Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.

Дизайн

Система реализована в Java EE и разработан, чтобы быть независимая платформа и полностью группируемый,[1] чтобы обеспечить большую степень масштабируемости, чем это типично для аналогичных программных пакетов.

Несколько экземпляров EJBCA запускаются одновременно, совместно используя базу данных, содержащую текущие центры сертификации (CA). Это позволяет каждому экземпляру программного обеспечения получить доступ к любому ЦС. Программное обеспечение также поддерживает использование аппаратный модуль безопасности (HSM), что обеспечивает дополнительную безопасность.

EJBCA поддерживает множество распространенных архитектур PKI[2] например, все на одном сервере, распределенные RA и внешние орган проверки. Пример архитектуры показан ниже.

Криптографические примитивы

  • ECC  : более 50 кривых, кривые NIST (P-224, P-256, P-384, P-521), кривые Brainpool, французская кривая FRP256v1, кривые Curve25519 и Curve448  (en) (начиная с EJBCA 7.4 .0)
  • RSA  : 1024, 1536, 2048, 3072, 4096, 6144, 8192 бит
  • DSA  : 1024 бит

Множество протоколов интеграции и api

EJBCA был разработан с учетом интеграции. Поддерживаются большинство стандартных протоколов, CMP, SCEP, стандартное восточное время, и ACME а также веб-сервисы. Используя интеграционные API, можно интегрировать EJBCA как фабрику сертификатов, не открывая его собственные пользовательские интерфейсы.

Несколько алгоритмов

Вы можете использовать все обычные и некоторые необычные алгоритмы в своей PKI. ЮАР, ECDSA, EdDSA, и DSA, SHA-1, SHA-2, и SHA-3. Совместимый с NSA Suite B Криптография.

Несколько экземпляров цс

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

Общие критерии

EJBCA v7.4 был сертифицирован в соответствии с Общими критериями (ref.: CSEC2021005) на16 апреля 2021 г.в соответствии с «  Certification Authorities  » совместный профиль защиты (PP4CA).

EJBCA v5.0 был сертифицирован в соответствии с Общими критериями (ref.: ANSSI-CC-2021/47) на4 октября 2021 г.в соответствии с профилем защиты «  Выдача сертификатов и компоненты управления  » (PP-CIMC: компоненты управления и выдача сертификатов), уровень EAL 4 .

Библиотека CESeCore – сердце безопасности EJBCA – была сертифицирована как соответствующая Общим критериям (ссылка: ANSSI-CC-2021/33) на14 июня 2021 г., уровень EAL 4 .

Поддержка приложений и оборудования

  • Серверы приложений: WildFly (версия сообщества), JBoss EAP (с поддержкой Red Hat )
  • Операционные системы: GNU / Linux , Unix, FreeBSD, Solaris, Windows
  • Базы данных: PostgreSQL , MariaDB , MySQL , Oracle , DB2, MS-SQL, Hypersoniq, Derby, Sybase, Informix, Ingres
  • Каталоги LDAP  : OpenLDAP , Active Directory , LDAPv3, Sun Directory Server
  • Модули HSM  : nCipher netHSM, nCipher nShield, SafeNet Luna SA, SafeNet Luna PCI, SafeNet ProtectServer, Bull TrustWay Proteccio, Bull TrustWay CryptoBox, Bull TrustWay PCI Crypto Card, Utimaco R2, Utimaco SafeGuard CryptoServer, CptoSavroServer3 CoSign, AEP Keyper
  • HSM в облаке  : AWS CloudHSM, Azure Key Vault
  • Карты / токены HSM  : SmartCard-HSM, Nitrokey HSM, YubiHSM 2, OpenSC (общий)
  • Программные инструменты PKCS11  (in)  : OpenSC  (in) , SoftHSM  (in) , PKCS11 Spy Unbound Key Control (UKC)
  • Высокая доступность и контроль

Протокол статуса онлайн-сертификата

Для проверки сертификата у вас есть выбор использовать X.509 CRL и OCSP (RFC6960).

Протоколы и стандарты

  • Сертификаты X.509 v3 и список отзыва сертификатов (CRL) v2 ( RFC  5280)
  • Сертификаты CVC ( Card Verifiable Certificate ) для электронных паспортов ( ИКАО , Doc 9303 – Машиносчитываемые проездные документы  (en) (MRTD))
  • Квалифицированные сертификаты (ETSI eIDAS и RFC  3739)
  • OCSP ( протокол статуса онлайн-сертификата, протокол проверки, RFC  6960)
  • CMP ( протокол управления сертификатами  ( входящий ) , протокол управления сертификатами, RFC  4210)
  • EST ( регистрация через безопасный транспорт  (en) , протокол регистрации сертификатов, RFC  7030)
  • SCEP ( простой протокол регистрации сертификатов , проект IETF )
  • ACME ( среда автоматического управления сертификатами, протокол регистрации сертификатов сервера (например, Let’s Encrypt ), RFC  8555)
  • PKCS ( стандарты шифрования с открытым ключом ): PKCS # 1, PKCS # 7, PKCS # 9, PKCS # 10 , PKCS # 11, PKCS # 12
  • Журналы CT ( прозрачность сертификата  (en) , протокол публикации сертификата сервера TLS , RFC  6962)
  • CAA ( авторизация центра сертификации DNS , тип записи ресурса DNS для авторизации центров сертификации , RFC  6844)
  • CMS ( Синтаксис криптографических сообщений  (en) , RFC  5652)
  • CRMF ( формат сообщения запроса сертификата  (en) , RFC  4211)
  • LDAP v3 ( облегченный протокол доступа к каталогам , RFC  4511)
  • Протокол 3GPP ( например, LTE / 4G) для мобильных устройств через CMP (протокол управления сертификатами)
  • PSD2 (пересмотренная Директива о платежных услугах ), полное соответствие с Директивой о платежных услугах 2 (DSP 2)
Про сертификаты:  Экспедиторские документы FIATA (складская расписка FWR, экспедиторская расписка FCR, экспедиторский сертификат перевозки FCT)

Различные форматы сертификатов

EJBCA поддерживает оба X.509v3 сертификата и сертификаты, проверяемые картой (CVC BSI TR-03110). Сертификаты соответствуют всем стандартам, таким как RFC5280, CA / Форум браузеров, eIDAS, ИКАО 9303, EAC 2.10 и ISO 18013, поправка 2 eDL.

Система pki (три) – установка ejbca – русские блоги

EJBCA – это полнофункциональное системное программное обеспечение CA, основанное на технологии J2EE и обеспечивающее мощный, высокопроизводительный CA на основе компонентов. EJBCA сочетает в себе гибкость и независимость от платформы, может использоваться независимо, а также может быть интегрирован с любым приложением J2EE.

  • Особенности: Лицензия LGPL с открытым исходным кодом;

  • Построен на спецификации J2EE 1.3 (EJB2.0);

  • Гибкая компонентная архитектура;

  • Многоуровневый ЦС

  • Несколько центров сертификации и многоуровневые центры сертификации, создают одну или несколько полных инфраструктур в экземпляре EJBCA для независимой работы или интегрируют ее в любое приложение J2EE;

  • Простая установка и настройка

  • Мощный веб-интерфейс управления и надежный алгоритм идентификации.

  • Поддержка управления на основе командной строки, поддержка скриптов и других функций

  • Поддержка подачи заявки на получение личного сертификата или массового производства сертификатов

  • Сертификаты сервера и клиента можно экспортировать в формате PKCS12, JKS или PEM.

  • Поддержка прямого применения сертификатов с использованием таких браузеров, как Netscape, Mozilla, IE и т. Д.

  • Поддержка использования открытых API-интерфейсов и инструментов для подачи заявок на сертификаты через другие приложения.

  • Новым пользователям, добавленным RA, можно напоминать по электронной почте

  • Для проверки нового пользователя пароль может быть сгенерирован случайным образом или вручную.

  • Поддержка аппаратных модулей для интеграции систем выпуска оборудования (например, смарт-карт)

  • Поддержка SCEP

  • Поддержка многополярного управления с определенными правами пользователей и группами пользователей

  • Конфигурация сертификата может выполняться для разных типов и содержания сертификатов.

  • Конфигурация сущности может выполняться для разных типов пользователей.

  • Следуйте стандартам X509 и PKIX (RFC3280)

  • Поддержка CRL

  • Полная поддержка OCSP, включая расширение AIA

  • Создание списков отзыва сертификатов и точки распространения списков отзыва сертификатов на основе URL соответствуют RFC3280, а сертификаты и списки отзыва сертификатов могут храниться в любой базе данных SQL (обрабатываемой сервером приложений).

  • Необязательные несколько эмитентов для выдачи сертификатов и списков отзыва сертификатов в LDAP

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

  • Компонентная архитектура для выдачи сертификатов и списков отзыва сертификатов разным адресатам

  • Компонентная архитектура, используемая для использования нескольких методов авторизации объектов при выдаче сертификатов

  • Легко интегрируется в большие приложения и оптимизирован для интеграции в бизнес-процессы

  • EJBCA полностью написан на Java и может работать на любой платформе, использующей сервер J2EE. Разработка и тестирование ведутся на Linux и Windows.

  • Сменить пользователяsu - ca

  • Распаковать Wildflyunzip /opt/ca/Wildfly-12.0.0.Final.zip

  • Измените файл конфигурации запущенного Wildfly

    1. vim wildfly-12.0.0.Final/bin/standalone.conf
    2. 53 строки найдены
    3. Закомментируйте новую строку#JAVA_OPTS="-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true"
    4. Добавьте строку под линиейJAVA_OPTS="-Xms2048m -Xmx2048m -Djava.net.preferIPv4Stack=true"
    5. Сохранить, выйти

  • Запустить Wildfly./wildfly-12.0.0.Final/bin/standalone.sh

  • Настроить Wildfly

    1. Запустить клиента./wildfly-12.0.0.Final/bin/jboss-cli.sh -c. Ввод считается успешным, если появляются следующие символы[[email protected]:9990 /]

    2. Настроить источник данных

      module add --name=com.mysql --resources=/opt/ca/mysql-connector-java-5.1.46.jar --dependencies=javax.api,javax.transaction.api

/subsystem=datasources/jdbc-driver=mysql:add(driver-name="mysql",driver-module-name="com.mysql",driver-xa-datasource-class-name=com.mysql.jdbc.Driver)

data-source add --name=ejbcads --driver-name="mysql" --connection-url="jdbc:mysql://127.0.0.1:3306/ejbcatest" --jndi-name="java:/EjbcaDS" --use-ccm=true --driver-class="com.mysql.jdbc.Driver" --user-name="username" --password="password" --validate-on-match=true --background-validation=false --prepared-statements-cache-size=50 --share-prepared-statements=true --min-pool-size=5 --max-pool-size=150 --pool-prefill=true --transaction-isolation=TRANSACTION_READ_COMMITTED --check-valid-connection-sql="select 1;"

      Вышеупомянутые команды и последующие команды конфигурации необходимо выполнять одну за другой. Обратите внимание на замену--connection-url="jdbc:mysql://127.0.0.1:3306/ejbcatest"，--user-name="username"，--password="password"

    3. Настроить удаленный вызов Wildfly

      /subsystem=remoting/http-connector=http-remoting-connector:remove
/subsystem=remoting/http-connector=http-remoting-connector:add(connector-ref="remoting",security-realm="ApplicationRealm")
/socket-binding-group=standard-sockets/socket-binding=remoting:add(port="4447")
/subsystem=undertow/server=default-server/http-listener=remoting:add(socket-binding=remoting)
:reload

      Ввод завершен, нужно дождаться завершения перезагрузки Wildfly и команда доступна.:read-attribute(name=server-state)Приходите проверить. Если появляется следующее сообщение, перезагрузка прошла успешно.
      shell { "outcome" => "success", "result" => "running" }

    4. Настроить журнал Wildfly

      /subsystem=logging/logger=org.ejbca:add
/subsystem=logging/logger=org.ejbca:write-attribute(name=level, value=DEBUG)
/subsystem=logging/logger=org.cesecore:add
/subsystem=logging/logger=org.cesecore:write-attribute(name=level, value=DEBUG)

    5. Закройте jboos-cli

  • Настроить ejbca

    1. разархивировать файлы,unzip ejbca_ce_6_10_1_2.zip

    2. модифицироватьejbca.properties файл

      1. cp ejbca_ce_6_10_1_2/conf/ejbca.properties.sample ejbca_ce_6_10_1_2/conf/ejbca.properties
      2. vim ejbca_ce_6_10_1_2/conf/ejbca.properties
      3. Настраиватьappserver.home Значение (- это место установки сервера приложений, для нас это/opt/ca/wildfly-10.0.0.Final), Окончательные результатыappserver.home=/opt/ca/wildfly-12.0.0.Final

    3. модифицироватьweb.propertiesфайл

      1. cp ejbca_ce_6_10_1_2/conf/web.properties.sample ejbca_ce_6_10_1_2/conf/web.properties
      2. vim ejbca_ce_6_10_1_2/conf/web.properties
      3. Задайте пароль сертификата суперадминистратора ЦС, а также пароль сертификата серверного сертификата, сгенерированного для сервера приложений, и пароль доверенной истории ЦС и т. Д. Мы можем установить эти пароли по мере необходимости или сохранить конфигурация по умолчанию, на которую нужно обратить внимание. Это httpsserver.hostname, это должно соответствовать псевдониму позади, мой IP-адрес 147.128.105.149, затем мы установили его на 147.128.105.149 здесь.
      4. Окончательная модификация,httpsserver.hostname=127.0.0.1

    4. модифицироватьdatabase.properties

      1. cp ejbca_ce_6_10_1_2/conf/database.properties.sample ejbca_ce_6_10_1_2/conf/database.properties
      2. vim ejbca_ce_6_10_1_2/conf/database.properties
      3. Фактически, просто используйте источник данных wildfly. Положитьdatasource.jndi-name=EjbcaDSОтмените комментарий, но также укажите тип базы данныхdatabase.name=mysqlЭту заметку также следует выпустить. В противном случае произойдет ошибка установки, и будет выполнен сценарий установки таблицы библиотек базы данных h2.

    5. модифицироватьinstall.properties

      1. cp ejbca_ce_6_10_1_2/conf/install.properties.sample ejbca_ce_6_10_1_2/conf/install.properties
      2. vim ejbca_ce_6_10_1_2/conf/install.properties
      3. Задайте имя CA, метод шифрования и т. Д. Рекомендуется оставить значение по умолчанию.

  • развертывание пакета ejbca

    cd /opt/ejbca_ce_6_5.0.5/
ant clean deployear
ant runinstall
ant deploy-keystore

  • Чтобы удалить текущую конфигурацию HTTPS и TLS Wildfly, вам необходимо использовать./wildfly-12.0.0.Final/bin/jboss-cli.sh -c

    /subsystem=undertow/server=default-server/http-listener=default:remove
/subsystem=undertow/server=default-server/https-listener=https:remove
/socket-binding-group=standard-sockets/socket-binding=http:remove
/socket-binding-group=standard-sockets/socket-binding=https:remove

  • Настроить TLS

    1. Настроить доступный извне

      /interface=http:add(inet-address="0.0.0.0")
/interface=httpspub:add(inet-address="0.0.0.0")
/interface=httpspriv:add(inet-address="0.0.0.0")
/socket-binding-group=standard-sockets/socket-binding=http:add(port="8080",interface="http")
/socket-binding-group=standard-sockets/socket-binding=httpspriv:add(port="8443",interface="httpspriv")
/socket-binding-group=standard-sockets/socket-binding=httpspub:add(port="8442", interface="httpspub")
/subsystem=undertow/server=default-server/http-listener=http:add(socket-binding=http)
/subsystem=undertow/server=default-server/http-listener=http:write-attribute(name=redirect-socket, value="httpspriv")
:reload

    2. Настроить привязку порта

      /core-service=management/security-realm=SSLRealm:add()
/core-service=management/security-realm=SSLRealm/server-identity=ssl:add(keystore-path="${jboss.server.config.dir}/keystore/keystore.jks", keystore-password="serverpwd", alias="127.0.0.1")
/core-service=management/security-realm=SSLRealm/authentication=truststore:add(keystore-path="${jboss.server.config.dir}/keystore/truststore.jks", keystore-password="changeit")
:reload

      среди нихkeystore-password="serverpwd"соответствоватьweb.propertiesвнутриhttpsserver.password。alias="127.0.0.1"соответствоватьweb.propertiesвнутриhttpsserver.hostname

    3. Перезапустить wildfly:shutdown(restart=true), Дождитесь завершения перезагрузки

    4. Настроить tls

      /subsystem=undertow/server=default-server/https-listener=httpspriv:add(socket-binding=httpspriv, security-realm="SSLRealm", verify-client=REQUIRED)
/subsystem=undertow/server=default-server/https-listener=httpspriv:write-attribute(name=max-parameters, value="2048")
/subsystem=undertow/server=default-server/https-listener=httpspub:add(socket-binding=httpspub, security-realm="SSLRealm")
/subsystem=undertow/server=default-server/https-listener=httpspub:write-attribute(name=max-parameters, value="2048")
:reload

    5. Другие важные конфигурации, такие как коды конфигурации

      /system-property=org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH:add(value=true)
/system-property=org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH:add(value=true)
/system-property=org.apache.catalina.connector.URI_ENCODING:add(value="UTF-8")
/system-property=org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING:add(value=true)
/subsystem=webservices:write-attribute(name=wsdl-host, value=jbossws.undefined.host)
/subsystem=webservices:write-attribute(name=modify-wsdl-address, value=true)
:reload

    6. Перезапустить wildfly:shutdown(restart=true), Дождитесь завершения перезагрузки

  • доступhttp://127.0.0.1:8080/ejbcaаутентификация

  • Скачиваем сертификат администратора, меняем/opt/ca/ejbca_ce_6_10_1_2/p12Внизsuperadmin.p12Скопируйте на локальный и установите сертификат

  • доступhttps://127.0.0.1:8443/ejbcaаутентификация

    • Функции

    EJBCA предлагает следующие возможности:

    • Несколько центров сертификации (ЦС) и подчиненные уровни ЦС для каждого экземпляра
    • Поддержка всех архитектур PKI общая
    • Генерация сертификатов в централизованном и децентрализованном режиме
    • Создание индивидуального или пакетного сертификата
    • Администрирование с помощью веб-службы , веб- интерфейса или интерфейса командной строки (CLI)
    • Многоязычная поддержка: немецкий, английский, боснийский, китайский, французский, японский, португальский, шведский, чешский, украинский, вьетнамский и т. Д.
    • Управление профилями сертификатов
    • Управление профилями конечных объектов
    • Управление квалифицированными сертификатами и удостоверениями личности eID
    • Несколько уровней администраторов по ЦС и по функциям
    • Поддержка API HSM ( модуль безопасности оборудования, модуль безопасности оборудования)

    Хранилище общей безопасности

    Характеристики EJBCA позволяют – по конфигурации – иметь экземпляры, которые соответствуют Общему репозиторию безопасности (RGS v2) ANSSI (Национальное агентство безопасности информационных систем, администрация Франции).

    Итоги

    В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!

    certification authority Java keystore ssl TLS truststore криптографические алгоритмы криптография Сертификаты
    Оцените статью
    Мой сертификат
    Добавить комментарий

    © 2024 Мой сертификат