Jks файл, чем открыть

Обновлено: 04.07.2024

Возможно, связь между микрослужбами в одном кластере на основе протокола защищенных сокетов (SSL) не требуется, но часто требуется, если вы хотите подключиться к удаленной веб-службе или брокеру сообщений. В тех случаях, когда вы предоставляете доступ к веб-службе или другим конечным точкам, вам также может потребоваться использовать собственное хранилище ключей в микрослужбе, развернутой в Red Hat OpenShift, чтобы внешние клиенты подключались только к определенному доверенному хранилищу.

В этой статье я покажу вам, как настроить хранилище ключей и хранилище доверенных сертификатов для микрослужбы на основе Java, созданной с помощью Spring Boot. Для разработки микросервиса я использовал библиотеки Apache Camel и CXF от Red Hat Fuse. Я использовал развертывание исходного кода (S2I) и тестировал примеры в Red Hat OpenShift 4.3.

О примерах приложений

Первый пример приложения — это веб-служба на основе REST, развернутая в OpenShift 4.3 и взаимодействующая через SSL. Второй пример приложения — это клиент, который подключается к удаленной защищенной веб-службе. Я разместил оба приложения и все файлы примеров для этой статьи на GitHub.

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


Мы рассмотрим процесс защиты и развертывания веб-службы на основе REST в OpenShift 4.3. Обратите внимание, что эти инструкции подходят как для нового проекта OpenShift, так и для существующего. Я буду использовать только что представленные примеры приложений.

Защитите и разверните веб-службу на основе REST

Чтобы защитить и развернуть веб-службу на основе REST в OpenShift 4.3, начните с создания хранилища ключей и хранилища доверенных сертификатов. Затем добавьте их в секрет вашего проекта ( rest-keystore ), как показано ниже:

Затем добавьте конфигурацию SSL в файл src/main/resources/application.properties (для получения дополнительной информации перейдите по ссылке конфигурации):

Примечание. Путь к хранилищу ключей — server.ssl.key-store . Позже мы изменим конфигурацию развертывания микросервиса Spring Boot, чтобы смонтировать том с этим хранилищем ключей.

Определить веб-службу

Далее в src/main/resources/endpoint.xml вы определите веб-службу JAX-RS на основе CXF. Обратите внимание на входящие и исходящие перехватчики, которые настроены для регистрации запросов и ответов.

Примечание. Операция, описанная в HelloServiceImpl.java, вызывается внешними клиентами.

Микрослужба в этом примере инициируется из SampleRestApplication. Обратите внимание на аннотации SpringBootApplication и ImportResource. Аннотация SpringBootApplication аналогична объявлению класса вместе с аннотациями @Configuration, @EnableAutoConfiguration и @ComponentScan. Аннотация ImportResource импортирует определение компонента из endpoint.xml ресурса.

Развернуть веб-службу

Выполните следующие действия в графическом интерфейсе OpenShift 4.3:

  1. Выберите проекцию "Разработчик".
  2. Выберите Добавить->Из каталога->Найти и найти CXF JAX-RS с помощью Spring, как показано на рис. 2. В этом случае мы используем S2I для развертывания как веб-службы, так и клиентских приложений в OpenShift.

Снимок экрана, показывающий перспективу разработчика -> Добавить -> Из каталога -> Поиск -> CXF JAX-RS с Spring.

Далее сделайте следующее:

  1. Выберите шаблон CXF JAX-RS с Spring и нажмите Создать экземпляр шаблона.
  2. Задайте URL-адрес репозитория Git и разветвите его.
  3. Обратите внимание на версию и имя службы. Остальные записи останутся прежними.
  4. Нажмите «Создать» внизу страницы, как показано на рис. 3.


  1. Подождите несколько минут, пока OpenShift создаст build-config , deploy-config и (наконец) модули.

Примечание. В некоторых случаях в OpenShift могут отсутствовать нужные вам шаблоны. См. документацию Red Hat Fuse, чтобы добавить или обновить шаблон до последней версии.

Смонтировать том с хранилищем ключей

Теперь вы смонтируете том с хранилищем ключей. Для этого добавьте две записи в файл deployment-config : volumeMounts и keystore.jks.

Добавление volumeMounts в файл deployment-config создает путь подключения.Как только это будет сделано, вы можете использовать свой секрет хранилища ключей rest, чтобы добавить запись keystore.jks в путь монтирования.

