Как добавить цепочку в сертификат pkcs12 (p12, pfx), как конвертировать его в crt/cer –

Firefox

Даже после того, как вы установите доверенный источник сертификата в хранилище, Firefox все равно будет выдавать предупреждения. Этого может не случиться в Windows 10, но почти наверняка случится в macOS. Справиться с этим достаточно просто. Firefox демонстрирует вот такой экран:

Чтобы добавить разрешения сертификату, кликните «Дополнительно…». Сразу же после этого кликните на «Принять риск и продолжить», чтобы дать понять, что вы знаете о риске.

Это нужно сделать всего один раз, но для каждого локального домена.

Keystore & truststore

Говоря о JKS, стоит отметить, что данные файлы могут использоваться как KeyStore так и TrustStore. Это два различных типа хранилищ, которые находятся в JKS файлах. Одно из них (KeyStore) содержит более чувствительную информацию типа приватного ключа, и поэтому требует пароля для доступа к этой информации.

Но так же эти сертификаты идут в поставке Java в файле cacerts, который по умолчанию расположен в директории java.homelibsecurity и имеет пароль по умолчанию changeit.

Данная информация может быть полезна в тех случаях, когда установка JDK/JRE осуществляется в компании централизовано из одного источника, и имеется возможность добавления туда своих доверенных сертификатов компании для prod/uat окружения.

Ниже приведена таблица с некоторыми различиями KeyStore & TrustStore.

Macos — chrome и safari

1. Дважды кликните на корневом сертификате (ca.crt).

2. Выберите нужную связку ключей [keychain] (login, если вы хотите, чтобы сертификат считался доверенным только в вашем аккаунте, или System, если сертификат должен считаться доверенным во всей системе).

3. Добавьте сертификат.

4. Откройте «Keychain Access» (если еще не открыт).

5. Выделите keychain, который выбрали раньше.

6. Вы должны увидеть сертификат MY-CA (это будет имя, которое вы, как CN, дали вашему источнику сертификата).

7. Дважды кликните по сертификату.

8. Разверните «Доверять» и выберите опцию «Доверять всегда» в пункте «При использовании этого сертификата».

9. Закройте окно сертификата и введите свой пользовательский пароль (если требуется).

Nginx

server {
listen 443;
ssl on;
ssl_certificate /path/to/localhost.crt;
ssl_certificate_key /path/to/localhost.key;
...
}

Windows 10 — chrome, ie11 и edge

1. Дважды кликните на сертификате (ca.crt).

2. Кликните на кнопку «Установить сертификат».

3. Выберите, хотите ли вы хранить его на уровне пользователя или на уровне машины.

4. Кликните «Дальше».

5. Выберите «Разместить все сертификаты в следующем хранилище».

6. Кликните «Обзор».

7. Выберите «Доверенные корневые источники сертификатов».

8. Кликните «ОК».

9. Кликните «Дальше».

10. Кликните «Завершить».

11. Если появится подсказка, кликните «Да».

Дёргаем цепочку сертификатов

