Как использовать свои корневые сертификаты для openssl в OS X 10.9?
Я повсеместно использую сертификаты от cacert.org.
В тех системах, в которых изначально корневой сертификат cacert доверенным не является, я его установил. В том числе в системный keychain под OS X 10.9. Так что в сафари, например, серверный ssl-сертификат от cacert нормально принимается.
Проблема с приложениями, который используют библиотеку openssl под OS X: wget, owncloud client. Сертификат не проходит.
Пробовал по найденному в интернете кидать корневой сертификат как в /System/Library/OpenSSL, так и в /opt/local/etc/openssl (у меня кроме системного стоит openssl из macports). Все равно ни wget, ни owncloud client сертификат не принимают.
openssl (обе версии) говорит следующее:
openssl s_client -showcerts -connect domain.ru:443
CONNECTED(00000003)
depth=0 CN = *.domain.ru
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = *.domain.ru
verify error:num=27:certificate not trusted
verify return:1
depth=0 CN = *.domain.ru
verify error:num=21:unable to verify the first certificate
verify return:1
- Вопрос задан более трёх лет назад
- 2786 просмотров
Что такое корневой сертификат?
Корневой сертификат SSL, CA certificate — это электронный документ, которым центры сертификации подписывают SSL-сертификаты при выдаче.
Корневые сертификаты Sectigo, Thawte, Digisert, GeotTrust и RapidSSL установлены во всех популярных браузерах. Браузеры доверяют этим центрам и всем выданным ими сертификатам.
Если корневой сертификат центра не установлен в браузере — он будет распознаваться как недостоверный. Это относится и к самоподписанным сертификатам. Посетители таких ресурсов видят предупреждение:
В части случаев конечный сертификат выдает не основной центр, а посредник. Создается цепочка доверия: корневым сертификатом подписывается промежуточный, промежуточным — сертификат сайта.
Покупая SSL-сертификат, владелец сайта получает все промежуточные сертификаты. Каждый из них нужно установить на сервер. При соединении с сервером браузер посетителя получит информацию о цепочке сертификатов. Проверит, чтобы каждый из них был подписан предыдущим. Дойдет до корневого сертификата и поймет, что сайт надёжен.
Другие вопросы из категории
1С 8.2 HTTPS: добавление сертификатов в cacert.pem
В 1С 8.2, при попытке установить HTTPS соединение с сайтом, можно получить такую ошибку: «Peer certificate cannot be authenticated with known CA certificates«. В то же время, при соединении с тем же адресом в 1С 8.3, всё работает. В чём дело, и как это исправить?
Дело в том, что 8.3 пользуется системным хранилищем сертификатов. А в 8.2 в качестве такого хранилища выступает файл cacert.pem, расположенный в каталоге 1С (например: C:\Program Files\1cv82t\8.2.17.169\bin\cacert.pem). И там есть не все современные корневые сертификаты. Надо добавить недостающее, и всё должно заработать.
План такой:
1. Получить сертификаты с сайта
2. Преобразовать сертификаты в текстовый вид
3. Добавить тексты сертификатов в cacert.pem
Поскольку я не знаю, каким веб-браузером вы пользуетесь, то рассмотрю разные варианты. Из-за этого первый пункт плана получился самым обширным. Полное содержание этой статьи выглядит так:
1. Получить сертификаты с сайта
1.1 Открыть адрес в браузере
1.2 Открыть окно просмотра сертификата
1.2.1 Internet Explorer 11
1.2.2 Google Chrome 68
1.2.3 Opera 54
1.2.4 Firefox 61
1.3 сохранить нужные сертификаты в файл
1.3.1 выбор нужных сертификатов
1.3.2 Экспорт сертификата в стандартном просмотрщике
1.3.3 экспорт сертификата в Firefox:
2. Подготовка текста сертификата
3. Добавление сертификата в cacert.pem
1. Получить сертификаты с сайта
Чтобы получить сертификаты, можно открыть нужный адрес в браузере, затем попросить браузер показать дополнительную информацию или свойства, среди них выбрать просмотр сертификата, и сохранить нужные сертификаты в файле.
1.1 Открыть адрес в браузере
Первый пункт (открыть нужный адрес) затруднений не вызывает: надо просто ввести нужный адрес (не забывая префикс https:// в начале) в адресную строку. Для примера я возьму свой сайт для демо-магазина https://demo.sync1c.ru:
Кстати, на момент написания статьи, я так и не привёл этот сайт в порядок в плане HTTPS. поэтому браузеры ругаются, что на странице присутствует небезопасное содержимое. Если посмотреть исходный код страницы, то видно, что адреса всех картинок, скриптов, и т.д. начинаются на «http://». Надо поменять на «https://» или «//», но пока руки не доходят. Впрочем, это сделает наш пример даже интереснее. Поскольку я точно знаю, что сайт безопасен, знаю, чем вызваны предупреждения, и не собираюсь вводить сюда данные кредитки, то могу не обращать внимание на опасения браузера.
1.2 Открыть окно просмотра сертификата
Итак, надо добраться до сертификата сайта. В разных браузерах это выглядит по-разному:
1.2.1 Internet Explorer 11
В главном меню выбрать Файл / Свойства. Либо нажать правой кнопкой на пустом месте страницы (где нет ничего: ни картинок, ни надписей, ни кнопок, и т.д.) и выбрать «Свойства» — обычно это самый нижний пункт меню. Откроется окно свойств страницы:
Нажмём кнопку «Сертификаты» — откроется окно «Сертификат»:
1.2.2 Google Chrome 68
Слева от адреса кликнуть иконку «сведения о сайте». Она может выглядеть как буква «i» в кружочке, или надпись «Защищено», и т.д. Появится окошко сведений:
Нажмём «Сертификат» — откроется окно «Сертификат», практически такое же, как в IE:
1.2.3 Opera 54
Слева от адреса кликнуть иконку «сведения о сайте». Она может выглядеть как замочек, или земной шар, и т.д. Появится окошко сведений:
Нажмем «Подробнее» — появятся подробности:
Кликнем на сертификат — откроется стандартное окно «Сертификат», как в Google Chrome:
1.2.4 Firefox 61
Слева от адреса кликнуть иконку «Show site information». Появится окошко сведений:
Нажать уголок «Show connection details». Появится окошко «Site security»:
Нажать «More Information». Появится «Page Info»:
Нажать «View Certificate». И вот тут, наконец-то, появится «Certificate Viewer»:
В отличие от остальных браузеров, Firefox использует свой собственный просмотрщик сертификатов.
1.3 сохранить нужные сертификаты в файл
1.3.1 выбор нужных сертификатов
Цепочка сертификатов для demo.sync1c.ru выглядит так:
Здесь мы видим, что сертификат для сайта «demo.sync1c.ru» выпущен издателем «cPanel, Inc. Certification Authority». В свою очередь, его сертификат выпущен издателем «COMODO SECURE ™». Т.е., грубо говоря, COMODO ручается за cPanel, а cPanel ручается за demo.sync1c.ru. У всех браузеров есть списки сертификатов, которым можно доверять, и этот сертификат COMODO туда входит. Поэтому браузеры доверяют COMODO, с его подачи они доверяют cPanel, и, уже с её подачи — сайту demo.sync1c.ru. Примерно так это работает, если грубо и упрощённо.
Чтобы 1С 8.2 стала работать с нашим сайтом по HTTPS, надо добавить соответствующие сертификаты в её список доверенных. Можно пойти двумя путями:
— добавить сертификаты COMODO и cPanel.
— добавить сразу сертификат demo.sync1c.ru
Я в своё время пошёл первым путём, т.е. добавил сертификаты COMODO и cPanel, после этого доступ к demo.sync1c.ru заработал. Затем ещё добавил сертификат для localhost, т.е. это я уже сделал вторым путём. Тоже работает. Сейчас я хотел поэкспериментировать, удаляя/добавляя сертификаты, и обнаружил, что старая версия cacert.pem почему-то стала позволять работать с demo.sync1c.ru. Вероятно, что-то как-то изменилось в родительских сертификатах цепочки. Мир сертификатов, он не является статичным: выпускаются новые, старые отзываются, либо прекращается срок действия, и т.д. Соответственно, не факт, что тот или иной рецепт однозначно сработает — возможно, вам придётся попробовать несколько вариантов.
1.3.2 Экспорт сертификата в стандартном просмотрщике
Напомню: IE, Chrome и Opera используют одинаковые окна для просмотра сертификата (видимо, это стандартное системное окно), а Firefox пользуется своим.
1. На вкладке «Путь сертификации» выбираем нужный сертификат, нажимаем «Просмотр сертификата». Это, если нужен какой-то из родительских сертификатов. Если сам конечный сертификат — этот шаг пропускаем, мы и так уже его просматриваем.
2. Переходим на вкладку «Состав», и видим кнопку «Копировать в файл»:
В браузере Internet Explorer эта кнопка почему-то всегда неактивная, но в Chrome и Opera она работает. Для тех же самых сертификатов. Поэтому, если к вас Internet Explorer, и тоже кнопка неактивная — закройте браузер, и скачайте другой.
После нажатия «Копировать в файл» появляется окно «Мастер экспорта сертификатов»:
Нажмём «Далее», попадаем на выбор формата:
Оставляем первый пункт (Файлы X.509 (.CER) в кодировке DER):
Далее выбираем папку и имя файла:
Ещё одно окно с подтверждением:
1.3.3 экспорт сертификата в Firefox:
На вкладке Details выбираем нужный сертификат, нажимаем «Export. «:
Для типа файла выбираем «X.509 Certificate (DER) (*.der)»:
И нажимаем «Сохранить». Готово!
2. Подготовка текста сертификата
Теперь надо подготовить текст сертификата для вставки в файл cacert.pem. Он выглядит примерно так:
Название
========
MD5 Fingerprint=.
Certificate:
.
-----BEGIN CERTIFICATE-----
.
-----END CERTIFICATE-----
Название сертификата надо написать вручную, остальное можно получить с помощью консольного приложения openssl.
Проект OpenSSL — это бесплатный набор инструментов с открытым исходным кодом, он широко используется в криптографических задачах подобного рода. Но на официальном сайте можно скачать только исходные тексты. Однако официальная Wiki предлагает несколько ссылок на хранилища OpenSSL в откомпилированном (готовом к использованию) виде:
https://wiki.openssl.org/index.php/Binaries
Здесь предлагается скачать OpenSSL в виде программы-инсталлятора для Windows. Если вы владеете английским, то чтение раздела «System Requirements» наверняка вас развлечёт 🙂 Не знаю, зачем нужен инсталлятор для консольной программы. хотя, возможно, он прописывает путь в системную переменную PATH — это как бы удобно. В общем, надеюсь, вы сумеете найти и скачать OpenSSL из надёжного источника, либо собрать её самостоятельно.
Чтобы получить текст сертификата для cacert.pem, выполните такую команду:
openssl.exe x509 -inform der -in -fingerprint -md5 -text > text.txt
Вместо подставьте имя файла, куда вы скачали/экспортировали сертификат. Обратите внимание, что выход (результат работы) программы перенаправляется в файл text.txt — после выполнения этой команды там будет готовая часть текста для cacert.pem (без названия). Если вы обрабатываете несколько сертификатов, то не забывайте менять имя выходного файла.
Надеюсь, вы сумеете справиться с запуском консольной программы и получением результатов. Иначе надо писать про это отдельную статью. Попробуйте погуглить «работа в командной строке Windows», например.
3. Добавление сертификата в cacert.pem
Добавьте название и текст сертификата, полученный на шаге 2, в конец cacert.pem с помощью любого хорошего текстового редактора (блокнот Windows не рекомендуется). Поскольку cacert.pem находится внутри каталога «Program Files», надо запускать редактор от имени администратора. Либо перенести cacert.pem в другое место, исправить, а потом перенести обратно — проводник Windows будет запрашивать разрешение администратора.
Если у вас нет хорошего текстового редактора — скачайте Notepad++.
Информация
- Пользовательское соглашение
- Политика конфиденциальности
Доверенные корневые сертификаты для АктивногоШлюза
Могут быть ситуации, когда необходимо добавить дополнительные сертификаты в хранилище сертификатов АктивногоШлюза.
- 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 .