Два способа добавить хранилище ключей

Есть два способа добавить эти записи в файл deployment-config . Первый вариант — отредактировать файл конфигурации развертывания и добавить записи вручную, как показано на рис. 4.


Ваш второй вариант – добавить секрет хранилища ключей rest в рабочую нагрузку проекта, как показано на рис. 5.


Если вы выберете второй вариант, проверьте конфигурацию развертывания после сохранения своей работы. Вы найдете записи, показывающие, что хранилище ключей монтируется томом из секрета хранилища остальных ключей. Вам все равно придется отредактировать конфигурацию, чтобы она точно соответствовала volumeMounts и keystore.jks. Тем не менее, я предпочитаю использовать секрет, потому что это приводит к меньшему количеству опечаток и проблем с форматированием YAML.

Доступ к микросервису

После того, как вы завершите эти настройки, вы обнаружите, что у вас есть работающий и работоспособный модуль:

Чтобы получить доступ к этому микросервису из внешнего клиента, вам потребуется создать маршрут OpenShift с сквозным завершением:

Наконец, получите доступ к маршруту ssl-cxf-jaxrs , который является сквозным .

При этом вы настроили SSL для веб-службы, как показано в этих выходных данных:

Далее я кратко расскажу о клиентском приложении, которое вы можете настроить для подключения к приложению односторонней веб-службы SSL.

Клиент для безопасного веб-сервиса на основе REST

Моим примером клиентского приложения является микросервис Apache Camel на основе SSL ( camel-client-ssl ). Я развернул микрослужбу в OpenShift, используя тот же подход S2I, который только что продемонстрировал для веб-службы.

Для этого примера я также написал специальную версию веб-службы, которую можно запускать автономно на локальном ноутбуке или виртуальной машине (ВМ). Чтобы запустить пример, вам просто нужно убедиться, что ваш кластер OpenShift доступен с вашей виртуальной машины или ноутбука. При первом запуске приложения используйте mvn spring-boot:run из pom.xml .

Пример настройки

Я не буду описывать весь процесс настройки клиента для взаимодействия с вашим веб-сервисом. Я лишь укажу на несколько важных деталей.

Заключение


Доверенный сертификат содержит один сертификат. Записи доверенных сертификатов представлены в KeyStore Explorer следующим значком:

Доверенные сертификаты используются для формирования цепочек доверия во время таких операций, как импорт ответа ЦС.

