Экспорт сертификата корневого центра сертификации
В этой статье описывается экспорт сертификата корневого центра сертификации.
Применяется к: Windows Server 2003
Исходный номер базы знаний: 555252
Советы
- Запрос сертификата корневого центра сертификации с помощью командной строки:
- Войдите на сервер центра корневой сертификации с учетной записью администратора.
- Перейдите к начальному запуску>. Введите текст CMD и нажмите клавишу ВВОД.
- Чтобы экспортировать сервер корневого центра сертификации в новое имя файла ca_name.cer, введите:
certutil -ca.cert ca_name.cer- Войдите на веб-сайт регистрации корневого центра сертификации. Обычно сайт веб-регистрации находится по следующим ссылкам: /certsrv или /certsrv ip_address = IP-адрес сервера корневого центра сертификации. fqdn = полное доменное имя сервера корневого центра сертификации.
- Выберите «Скачать сертификат ЦС», цепочку сертификатов или список отзыва сертификатов.
- Выберите » Скачать сертификат ЦС».
- Сохраните файл certnew.cer в локальном хранилище дисков.
Отказ от ответственности за содержимое общедоступных решений
Корпорация Майкрософт и/или ее поставщики не делают никаких заявлений относительно пригодности, надежности или точности сведений и соответствующих изображений, приведенных в настоящем документе. Все эти сведения и соответствующие изображения предоставлены «как есть» без каких-либо гарантий. Корпорация Майкрософт и/или ее поставщики настоящим отказываются от каких-либо гарантийных обязательств и условий в отношении этих сведений и соответствующих изображений, включая все подразумеваемые гарантии и условия товарной пригодности, применимости для конкретных целей, качества исполнения, прав собственности и отсутствия нарушений прав интеллектуальной собственности. В частности, вы подтверждаете свое согласие с тем, что корпорация Майкрософт и/или ее поставщики ни при каких обстоятельствах не несут ответственности за прямой или косвенный ущерб, штрафные санкции, случайные, фактические, косвенные или иные убытки, включая, в частности, убытки от утраты эксплуатационных качеств, от потери данных или прибылей в связи с использованием или невозможностью использовать эти сведения и соответствующие изображения, содержащиеся в настоящем документе, возникшие вследствие соглашения, гражданского правонарушения, халатности, объективной ответственности или иным образом, даже если корпорация Майкрософт или ее поставщики заранее были извещены о возможности такого ущерба.
Обратная связь
Были ли сведения на этой странице полезными?
Fullchain-сертификаты и как их добыть
Фантастические твари и где они.Если совсем просто: те, что нам понадобятся — PEM (с расширениями .pem .crt .cer, и .key)- самые обычные текстовые файлы с зашифрованными данными внутри, которые позволяют сторонам убедиться, что их «собеседники» на другом конце именно те, за кого себя выдают. Их можно открыть Блокнотом и увидеть что-то вроде:
Таких блоков в файле может быть один или больше, в зависимости от длины цепочки.
Каждый сертификат начинается строкой «BEGIN CERTIFICATE» и заканчивается «END CERTIFICATE» с пятью тире до и после текста. Другие форматы имеют свои заголовки; например, P7B — «BEGIN PKCS7», а блок приватного ключа (о нём ниже) — «BEGIN RSA PRIVATE KEY».
Файл будет работоспособен при любом порядке блоков, но всё же желательно его соблюдать.
Неправильная последовательность снизит рейтинг SSLLabs вашего сайта (если он вам нужен; для навыков Алисы этот фактор не имеет значения).Более важная деталь: в файле не должно быть пустых строк! Также, в зависимости от операционной системы, на которой работает веб-сервер, могут быть разные требования к символам переноса строки. И, конечно, недопустимы никакие комментарии, пометки, посторонние символы.
Сертификаты можно разделить на степени — или уровни — доверия.
- Корневые сертификаты. Выпущены специальными удостоверяющими центрами, имеют наивысшую доверительность. Могут удостоверять собой любые другие виды сертификатов.
- Промежуточные сертификаты. Любые виды цепочек сертификатов. Тоже имеют право удостоверять (подписывать) другие сертификаты.
- Конечные сертификаты. Самая низкая степень доверия. Ими нельзя подписывать никакие другие сертификаты.
То есть, сертификаты составляют вертикальные цепочки, в которых более высоким сертификатом удостоверяется (подписывается) более низкий. На втором скриншоте видно, что правильный порядок блоков - обратный этой цепочке (верхний блок - конечный сертификат домена, затем промежуточные сертификаты по восходящей и, наконец, в самом низу - корневой сертификат).
Теперь легко понятны ещё два термина:
- fullchain («полная цепочка») сертификат — тот, который хранит всю цепочку, включая корневой и конечный сертификаты (и все промежуточные, если они участвуют).
Физически fullchain-сертификат — тот же текстовый файл, который хранит все подписи, участвующие в цепочке. - самозаверенный (чаще говорят «самоподписанный») — конечный сертификат, который удостоверяет сам себя на манер корневого.
Кроме того, из-за того, что самоподписанные сертификаты невозможно отозвать, возникают различные риски («атака посредника» итд).
Самоподписанные сертификаты имеют самую низкую надёжность и их использование недопустимо, когда требуется обеспечить безопасный внешний обмен данными. В изолированных сетях самоподписанные сертификаты вполне возможны.
Для цифровой аутентификации, в том числе подписи к сертификатам существует два вида ключей:
Публичный (открытый) Приватный (закрытый) Можно и нужно открывать в доступ Ни в коем случае никому нельзя отдавать Используется только для проверки подписи и идентичности владельца Используется для создания цифровых подписей Если возникло подозрение, что ваш закрытый ключ мог попасть к кому-то в руки, должны быть немедленно выпущены новые ключи и отозваны связанные с ними сертификаты.
Организацию, выпускающую сертификаты (удостоверяющий центр или любую другую) называют издателем. Каждый издатель выкладывает в общий доступ свой публичный ключ, чтобы любой желающий мог проверить, действительно ли сертификат подписан именно этим издателем.
И напоследок, у сертификата есть срок действия, после истечения которого пользоваться им не получится. Он может быть отозван и досрочно по каким-то причинам (например, скомпрометирован приватный ключ издателя или владельца конечного сертификата). Сертификат, у которого всё в порядке, называют валидным (действительным) — и наоборот.
fullchain-сертификаты в навыках Алисы
Поскольку безопасность и надёжность — ключевые характеристики облачных сервисов (нередко с обменом данными сразу между несколькими провайдерами), это накладывает современные требования к протоколам и сертификатам, в том числе:
- обязательная работа через HTTPS,
- обязательное использование fullchain-сертификатов.
Благо, сегодня вряд ли удастся встретить хостинг без поддержки SSL/HTTPS, зато бесплатных сертификатов в достатке (да, те самые Lets’ Encrypt, SSL For Free, CAcert итд).
Как получить такой сертификат?
Вариантов и инструкций в Интернете достаточно много. В том числе у нас на вики в статье » Алиса управляет Умным домом через Node-RED».
В следующих разделах — краткие инструкции по самым популярным сервисам:
Lets’ Encrypt и certbot
Потребуется установить программу certbot. Под *nix- системами это сделать проще, но под Windows тоже не потребуется сверхъестественных усилий.
Инструкции могут сильно отличаться от версии операционной системы, одной страницей тут не обойтись, лучше подобрать подходящий для вашей среды вариант в Интернете. Да и задача этой инструкции в другом: дать общее представление о полных цепочках и объяснить, что делать со сгенерированными файлами, чтобы их получить.
Предположим, что certbot у вас установлен. Что дальше? Запускаем несколько консольных команд.
certbot register -m emailадминистратора@вашдомен.com
certbot certonly --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com
Если опасаетесь, что что-то не так и хотите сначала потренироваться, добавьте опцию —dry-run (режим эмуляции для отладки ошибок)
certbot certonly --dry-run --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com
После успешной генерации сертификата у вас появятся 4 файла (их расположение также сильно зависит от вашей операционной системы):
- cert.pem (конечный сертификат),
- chain.pem (цепочка доверия от корневого сертификата, не включающая конечный),
- fullchain.pem (нужная нам полная цепочка, включая конечный сертификат, по сути это сложение cert.pem + chain.pem),
- privkey.pem (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).
Для веб-сервера необходимы два из них: fullchain.pem и privkey.pem.
Ещё несколько полезных команд certbot
Проверка и обновление сертификатов (полезно поставить запуск этой команды по расписанию):
certbot -q renew
Для проверки и обновления также есть тестовый режим (чтобы убедиться. что ваши домены будут обновляться):
certbot renew --dry-run
Добавление новых доменов и поддоменов к сертификату:
certbot certonly --webroot -w /var/www/папкасервера --expand -d вашдомен.com -d test.вашдомен.com -d www.вашдомен.ru
Изменение адреса администратора:
certbot register --update-registration -m newemail@вашдомен.ru
SSL For Free
Получить сертификат через онлайн-сервис намного быстрее и проще, ничего устанавливать не нужно:
- Регистрация на сайте https://sslforfree.com/
- Выбор настроек (обычно ничего трогать не нужно, просто жмите «Next Step»)
- Подтверждение прав на домен, для которого получаете сертификат, любым из способов:
- на почту его владельца (список готовый, посторонний адрес вписать не получится) — вам должен быть доступен один из перечисленных email.
- изменением полей DNS (CNAME) — для новичков этот способ самый запутанный, но не требует доступности почты и http.
- скачиванием подтверждающего файла и размещением его в подпапке сайта — к домену должен быть http-доступ из Интернета в момент проверки.
- После подтверждения останется выбрать формат: предлагается список шаблонов (Default, Tomcat, AWS, cPanel, Google App, Heroku. nginx, Plesk, итд) — но во всех случаях, кажется, скачивается идентичный архив.
Сертификат готов, но. сервис SSL For Free создаёт три файла:
- ca_bundle.crt (цепочка, исключая конечный сертификат)
- certificate.crt (сам конечный сертификат)
- private.key (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).
Поэтому fullchain мы склеим вручную из двух первых файлов (сначала certificate.crt, затем ca_bundle.crt), и назовём его fullchain.crt (имена на самом деле могут быть любыми, но принято — и нужно — использовать «говорящие» названия: fullchain.crt/fullchain.pem, или domain.ca-bundle)
Сделать это можно как консольными командами, так и в обычном Блокноте Windows. Пример консольной команды:
cat domain.crt Intermediate1.crt Intermediate2.crt CARoot.crt > fullchain.crt
(предполагается, что «domain.crt» — конечный сертификат домена, затем по восходящей перечислены все промежуточные файлы — их может быть один или несколько — и в самом конце корневой сертификат).
Серверу отдаём, соответственно, fullchain.crt и private.key.
Есть вероятность, что дополнительно понадобится файл root, содержащий подписи корневых удостоверяющих центров. Средствами Windows, например, при помощи штатной certutil можно получить корневые сертификаты в формате sst ("certutil.exe -generateSSTFromWU roots.sst"), а распаковкой регулярно обновляемого файла authrootstl.cab - в формате stl и затем сконвертировать при необходимости в нужный тип.Немного паранойи
Не забывайте, что онлайн-способы генерации не должны применяться для чувствительных данных! Ведь если ваш приватный ключ создан сторонним сервисом, ему известен ваш приватный ключ! А значит, теоретически он уже попал в чужие руки. В этом случае стоит всё же приложить чуть больше усилий и сгенерировать все сертификаты и ключ локально.
Как понять, что всё хорошо
Очень просто: вы скопировали файлы сертификатов в нужную папку, указали вашему веб-серверу пути к ним, и всё работает! 🙂
Как понять, что всё плохо
При попытке верифицироваться с неполноценным сертификатом вы получите сообщение «Endpoint URL: Некорректный SSL-сертификат».
Возвращайтесь к началу инструкции, по которой вы его выпускали и проверьте, всё ли вы сделали правильно. Сравните с любой другой инструкцией из Интернета. Возможно, где-то вкралась ошибка, или другое объяснение окажется для вас более полным и понятным.
Как проверить сертификат на валидность
Онлайн
Вот несколько популярных сервисов для онлайн-проверки валидности сертификатов:
Все три англоязычные, все три бесплатные, для всех трёх надо ввести ваш доменный адрес, но первый выводит более красивые картинки и, возможно, это и сыграло роль в его популярности в русскоязычном сегменте. Главное — чтобы все пункты были с зелёными крыжиками ) самоподписанные сертификаты этот сервис тоже определяет.
Ещё раз: ни в коем случае никогда и никому не отправляйте файлы, которые содержат ваши приватные ключи! К онлайн-сервисам проверки сертификатов это тоже относится.
Офлайн (без доступа к Интернету)
Да, в изолированных сетях и сетях без доступа к Интернету тоже бывают нужны SSL-сертификаты. И значит, должен быть способ их проверки без выхода в Интернет.
Такой способ есть, использует криптографический пакет OpenSSL (что-то вроде «openssl x509 -in myserver.crt -text -noout», «openssl x509 -noout -modulus -in server.crt | openssl md5», «openssl verify -CAfile RootCert.pem -untrusted Intermediate.pem UserCert.pem», итд — в тематику инструкции эта тема уже не входит).
Небольшой пример проверки того, что сертификаты правильно собраны в один файл (в примере назван «domain.ca-bundle»):
openssl x509 -noout -modulus -in domain.crt | openssl md5 openssl x509 -noout -modulus -in domain.ca-bundle | openssl md5 openssl x509 -noout -modulus -in | openssl md5
Команды возвращают хэш-суммы сертификатов. Для bundle, cert, private_key и всех промежуточных сертификатов они должны совпадать.
Если у полученного бандла хэш-сумма отличается — значит, собранный файл содержит ошибки (лишние переносы строк, лишние символы, которые могли нечаянно поставить, правильные символы переноса строки для вашей ОС), либо изначально провайдер отдал вам некорректные файлы.
Доверенные корневые сертификаты для АктивногоШлюза
Могут быть ситуации, когда необходимо добавить дополнительные сертификаты в хранилище сертификатов АктивногоШлюза.
- 1 Добавление сертификатов во время установки АктивногоШлюза
- 2 Убедитесь, нужен ли вам сертификат ЦС
- 3 Подготовка сертификатов
- 4 Создание хранилища доверенных сертификатов из сертификата ЦС
- 4.1 Проверка разрешений
Добавление сертификатов во время установки АктивногоШлюза
При желании дополнительные доверенные корневые сертификаты можно указать во время установки АктивногоШлюза, указав параметры установки для Linux или Windows.
Убедитесь, нужен ли вам сертификат ЦС
АктивныйШлюз подключается к другим компонентам Ключа-Астром (кластерам, серверам) или сторонним системам (таким как VMware, Cloud Foundry, Kubernetes или OpenShift) с использованием защищенных SSL каналов. Встроенного хранилища АктивногоШлюза (набор сертификатов по умолчанию, поставляемый с Java), иногда недостаточно для покрытия всех необходимых вариантов использования. Это может произойти, если, например, сертификат был выдан внутри вашей организации для прокси-сервера, принимающего SSL-трафик. Также возможно, что некоторые серверы в вашей организации, к которым АктивныйШлюз должен подключаться, генерируют и используют самоподписанные сертификаты, и ваша организация не заменила их официальными сертификатами.
При возникновении таких ситуаций в лог-файле АктивногоШлюза будет ошибка о том, что сертификат, представленный сервером, к которому ваш АктивныйШлюз пытался подключиться, не является доверенным. В этих случаях вам необходимо импортировать отсутствующий сертификат в АктивныйШлюз.
Предупреждение
Добавление сертификата является потенциальной проблемой безопасности. Перед добавлением нового доверенного корневого сертификата в АктивныйШлюз убедитесь, что безопасность вашей организации не будет скомпрометирована вашими действиями.
Если в журнале АктивногоШлюза сообщается об ошибке о том, что сертификат, представленный сервером, к которому ваш АктивныйШлюз пытался подключиться, не был доверенным, не думайте, что вам нужно добавить отсутствующий сертификат. Прежде чем продолжить, необходимы дополнительные исследования.
Ошибка недействительного сертификата также может означать, что была попытка нарушить безопасность вашей организации. Поэтому вы всегда должны исследовать эту возможность, когда сообщается о такой ошибке.
Подготовка сертификатов
Прежде чем добавлять сертификат в АктивныйШлюз, его необходимо получить и поместить в файл ca.cert .
Следующая общая информация о сертификатах ЦС может помочь вам определить необходимые сертификаты:
Условия доверенного соединения SSL:
- Между сертификатами, представленными сервером (конечная точка API), и сертификатами, присутствующими в хранилище доверенных сертификатов АктивногоШлюза, должна быть создана полная цепочка сертификатов.
- Корневой сертификат цепочки должен быть включен в хранилище доверенных сертификатов АктивногоШлюза вместе с любыми другими сертификатами, НЕ представленными конечной точкой сервера/API.
Чтобы увидеть, какие сертификаты предоставляет конечная точка, вы можете использовать следующую команду:
openssl s_client -connect : -showcerts -servername
Некоторые приложения (например, OpenShift) могут предоставлять разные сертификаты в зависимости от SNI. АктивныйШлюз установит сконфигурированное имя хоста конечной точки в SNI.
Если приведенная выше команда представляет полную цепочку сертификатов, вы должны добавить корневой сертификат в хранилище доверенных сертификатов АктивногоШлюза. Вы также можете добавить промежуточные звенья, но они не нужны, если конечная точка API их представляет.
Если приведенная выше команда не представляет полную цепочку сертификатов, то корень цепочки должен быть получен в другом месте.
Например, конечная точка запроса openssl к этому серверу возвращает только сертификат сервера, а не корневой сертификат. Вы знаете, что этот сервер представляет только сертификат сервера, а не корневой сертификат, поскольку в сообщении об ошибке говорится, что невозможно получить сертификат локального эмитента. При наличии корневого сертификата в сообщении об ошибке будет указано « Самозаверяющий сертификат в цепочке сертификатов ». Чтобы создать действительное SSL-соединение с этой конечной точкой, необходимо отдельно получить корневой сертификат.
openssl s_client -connect localhost:6443 CONNECTED(00000005) depth=0 CN = kube-apiserver verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = kube-apiserver verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:CN = apiserver i:CN = AstromKeyRootAuth --- Server certificate -----BEGIN CERTIFICATE----- MDIDYGCCAkigAwIBAgJIJ8SQ/FcmJiYwDQZJKoZIhvcNAQESBQAwFTETMBEGA1UE AxMKa3ViZXJuZXRlczAeFw0yMTAxMjcxOTM1MDhaFw0yMjAxMjcxOTM1MDhaMBkx FzAVBgNVBAMTDmt1YmUtYXBpc2VydmVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKSAQEA15BVGULXSXZAM6a4Y7lR6JfSBOXIAq1sCoydH2AdhzqHu0mXj+Fd sooRQ46f7bySZvMGFfLupmaAzH5kVJOVDQ2WoHPYVzAEhDji+SUBOi99AC0tevEa ONLdkLGzR//2u8XND0iiswsGkK3yaNyPwCVnOnA3c4O32waMoM1VI9XGuNSqqfQF 6XUx8sGHG5bNVzfHOXh5CBJZ5JReDhW/J8CbPElYJPJaQcSpTVFx5ReTQqBLeBSy eWyCwqMj/jAnKzpPffO478If/Uc8I5vS8zi2yPhYJhKqD0m1b96hH0slXKho25Ip gpu4cIw03mQZMK558W4d6ccww/OvMbpKQQIDAQABo4GvMIGsMA4GA1UdDwEB/wQE AwIFoDATBgNVHSUEDDAKBgfrBgEFBQcDATSBhAYDVR0RBH0we4IPamstazhzLWNs b25lLTAwggprdWJlcm5ldGVzghJrdWJlcm5ldGVzLmRlZmF1bHSCFmt1YmVybmV0 ZXMuZGVmYXVsdC5zdmOCAGt1YmVybmV0ZXMuZGVmYXVsdC5zdmMuY2x1c3Rlci5s b2NhbIcECmAAAYcErBcSvDANBgkqhkiG9w0BAQsFAAOCAQEAdmOq/Sp74xiLCa14 EI/9v7jUG+GqjD3HPpj/oXIdLHg6HA4nixxcxwnWAf2RAMVXBYn7qTDU6x7W5M+t 6M0uaCe8Od8oKjOKeQ31dfMpPbLYprKmcnuBriiN5gjfghINZKaZlGlX0GkBC9Ts THYbmWfXfvfsX2xfpc4J0esfK+BafllEimCx8blnw1uY7CiCedEANePT+J5Q+m9L m5pu7Qz/B4JDHLIJBArhFTBM6IIF6DhoqGUXM1XXqMlTVBpxz2vhf0N/HxcTaEBa VWu7GZbk5mCYhngmRJ8PJ3uA8yajDT2muWm/la5oOI/GeuTgR98tqjXOXmz2NjvE Zng1CA== -----END CERTIFICATE----- subject=CN = kube-apiserver issuer=CN = kubernetes --- Acceptable client certificate CA names CN = kubernetesПриведенный ниже сертификат является примером корневого сертификата для вышеуказанного сертификата сервера. Убедитесь, что вы добавляете в свои хранилища доверенных сертификатов только те корневые сертификаты, которым вы доверяете.
cat ca.crt | openssl x509 -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: CN = kubernetes Validity Not Before: Jan 27 19:35:08 2021 GMT Not After : Jan 25 19:35:08 2031 GMT Subject: CN = kubernetes Subject Public Key Info:Вы можете видеть, что это корневой сертификат, который вам нужен, потому что субъект и эмитент идентичны, и они совпадают с эмитентом сертификата сервера, показанного выше (‘kube-apiserver’).
Создание хранилища доверенных сертификатов из сертификата ЦС
Создайте дополнительное хранилище доверенных сертификатов, содержащее только ваши сертификаты ЦС, которые будут объединены в АктивномШлюзе во время выполнения со встроенным хранилищем доверенных сертификатов JDK. Хранилище доверия должно быть в формате PKCS12 . Форматы OpenSSL не поддерживаются, поэтому используйте команду keytool для выполнения преобразования. После преобразования вы должны поместить сертификат в каталог SSL АктивногоШлюза .
Примечание. Если вы импортируете несколько сертификатов, убедитесь, что вы указали уникальный псевдоним для каждого импортируемого сертификата. Если вы используете один и тот же псевдоним для каждого сертификата, все ранее использовавшиеся сертификаты будут перезаписаны.
Примеры для Linux создания файла PKCS12 из файла CRT или файла PEM и размещения его либо непосредственно в каталоге SSL АктивногоШлюза, либо в текущем каталоге для последующего копирования:
/opt/AstromKey/gateway/jre/bin/keytool -import -file ca.crt -alias dt_k8s_api -storetype pkcs12 -keystore /var/lib/AstromKey/gateway/ssl/mytrusted.p12/opt/AstromKey/gateway/jre/bin/keytool -import -file dt_k8s_api.pem -alias myCertAuthority -storetype pkcs12 -keystore mytrusted.p12Проверка разрешений
Для Linux проверьте, что пользователь АктивногоШлюза, для которого был установлен АктивныйШлюз (по умолчанию dtuser ), имеет права на запись в каталог SSL АктивногоШлюза (по умолчанию /var/lib/AstromKey/gateway/ssl ) и что у пользователя есть права на чтение для созданного хранилища доверия.
Настройка АктивногоШлюза для использования хранилища доверенных сертификатов
Чтобы настроить АктивныйШлюз для использования пользовательского файла хранилища доверенных сертификатов mytrusted.p12 , убедитесь, что файл хранилища доверенных сертификатов находится в каталоге SSL АктивногоШлюза, а затем добавьте следующие записи в файл custom.properties в каталоге конфигурации АктивногоШлюза:
[collector] trustedstore = mytrusted.p12 # the following entries are optional trustedstore-password = changeit trustedstore-type = PKCS12Вы можете отобразить настроенный список псевдонимов и описания сертификатов с помощью команды keytool -list в новом хранилище доверенных сертификатов.
# /opt/AstromKey/gateway/jre/bin/keytool -list -keystore /var/lib/AstromKey/gateway/ssl/mytrusted.p12 Enter keystore password: Keystore type: PKCS12 Keystore provider: SUN Your keystore contains 1 entry dt_k8s_api, Apr 26, 2020, trustedCertEntry, Certificate fingerprint (SHA-256): 08:18:9A:F2:29:31:0D:64:F0:1F:93:A1:CC:2E:A9:21:E9:DA:40:82:9B:A8:71:B7:A4:2C:6D:8C:B3:90:31:31Зашифрованный пароль Пароль будет удален и зашифрован при перезапуске службы АктивногоШлюза.
Перезапуск службы АктивногоШлюза и проверка конфигурации сертификата
Перезапустите основную службу АктивногоШлюза, чтобы изменения вступили в силу.
Если все настроено правильно, в журнале АктивногоШлюза должна быть запись следующего содержания:
Custom certificate configuration created successfully.Исправление проблем
АктивныйШлюз регистрирует свои действия, связанные с вышеуказанной конфигурацией. Настроенное хранилище доверенных сертификатов не будет использоваться (и конфигурация хранилища доверенных сертификатов останется неизменной), если выполняется любое из следующих условий:
- Указано системное свойство javax.net.ssl.trustStore . Если это свойство указано, оно имеет приоритет над конфигурацией АктивногоШлюза.
- Настроенное хранилище доверенных сертификатов не может быть прочитано с использованием настроенного пути, пароля и типа.
- Объединенную конфигурацию нельзя записать в файл ssl/runtime.cacerts .
Формат SSL сертификата: как конвертировать сертификат в .pem, .cer, .crt, .der, pkcs или pfx?
PEM – наиболее популярный формат среди сертификационных центров. PEM сертификаты могут иметь расширение .pem, .crt, .cer, и .key (файл приватного ключа). Она представляют собой ASCII файлы, закодированные по схеме Base64. Когда вы открываете файл pem формата в текстовом редакторе, вы можете увидеть, что текст кода в нем начинается с тега «—— BEGIN CERTIFICATE ——» и заканчивая тегом «—— END CERTIFICATE ——«. Apache и другие подобные серверы используют сертификаты в PEM формате. Обратите внимание, что в одном файле может содержатся несколько SSL сертификатов и даже приватный ключ, один под другим. В таком случае каждый сертификат отделен от остальных ранее указанными тегами BEGIN и END. Как правило, для установки SSL сертификата на Apache, сертификаты и приватный ключ должны быть в разных файлах.
Формат сертификата DER
DER формат – это бинарный тип сертификата вместо формата PEM. В PEM формате чаще всего используется расширение файла .cer, но иногда можно встретить и расширение файла .der. Поэтому чтобы отличить SSL сертификат в формате PEM от формата DER, следует открыть его в текстовом редакторе и найти теги начала и окончания сертификата (BEGIN/END). DER SSL сертификаты, как правило, используются на платформах Java.
PKCS # 7 / P7B сертификат
SSL сертификаты в формате PKCS # 7 или P7B — это файлы, которые хранятся в формате Base64 ASCII и имеют расширение файла .p7b или .p7c. P7B сертификаты содержат теги начала сертификата «—— BEGIN PKCS7 ——» и его конца «—— END PKCS7 ——«. Файлы в формате P7B включают в себя только ваш SSL сертификат и промежуточные SSL сертификаты. Приватный ключ при этом идет отдельным файлом. SSL сертификаты в формате PKCS # 7 / P7B поддерживают следующие платформы: Microsoft Windows и Java Tomcat.
PFX сертификат (формат PKCS # 12)
Формат SSL сертификата PKCS # 12 или, как его еще называют, PFX сертификат — бинарный формат, при использовании которого в одном зашифрованном файле хранится не только ваш личный сертификат сервера и промежуточные сертификаты центра сертификации, но и ваш закрытый ключ. PFX файлы, как правило, имеют расширение .pfx или .p12. Обычно, файлы формата PFX используются на Windows серверах для импорта и экспорта файлов сертификатов и вашего приватного ключа.
Конвертация SSL сертификатов в OpenSSL
Данные команды OpenSSL дают возможность преобразовать сертификаты и ключи в разные форматы. Для того чтобы сделать их совместимыми с определенными видами серверов, либо ПО. К примеру, Вам необходимо конвертировать обыкновенный файл PEM, который будет работать с Apache, в формат PFX (PKCS # 12) с целью применения его с Tomcat, либо IIS.
-
Конвертировать PEM в DER
openssl x509 -outform der -in certificate.pem -out certificate.der
openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
openssl x509 -inform der -in certificate.cer -out certificate.pem
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.ceropenssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer
openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes
Онлайн конвертер SSL сертификатов
Также существуют онлайн программы для конвертации сертификатов из одного формата в другой. Например, мы можем посоветовать SSL конвертер от SSLShopper. Используйте этот SSL конвертер для преобразования SSL-сертификатов различных форматов, таких как PEM, DER, P7B и PFX. Чтобы использовать SSL-конвертер, просто выберите файл сертификата и его текущий тип (он определяется по формату расширения), затем выберите формат, в какой Вам необходимо преобразовать SSL сертификат и нажмите кнопку “Convert Certificate”. Обратите внимание, что в зависимости от того, в какой формат вам нужно конвертировать SSL сертификат, от вас потребуются разные исходящие файлы.
Конвертация PEM в DER
Для конвертации стандартного сертификата в формате PEM в бинарный формат DER, потребуется только файлSSL сертификата. Обычно, вы его получаете в архиве вместе с промежуточными сертификатами. Как правило, в его названии указано имя вашего домена.
Конвертация PEM в P7B / PKCS#7
Если же вам нужно преобразовать ваш стандартный SSL сертификат в файл формата P7B / PKCS#7, вы можете кроме SSL сертификата вашего домена загрузить также файлы с цепочками сертификатов. Более подробно о том, что такое цепочка SSL сертификатов, мы писали в статье о CA-bundle.
Конвертация PEM в PFX / PKCS#12
Обратите внимание, что для конвертации стандартного формата SSL сертификата необходимо добавить еще один файл – ваш приватный ключ. Приватный ключ – это конфиденциальная информация, которая должна быть только у вас. Поэтому центры сертификации не высылают его месте с файлами вашего сертификата. Приватный ключ создается в момент генерации CSR запроса. Если вы генерируете CSR у себя на сервере, на нем же должен автоматически сохраниться ключ. Если вы создаете CSR запрос в специальном инструменте на нашем сайте (на странице по ссылке или во время заполнения технических данных), ключ показывается вам в конце генерации CSR (или введения технических данных), но не сохраняется в нашей базе данных. Поэтому важно, чтобы вы самостоятельно сохранили приватный ключ.
Конвертация PFX / PKCS#12 в PEM
Если вам необходимо преобразовать SSL сертификат формата PFX в PEM-формат, следует открыть файл сертификата в любом текстовом редакторе и скопировать текст каждого сертификата вместе с тегами BEGIN / END в отдельные файлы, после чего их следует сохранить их как certificate.cer (для сертификата вашего сервера) и cacert.cer (для цепочки промежуточных сертификатов). То же самое следует проделать с текстом приватного ключа и сохранить его под названием privatekey.key.