$ uname -or
FreeBSD 10.3-STABLE
$ openssl version
OpenSSL 1.0.2h  3 May 2021
$ `echo $SHELL` --version
tcsh 6.18.01 (Astron) 2021-02-14 (x86_64-amd-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec
$ /usr/local/bin/bash --version
GNU bash, version 4.3.25(1)-release (amd64-portbld-freebsd10.0)

$ echo | openssl s_client -connect ya.ru:443 | openssl x509 -certopt ca_default -out ya.pem -outform PEM

$ openssl x509 -in ./ya.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://yandex.ocsp-responder.com
                CA Issuers - URI:http://repository.certum.pl/ycasha2.cer

$ fetch http://repository.certum.pl/ycasha2.cer

$ openssl x509 -inform der -in ./ycasha2.cer -out ./ycasha2.pem

$ openssl x509 -in ./ycasha2.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://subca.ocsp-certum.com
                CA Issuers - URI:http://repository.certum.pl/ctnca.cer

$ fetch http://repository.certum.pl/ctnca.cer

$ openssl x509 -inform der -in ./ctnca.cer -out ./ctnca.pem

$ openssl x509 -in ./ctnca.pem -noout -text | grep 'X509v3 extensions' -A 6
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

$ cat ya.pem ycasha2.pem ctnca.pem > chain0.pem

$ echo | openssl s_client -connect ya.ru:443 | grep Verify
    Verify return code: 0 (ok)

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
    Verify return code: 20 (unable to get local issuer certificate)

$ openssl x509 -noout -hash -in ./ctnca.pem
48bec511

$ ln -s `pwd`/ctnca.pem `pwd`/48bec511.0

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
DONE
    Verify return code: 0 (ok)

$ ./issuers.sh ./ya.pem
0
http://repository.certum.pl/ycasha2.cer
tmp.der                                       100% of 1196  B   16 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem0.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem0.pem
1
http://repository.certum.pl/ctnca.cer
tmp.der                                       100% of  959  B   13 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem1.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem1.pem
cat ././ya.pem* > chain.pem
Certificate chain:
-rw-r--r--  1 root  wheel  5842 Jun 30 15:46 chain.pem

$ md5 chain0.pem ; md5 chain.pem
MD5 (chain0.pem) = 6d32b0798d48d14764cd26cc4f730444
MD5 (chain.pem) = 6d32b0798d48d14764cd26cc4f730444

Доверие к сертификатам

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

Использование сертификата

Приложениям, обслуживающим ваш контент, понадобится доступ к файлам сертификата и закрытого ключа. Это может быть локальный веб-сервер (Apache или NGINX), локальный сервис или какой-то другой локальный инструмент, допустим, сборщик модулей DevServer.

Вот несколько примеров:

Источник сертификата (certificate authority)

1. Создайте закрытый ключ и самоподписанный сертификат

openssl req -x509 -nodes -new -sha512 
-days 365 -newkey rsa:4096 -keyout ca.key 
-out ca.pem -subj "/C=US/CN=MY-CA"

Опционально: если необходимо, можно заменить MY-CA в CN на что-нибудь другое.

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

openssl x509 -in ca.pem -text -noout

2. Создайте файл сертификата с расширением .crt:

openssl x509 -outform pem -in ca.pem -out ca.crt

Как добавить цепочку в сертификат pkcs12 (p12, pfx), как конвертировать его в crt/cer

openssl pkcs12 -in yourcert.pfx -nocerts -out yourcert.key
openssl pkcs12 -in yourcert.pfx -clcerts -nokeys -out yourcert.crt

openssl x509 -in intermediate.cer -out intermediate.pem
openssl x509 -in root.cer -out root.pem
openssl x509 -in yourcert1.crt -out yourcert1.pem

cat yourcert.pem intermediate.pem root.pem >> yourcert-chain.pem

 openssl pkcs12 -export -out yourcert -fullchain.p12 -inkey yourcert.key -in yourcert -chain.pem

keytool -list -v -keystore yourcert-fullchain.p12 -storepass [ваш_пароль] -storetype PKCS12 | more

Корневые сертификаты

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

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

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

В данном примере сертификаты «Б» и «В» называются промежуточными.

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

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

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

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

Посмотреть локальные списки корневых сертификатов можно в настройках браузеров или операционной системы.

Подключение ssl в grpc / rsocket

Если говорить о двунаправленном обмене бинарными данными, современных тенденциях к написанию реактивных приложений, стоит отметить gRPC и RSocket для создания подобных приложений. Но поскольку в основании этих протоколов можно использовать Netty как транспорт, логика конфигурирования останется. Поэтому я не буду уделять этому много внимания.

Подключение ssl в spring boot для restcontroller

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

Конечно же, это приводит к избыточности зависимостей и к увеличению времени загрузки, но упрощает разработку. Куда проще написать аннотацию RestController, чем самому разбираться с тем, как корректно хендлить запросы через сервлеты. А для того, чтобы перенаправить всё взаимодействие через сервлеты в защищённый канал с использованием сертификатов, в Spring Boot есть два пути проcтой и более сложный для кастомных решений.В первом случае достаточно воспользоваться набором пропертей

server.ssl.key-store-type=JKS
server.ssl.key-store=classpath:cert.jks
server.ssl.key-store-password=changeit
server.ssl.key-alias=key
trust.store=classpath:cert.jks
trust.store.password=changeit

И все будет сделано за вас. Либо, если требуется более кастомная конфигурация, поднятие коннекторов на разных портах с нестандартными настройками и так далее, тогда путь лежит в сторону использования интерфейса WebServerFactoryCustomizer, имплементации которого существуют для всех основных контейнеров будь то Jetty, Tomcat или Undertow.

Поскольку это функциональный интерфейс, его довольно просто можно описать через lambda c параметром типа Connector. Для него мы можем выставить флаг setSecure(true), затем заполнить необходимые параметры для ProtocolHandler-а, выставив ему пути до jks c keystore и trustStore и соответствующие пароли к ним. Например, для tomcat код будет выглядеть подобным образом:

Подключение ssl к nettyserver

При создании нового проекта, подразумевающего взаимодействие клиента и сервера бинарными данными(protobuf) через защищенные вебсокеты (wss), возник вопрос подключения SSL в netty сервер. Как оказалось, это не представляет особых проблем, достаточно в билдере сетевого интерфейса добавить метод .withSslContext(), в который необходимо передать созданный контекст.

Поручители

В роли поручителя-удостоверителя выступает центр сертификации, который выпустил SSL-сертификат по запросу владельца сайта.

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

Пусть некто «Б» удостоверил личность некоего «А».

Проблему можно считать преодолённой, если вы знаете и доверяете «Б», а что, если — нет: не знаете или не доверяете.

«Б», в свою очередь, может сообщить, что его знает «В».

В принципе, длина цепочки удостоверений не ограничена. Главное, чтобы в ней оказался тот, кому мы доверяем.

Мишу знает Боря, Борю знает Дима, Диму знает Вова, а вот уж Вову мы знаем сами. Помните шуточную теорию о шести рукопожатиях между двумя любыми людьми, одновременно живущими на Земле?

Однако в реальной жизни в цепочке знакомых между собой людей может долго не быть знакомого лично нам. Или эта цепочка может оказаться слишком длинной. Или потребовать слишком много ресурсов на свою обработку.

Сертификат доменного имени

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

1. Создайте файл расширения x509 v3:

cat > v3.ext <<-EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names 
[alt_names]
# Локальные хостинги
DNS.1 = localhost
DNS.2 = 127.0.0.1
DNS.3 = ::1 
# Перечислите доменные имена
DNS.4 = local.dev
DNS.5 = my-app.dev
DNS.6 = local.some-app.dev
EOF

Следуя этому шаблону, можно добавить сколько угодно доменных имен.

Примечание: пожалуйста, обновите DNS.4, DNS.5 и DNS.6 или удалите их, если у вас не настроены никакие локальные доменные имена.

2. Создайте закрытый ключ и запрос на подпись сертификата:

openssl req -new -nodes -newkey rsa:4096 
-keyout localhost.key -out localhost.csr 
-subj "/C=US/ST=State/L=City/O=Some-Organization-Name/CN=localhost"

Опционально: страну, штат, город и организацию можно изменять.

3. Создайте самоподписанный сертификат:

openssl x509 -req -sha512 -days 365 
-extfile v3.ext 
-CA ca.crt -CAkey ca.key -CAcreateserial 
-in localhost.csr 
-out localhost.crt

Тестирование tls/ssl

Для того чтобы провести тестирование реализованного безопасного подключения имеется возможность создать keystore программно, используя классы из пакета java.security.* Это даст возможность тестировать различное поведение системы в случае разных ситуаций типа истекших сертификатов, проверки корректной валидации доверенных сертификатов и так далее.

Чтобы грамотно проверить работоспобность придется пройти по всем составным частям jks и воссоздать программно внутри KeyStore пару ключей KeyPair, свой сертификат X509Certificate, цепочку родительских сертификатов, подпись и доверенные корневые сертификаты.

Для упрощения этой задачи можно воспользоваться библиотекой bouncyСastle, которая предоставляет ряд дополнительный возможностей в дополнение к стандартным классам в Java, посвященным криптографии из Java Cryptography Architecture (JCA) и Java Cryptography Extension (JCE).

Формат сертификатов

В рамках работы с сертификатами обычно используется контейнер PKCS 12 для хранения ключей и сертификатов, но в рамках Java, в дополнение широко используется проприетарный формат JKS (Java KeyStore). Для работы с хранилищем JDK поставляется с консольной утилитой keytool.

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

Заключение

Теперь, когда сертификат создан и доверие к нему обеспечено, вы без проблем можете посещать свой локальный домен! Обслуживание приложений стало безопасным, и вы можете спокойно продолжать разработку. Возвращаясь к примеру с Express, результат на экране будет таким:

Сайт полностью загружен, и рядом с URL в Chrome теперь отображается символ безопасного соединения.