Импортировать доверенный сертификат


  1. В меню "Инструменты" выберите "Импортировать доверенный сертификат". Либо нажмите кнопку панели инструментов «Импорт доверенного сертификата»:
  2. Появится диалоговое окно «Импорт доверенного сертификата».
  3. Выберите диск и папку, в которой хранится файл сертификата.
  4. Нажмите на нужный файл сертификата или введите имя файла в текстовое поле "Имя файла".
  5. Нажмите кнопку "Импорт".
  6. Если включена проверка доверия при импорте доверенных сертификатов и KeyStore Explorer не может установить доверительный путь от сертификата в файле до существующего самозаверяющего доверенного сертификата в вашем хранилище ключей или в сертификатах центра:
    1. Откроется диалоговое окно «Сведения о сертификате».
    2. После просмотра сведений закройте диалоговое окно, нажав кнопку ОК.
    3. Появится дополнительное диалоговое окно с вопросом, хотите ли вы принять сертификат.
    4. Нажмите кнопку «Да», если вы хотите доверять сертификату и импортировать его, и «Нет», если вы этого не хотите. Если вы ответите Нет, импорт будет прерван.

      5. Просмотреть доверенный сертификат

      1. Щелкните правой кнопкой мыши запись Trusted Certificate в таблице KeyStore Entries. Выберите подменю View Details во всплывающем меню и оттуда выберите Certificate Details. Либо дважды щелкните запись доверенного сертификата.
      2. Появится диалоговое окно «Сведения о сертификате». После просмотра сведений закройте диалоговое окно, нажав кнопку ОК.

      Просмотр открытого ключа доверенного сертификата

      1. Щелкните правой кнопкой мыши запись Trusted Certificate в таблице KeyStore Entries. Во всплывающем меню выберите подменю «Просмотр сведений», а затем выберите «Сведения об открытом ключе».
      2. Появится диалоговое окно «Сведения об открытом ключе». После просмотра сведений закройте диалоговое окно, нажав кнопку ОК.

      Экспорт доверенного сертификата

      Перетащите экспорт доверенного сертификата

      1. Выберите запись доверенного сертификата для перетаскивания, нажав и удерживая левую кнопку мыши над ней в таблице записей хранилища ключей.
      2. Используйте мышь, чтобы перетащить запись в нужное место для экспорта. Например: рабочий стол, папка или открытый текстовый документ.
      3. Отпустите левую кнопку мыши над местом экспорта.
      4. Запись будет экспортирована. Формат экспорта — X.509 PEM.

      Экспортировать открытый ключ доверенного сертификата как OpenSSL

      1. Щелкните правой кнопкой мыши запись Trusted Certificate в таблице KeyStore Entries. Выберите подменю «Экспорт» во всплывающем меню, а затем выберите «Экспорт открытого ключа».
      2. Отображается диалоговое окно «Экспорт открытого ключа как OpenSSL».
      3. Установите флажок PEM, если экспортируемый открытый ключ должен быть закодирован PEM.
      4. Используйте кнопку "Обзор", чтобы выбрать файл для экспорта.
      5. Нажмите кнопку «Экспорт», чтобы начать экспорт.

      Вырезать и вставить доверенный сертификат

      1. Нажмите на запись доверенного сертификата, чтобы выбрать его.
      2. В меню «Правка» выберите «Вырезать». Либо нажмите кнопку панели инструментов «Вырезать»:
      3. Выберите целевое хранилище ключей, нажав на его вкладку.
      4. В меню «Правка» выберите «Вставить». Либо нажмите кнопку на панели инструментов «Вставить»:
      5. Запись доверенного сертификата появится в целевой таблице KeyStore Entries.

        6. Примечание. KeyStore Explorer имеет внутренний буфер обмена для операций вырезания, копирования и вставки, который называется буфером. Поэтому записи KeyStore нельзя вырезать или копировать из KeyStore Explorer в другие приложения и наоборот.

        Скопируйте и вставьте доверенный сертификат

        1. Нажмите на запись доверенного сертификата, чтобы выбрать его.
        2. В меню «Правка» выберите «Копировать». Либо нажмите кнопку панели инструментов "Копировать":
        3. При копировании в другое хранилище ключей выберите его, щелкнув вкладку.
        4. В меню «Правка» выберите «Вставить». Либо нажмите кнопку на панели инструментов «Вставить»:
        5. Копия записи доверенного сертификата появится в целевой таблице KeyStore Entries.

          6. Примечание. KeyStore Explorer имеет внутренний буфер обмена для операций вырезания, копирования и вставки, который называется буфером. Поэтому записи KeyStore нельзя вырезать или копировать из KeyStore Explorer в другие приложения и наоборот.

          В других статьях описываются другие инструменты для создания сертификата, подписанного ЦС:

          • Администраторы Linux обычно используют OpenSSL.
          • Администраторы Windows обычно используют ключевой инструмент Java.

          Ваш локальный авторитетный сервер Code42 не является исключением. Сервер Code42, настроенный на использование подписанного сертификата, строгой проверки TLS и строгих заголовков безопасности, защищает связь сервера с браузерами, вашими приложениями Code42 и другими серверами.

          Сертификаты и файлы хранилища ключей Java

          Сервер Code42 принимает сертификаты, объединенные в файл Java KeyStore. Хранилище ключей содержит:

          • Сертификат, открытый и закрытый ключи для сервера Code42
          • Сертификат ЦС, подписавшего сертификат сервера Code42
          • Промежуточные сертификаты, устанавливающие цепочку доверия между ЦС и сертификатом сервера Code42

          Создайте хранилище ключей с помощью такой утилиты, как KeyStore Explorer, прежде чем применять его к серверу Code42 из консоли Code42.

          Создайте хранилище ключей на любом компьютере.
          Вы можете генерировать ключи и создавать хранилища ключей на любом защищенном компьютере, а затем импортировать результат в виде файла *.jks на ваш авторитетный сервер через консоль Code42. Вам больше не нужен доступ к хост-компьютеру авторитетного сервера.

          Прежде чем начать

          • Перед установкой SSL-сертификата создайте резервную копию базы данных сервера Code42 с помощью дампа базы данных, чтобы при необходимости можно было восстановить ее до предыдущего состояния. Чтобы создать дамп:
          1. Выберите «Настройки» > «Сервер».
          2. В меню действий выберите "Дамп базы данных".
          • Получите адрес ЦС, которому вы отправите запрос на получение подписанного сертификата, подтверждающего действительность вашего хранилища ключей.
          • Установите KeyStore Explorer, если он еще не установлен.
          • Если вы собираетесь импортировать сертификат с ключом шифрования, превышающим ограничения Java на импорт криптографических алгоритмов, сначала необходимо настроить корпоративный сервер для приема более длинных ключей шифрования.

          Соображения

          • Для многосерверных сред Code42 мы рекомендуем применить этот процесс ко всем серверам Code42.
          • Вы должны иметь роль администратора сервера или SYSADMIN, чтобы установить SSL-сертификат на свой сервер Code42.
          • В этой статье предполагается, что вы знакомы со следующим:
            • Основные принципы безопасности транспортного уровня (TLS)
            • Настройка SSL-сертификатов

            Утилита командной строки OpenSSL требуется, если вы используете Linux и хотите повторно использовать существующие ключевые материалы.

            Помощь в создании хранилища ключей
            Помощь в обработке запроса на подпись сертификата (CSR) или создании хранилища ключей не входит в обязанности Customer Champions. Чтобы получить помощь, обратитесь к своему менеджеру по работе с клиентами (CSM), чтобы привлечь команду профессиональных услуг.

            Терминология хранилища ключей

            • Сертификат. Электронный документ, используемый для подтверждения права собственности на открытый ключ.
              • Сертификат, подписанный ЦС. Центр сертификации (ЦС) подписывает сертификат электронным способом, чтобы подтвердить, что открытый ключ принадлежит владельцу, указанному в сертификате. Кто-то, получивший подписанный сертификат, может проверить, что подпись действительно принадлежит ЦС, и определить, не подделал ли кто-нибудь сертификат после того, как ЦС подписал его.
              • Цепочка сертификатов. Один подписанный сертификат подтверждает, что присоединенный открытый ключ принадлежит его владельцу. Второй подписанный сертификат подтверждает надежность первого подписавшего, третий подтверждает второго и так далее. Вершиной цепочки является самозаверяющий, но пользующийся большим доверием корневой сертификат.
              • Корневой сертификат: сертификат, которому доверяют, чтобы завершить цепочку сертификатов. Операционные системы и веб-браузеры обычно имеют встроенный набор доверенных корневых сертификатов. Когда ваш сервер отправляет цепочку сертификатов, и один из них соответствует одному из доверенных корневых сертификатов браузера, браузер доверяет вашему серверу. Когда браузер шифрует данные с помощью вашего открытого ключа, он гарантирует, что только ваш сервер сможет их прочитать.
              • Самозаверяющий сертификат: файл, содержащий открытый ключ и идентифицирующий владельца этого ключа и соответствующего закрытого ключа.

              Создать хранилище ключей

              Создание Java KeyStore — это первый шаг в настройке сервера Code42 для использования вашего собственного SSL-сертификата, подписанного ЦС. Если у вас есть существующий закрытый ключ и соответствующий сертификат X.509 (вместе именуемые ключевыми материалами), вы можете использовать их повторно. Вы также можете начать с нуля, создавая новые ключевые материалы по мере необходимости. Шаги различаются в зависимости от имеющихся у вас ключевых материалов:

              Существующие материалы должны включать альтернативное имя субъекта (SAN)
              Сертификаты и хранилища ключей, созданные в соответствии со старым стандартом, могут не иметь расширения альтернативного имени субъекта (SAN). Большинство браузеров теперь не доверяют таким сертификатам. Если ваши существующие сертификаты и хранилища ключей не имеют расширения SAN, начните с нового запроса на подпись сертификата.

              Вариант 1. Создайте хранилище ключей без существующих ключевых материалов

              Параметры Keypass и storepass
              Вы должны использовать один и тот же пароль для хранилища ключей и закрытого ключа. Вы можете использовать любую строку для этих параметров, но они оба должны иметь одинаковое значение.

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

              Шаг 1. Создайте хранилище ключей и пару ключей

              Пароль для ввода пары ключей
              Сохраните этот пароль и используйте его в качестве пароля для всего хранилища ключей на шаге 7 ниже.

              Шаг 2. Создайте и отправьте запрос на подпись сертификата

              Шаг 3. Импортируйте подписанные сертификаты в хранилище ключей

              1. Когда центр сертификации вернет ваш подписанный сертификат и ключ, поместите их в каталог, доступный для Keystore Explorer.
              2. В обозревателе хранилища ключей щелкните правой кнопкой мыши ту же запись пары ключей, которая использовалась для создания CSR, и выберите «Импортировать ответ ЦС» > «Из файла».
              3. Выберите подписанный сертификат в центре сертификации и нажмите «Импорт».
                Подписанный сертификат добавляется в запись пары ключей как сертификат уровня сервера.
              4. Чтобы проверить цепочку сертификатов, щелкните правой кнопкой мыши запись пары ключей и выберите "Просмотреть сведения" > "Сведения о цепочке сертификатов".
              5. Если вам нужно импортировать сертификаты промежуточного и корневого уровня, щелкните правой кнопкой мыши запись пары ключей и выберите «Редактировать цепочку сертификатов» > «Добавить сертификат», чтобы добавить сертификаты промежуточного и корневого уровня. См. раздел Добавление сертификатов в существующее хранилище ключей ниже.
              6. В строке меню выберите «Файл» > «Сохранить», чтобы сохранить импортированный сертификат в хранилище ключей.

              Ваш файл хранилища ключей готов и готов к импорту на сервер Code42.

              Вариант 2. Создайте хранилище ключей с существующими ключевыми материалами

              Если вы хотите использовать существующие ключевые материалы для создания хранилища ключей, вы можете сделать следующее:

              Добавить сертификаты в существующее хранилище ключей

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

              Повторное использование существующих ключевых материалов из другого приложения (Linux)

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

              Для выполнения следующих шагов требуется использование утилиты командной строки OpenSSL.

              Ваш файл хранилища ключей готов и готов к импорту на сервер Code42.

              Повторное использование существующих ключевых материалов из другого приложения (Windows)

              Выполните следующие действия, чтобы повторно использовать существующую комбинацию закрытый ключ/сертификат из другого приложения, если вы работаете в Windows. Ключевые материалы на платформах Windows обычно хранятся в файле хранилища ключей PKCS12. KeyStore Explorer может преобразовать файл хранилища ключей PKCS12 в файл JKS, выполнив следующие действия.

              Ваш файл хранилища ключей готов и готов к импорту на сервер Code42.

              Настройте сервер Code42 для использования хранилища ключей

              Вы можете создать подписанное хранилище ключей, содержащее SSL-сертификат, который можно использовать для безопасного доступа к консоли Code42. После создания хранилища ключей введите его на свой сервер Code42.

                .
              1. Перед установкой SSL-сертификата создайте резервную копию базы данных сервера Code42 с помощью дампа базы данных, чтобы при необходимости можно было восстановить ее до предыдущего состояния. Чтобы создать дамп:
                1. Выберите «Настройки» > «Сервер».
                2. В меню действий выберите "Дамп базы данных".

                Устранение неполадок

                • Если ваш тестовый сервер Code42 не запускается после установки нового хранилища ключей, удалите и переустановите сервер.
                • Если рабочий сервер Code42 не запускается после установки нового хранилища ключей, см. раздел Восстановление сервера Code42 до предыдущего состояния.
                • Большинство проблем с SSL-сертификатами связано с созданием, подписанием и преобразованием ключей. Мы рекомендуем вам:
                  • Тщательно повторите описанный выше процесс.
                  • Убедитесь, что ваш сертификат и файлы хранилища ключей содержат расширение альтернативного имени субъекта (SAN).
                    Преобразуйте хранилище ключей или сертификат в текст, как описано ниже. Найдите
                    альтернативное имя субъекта X509v3
                  • Проконсультируйтесь с вашим ЦС, чтобы убедиться, что у вас есть правильные промежуточные сертификаты.
                  • См. документацию по используемому инструменту:

                  Автоматически генерируемые самозаверяющие сертификаты

                  Ключи хранятся в хранилище ключей. Ваши авторитетные серверы или серверы хранения используют ключи в хранилище ключей для безопасной обработки транзакций.

                  Если сервер Code42 не может найти ключи, он ищет хранилища ключей со следующим приоритетом:

                  Если по какой-либо причине ваши серверы Code42 не могут найти ключи в этих местах, они генерируют самозаверяющий сертификат, чтобы обеспечить бесперебойную работу вашей среды Code42. Автоматически сгенерированный самозаверяющий сертификат следует использовать только временно, пока вы устраняете проблемы с хранилищем ключей. Code42 настоятельно рекомендует использовать сертификат, подписанный ЦС, для производственных сред.

                  Преобразование сертификатов и хранилищ ключей в текстовые файлы

                  Файлы сертификатов и хранилища ключей имеют двоичный формат или формат base64. Вы можете сделать их более удобными для чтения, преобразовав файлы в формат PEM, а затем преобразовав файлы PEM в текст следующим образом:

                  И, если вы новичок в мире Java, я также рекомендую вам пройти The Complete Java MasterClass на Udemy, чтобы изучить Java лучше и структурированнее. Это один из лучших и современных онлайн-курсов по изучению Java.

                  Основы SSL-сертификатов и хранилища ключей в Java

                  Когда мы обращаемся к защищенному сайту, использующему SSL для идентификации и шифрования, он предоставляет сертификат, проверенный надежными сторонними сайтами, такими как Verisign , GoDaddy или Thwaite . с помощью браузера сертификатов или Java-клиенты знают, что они обращаются к правильному сайту (тому, за кого он себя выдает), а не к перенаправленному прокси-сайту.

                  Этот шаг довольно прозрачен, если вы заходите на веб-сайты с помощью браузера, потому что, если сертификат не находится в доверенном хранилище браузера, вам будет предложено добавить этот сертификат, и он будет добавлен впоследствии. Но когда вы заходите на защищенный сайт с помощью Java программа, этот шаг подтверждения сертификата не прозрачен для пользователя, и сертификаты проверяются из TrustStore JRE. Т

                  его trustStore расположен в каталоге установки JDK, на который ссылается JAVA_HOME, например JAVA_HOME/jre/lib/security, и обычно называется "cacerts".

                  Если сертификат, предоставленный безопасным сайтом, присутствует в TrustStore JRE, соединение SSL будет установлено, но если сертификата там нет, Java выдаст исключение, и для решения этой проблемы вам необходимо добавить этот сертификат в trustStore.

                  Как добавлять, удалять и перечислять сертификаты из хранилища ключей Java

                  В этой статье мы увидим, как добавлять, удалять и перечислять сертификаты из хранилища ключей Java с помощью утилиты keytool.

                  keytool — это двоичный файл, расположенный в папке JAVA_HOME/jre/lib/security и используемый для добавления, удаления и перечисления сертификатов.

                  javin @localhost: C/Program Files/Java/jdk1. 6 . 0_26 / jre / lib / security keytool - list - хранилище ключей cacerts
                  Введите пароль хранилища ключей: changeit

                  Тип хранилища ключей: JKS
                  Поставщик хранилища ключей: SUN

                  Ваше хранилище ключей содержит 76 записей

                  digicertassuredidrootca, 07/01/2008, trustCertEntry,
                  Отпечаток сертификата (MD5): 87: CE: 0B: 7B: 2A: 0E: 49: 00: E1: 58: 71: 9B: 37: A8 : 93 : 72
                  trustcenterclass2caii , 01.07.2008 , trustCertEntry ,
                  Отпечаток сертификата (MD5): CE : 78 : 33 : 5C : 59 : 78 : 01 : 6E : 18 : EA : B9 : 36 : А0 : В9 : 2Е : 23

                  Вы видите, что в настоящее время хранилище ключей " cacerts " содержит 76 сертификатов. Вы также можете просмотреть эти курсы по программированию на Java, чтобы узнать больше об использовании keytool и других инструментов командной строки JDK, а также о других фундаментальных концепциях Java в пошаговой и структурированной форме.

                  <р>1. Получить сертификат: проще всего указать в браузере этот URL-адрес и, когда сертификат будет представлен, сохранить его на своем

                  <р>2. Теперь перейдите в папку Security вашего каталога установки JRE. если у вас установлен JDK, то это будет

                  Теперь будет распечатана информация о сертификате и будет запрошено подтверждение добавления сертификатов:

                  Если вы не можете получить доступ к безопасному URL-адресу с помощью браузера, вы можете использовать InstallCert, с помощью которого вы можете добавить сертификат в хранилище ключей программой. Подробные примеры см. в последнем разделе аутентификации LDAP с SSL в безопасности Java и Spring. Я предоставил подробные инструкции по использованию инструмента InstallCert.java.

                  Как использовать хранилище доверенных сертификатов и хранилище ключей в Java

                  Важные моменты о SSL, KeyStore и keyTool в Java

                  <р>1. Сертификаты необходимы для доступа к защищенным сайтам с использованием протокола SSL или для безопасного подключения клиента к серверу.

                  <р>2. JRE хранит сертификаты в хранилище ключей с именем «cacerts» в папке C:/Program Files/Java//jdk1.6.0_20/jre/lib/security.

                  <р>3. Общий пароль хранилища ключей — «Changeit».

                  <р>4. Keytool используется для доступа к хранилищу ключей в Java, и с помощью keytool вы можете перечислить и добавить сертификаты из хранилища ключей.

                  <р>5. Если вы реализуете SSL-соединение на стороне сервера, скажите, что Tomcat вам нужен как keyStore, так и trustStore, хотя оба могут быть одним и тем же файлом. keyStore будет использоваться для хранения сертификатов сервера, которые сервер будет предоставлять клиенту при подключении SSL.

                  Это все о том, как добавлять и перечислять сертификаты из keyStore или trustStore в java. Утилита keytool, которая поставляется вместе с JDK, поможет вам создать псевдоним, список сертификатов и т. д.

                  9 комментариев:

                  Можете ли вы также сообщить нам, как создать хранилище ключей в Java, я имею в виду, что если я хочу создать новое хранилище ключей или скопировать данные из одного хранилища ключей в другое? Я ищу точную команду с помощью keytool, пожалуйста, помогите.

                  Я получаю эту ошибку при подключении к моему серверу с использованием SSL в Java "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX". В нем говорится, что запрошенный сертификат не найден. Я использую самозаверяющий сертификат, созданный с помощью keytool, и я импортировал этот сертификат в хранилище ключей. Есть ли другой способ установить сертификат? мне нужно установить сертификат на стороне сервера или только на стороне клиента?

                  Вместо добавления сертификатов с помощью инструмента подсказки ключевых слов я предпочитаю использовать утилиту InstallCert.java. Если вы добавляете сертификаты с веб-сайта или URL-адреса, такого как URL-адрес LDAP, лучше всего использовать InstallCert.java. вот команда, которую я использую, просто убедитесь, что вы запускаете эту команду из каталога JRE/lib/security:

                  java -cp . Имя хоста InstallCert:порт

                  1) В вашем хранилище доверенных сертификатов не должно быть сертификатов, отправленных сервером для проверки подлинности.

                  поскольку при аутентификации на стороне клиента клиенты SSL отправляют сертификаты, соответствующие своему открытому ключу, на сервер.

                  Что вы можете сделать:
                  1) Проверьте, используете ли вы аутентификацию на стороне клиента или нет, если нет, то вам не нужно хранилище ключей, пока вы не станете SSL-сервером.

                  2) Посмотрите, используете ли вы явный файл trustStore или хранилище доверия по умолчанию, например. mytrustStore.jks в вашем приложении, убедитесь, что у вас есть сертификаты для аутентификации сервера в этом хранилище доверия.

                  One cal также использует утилиту управления ключами на основе графического интерфейса для создания хранилища ключей и импорта сертификатов, например инструмент IBM IkeyMan. Хотя я лично предпочитаю команду keytool, которая поставляется со стандартной установкой Java, инструменты с графическим интерфейсом намного проще в использовании.Еще одна важная вещь, о которой следует помнить, это то, что вы можете использовать одно и то же хранилище ключей как trustStore, так и keyStore в Java, которое используется для разных целей.

                  Ikeyman лучше, если вы хотите создать хранилище ключей на Java, он поддерживает различные типы хранилища ключей, например . Хранилище ключей JKS. Кроме того, если вы хотите создать личные сертификаты, вам сначала нужно создать запрос на сертификат, а затем подписать его с помощью центра подписи, например. GoDaday или Thwate. Вы также можете самостоятельно подписать свой сертификат для целей разработки и тестирования.

                  Пароль по умолчанию для хранилища ключей java — «changeit», все строчные буквы.

                  привет. У меня возникает проблема с установкой сертификата из-за того, что компьютер использует прокси-сервер сценария автоматической настройки при подключении к Интернету. Кто-нибудь может помочь решить эту проблему? большое спасибо.

                  Читайте также: