Введение
Речь пойдет про типовой почтовый сервер, настроенный самостоятельно на базе популярных бесплатных компонентов — Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim на CentOS 8. В качестве бэкенда для web сервера там используется apache, так что получать сертификаты будем с его помощью.
В ситуации с непубличным почтовым сервером нет принципиальной необходимости использовать подтвержденный сертификат. Вы запросто можете выпустить свой самоподписаный и использовать его. Пользователям достаточно будет подтвердить, что они доверяют этому сертификату и проблем не будет.
Тем не менее, последнее время наблюдается тенденция по выдавливанию самоподписанных сертификатов из обращения. Некоторый софт напрочь отказывается им доверять, не оставляя возможность пользователям это исправить. Вместо того, чтобы бороться с софтом, я предлагаю вам настроить всем известные сертификаты от let’s encrypt. К тому же сделать это относительно просто.
Создать тестовый SSL сервер.
Команда OpenSSL s_server реализует общий SSL/TLS-сервер. Она должна использоваться только для целей тестирования. В приведенном ниже примере данный сервер прослушивает соединения на порту 8080 и возвращает отформатированную HTML страницу статуса, который включает много информации о ciphers:
$ openssl s_server -key key.pem -cert cert.pem -accept 8080 -www
Конвертирование сертификатов с DER в PEM формат.
# openssl x509 -inform der -in LN.der -out LN.pem
Как правило, при покупке SSL сертификатов, его отдают вам в формате .der и если вам нужно использовать его в веб-сервере или .pem формате, вы можете использовать команду выше, чтобы преобразовать такие сертификаты.
Конвертирование сертификатов с PEM в DER формат.
В случае, если вам необходимо изменить .pem формат в .der:
# openssl x509 -outform der -in linux-notes.pem -out linux-notes.der
Конвертирование сертификата и приватного ключа в PKCS#12 фотмат.
# openssl pkcs12 –export –out sslcert.pfx –inkey key.pem –in sslcert.pem
Если вам необходимо использовать сертификат с приложением Java или с любым другим, кто принимает формат PKCS# 12.
Совет: Вы можете включить «chain certificate» используя «-chain» опцию:
# openssl pkcs12 -export -out my_cert.pfx -inkey my_key.pem -in your_cert.pem -chain the_cert.pem
Создание CSR используя приватный ключ (private key).
# openssl req -out some_cert.csr -key exists.key -new
Если вы не хотите создать новый секретный ключ, а хотите используя вместо существующего, вы можете с предыдущей командой.
Проверьте содержимое сертификата в PKCS12 формате.
# openssl pkcs12 -info -nodes -in my_certificate.p12
PKCS12 — это двоичный формат, так что вы не сможете просматривать содержимое в блокноте или другом редакторе. Таким образом, вы должны использовать команду что выше, для просмотра содержимого файла формата PKCS12.
Получить SHA-1 отпечаток сертификата или CSR
Чтобы получить отпечаток SHA1 сертификата с использованием OpenSSL, используйте команду, приведенную ниже:
$ openssl dgst -sha1 my_cert.der
Чтобы получить SHA1 отпечаток пальца CSR с использованием OpenSSL, используйте команду, приведенную ниже:
$ openssl dgst -sha1 the_csr.der
Получить MD5 отпечаток сертификата или CSR
Чтобы получить отпечаток MD5 сертификата с использованием OpenSSL, используйте команду, приведенную ниже:
$ openssl dgst -md5 cert.der
Чтобы получить MD5 отпечаток пальца CSR с использованием OpenSSL, используйте команду, приведенную ниже:
$ openssl dgst -md5 my_csr.der
Тестирование SSL сертификата по URL.
# openssl s_client -connect linux-notes.org:443 -showcerts
Я использую это довольно часто для проверки SSL-сертификатов по URL с сервера. Это очень удобно для проверки некоторых деталей протокола, шифров и CERT.
Узнать версию OpenSSL
# openssl version
Поверка PEM сертификата на завершение (Expiration Date).
# openssl x509 -noout -in cert.pem -dates
Пример:
# openssl x509 -noout -in bestflare.pem -dates notBefore=Jul 4 14:02:45 2015 GMT notAfter=Aug 4 09:46:42 2015 GMT
Проверить поддержку SSL версии V2/V3 по URL.
Проверка SSL версии V2:
# openssl s_client -connect linux-notes.org:443 -ssl2
Проверка SSL версии V3:
# openssl s_client -connect linux-notes.org:443 -ssl3
Проверка TLS 1.0:
# openssl s_client -connect linux-notes.org:443 -tls1
Проверка TLS 1.1:
# openssl s_client -connect linux-notes.org:443 -tls1_1
Проверка TLS 1.2:
# openssl s_client -connect linux-notes.org:443 -tls1_2
Какой алгоритм используется в сертификате (проверка).
$ openssl req -noout -text -in mycert.csr | grep 'Signature Algorithm'
Или, используя URL:
openssl s_client -connect linux-notes.org:443 < /dev/null 2>/dev/null | openssl x509 -text -in /dev/stdin | grep "Signature Algorithm"
Получить сертификат по URL
Команда что ниже, сохранит сертификат в файл прямо по URL сайта:
$ echo -n | openssl s_client -connect linux-notes.org:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > pem.cert
Если веб-сервер имеет несколько сертификатов на один IP-адрес, то вам нужно будет сообщить OpenSSL, какой сертификат будет использоваться, пример ниже:
$ echo -n | openssl s_client -connect linux-notes.org:443 -servername linux-notes.org | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > pem.cert
Вот и все, много полезностей и все в одной статье «Примеры использования OpenSSL в Unix/Linux».
Создать csr запрос
И так генерация csr запроса у нас будет для таких платформ:
- Microsoft IIS 7 и выше, так как я не вижу смысла в предыдущих версиях
- Linux платформы (Apache, ModSSL, Nginx)
- Online сервисы
Генерация csr запроса на IIS 7
На хостингах не самый распространенный веб-сервер, открываете консоль управления IIS. Выбираете нужный сайт и выбираете значок «Сертификаты сервера» 
В открывшемся окне, в области действия, вам необходимо нажать «создать запрос сертификата»
Заполняете поля:
- Полное имя > обычно пишут адрес ресурса
- Организация
- Подразделение > можно пропустить
- Город
- Область
- Страна или регион > на латинице ваше обозначение страны
Далее вы должны выбрать длину ключа, ставим 2048 бит
И указываем место сохранения CSR запроса, по сути это будет обычный текстовый файл.
Генерация csr запроса Apache, ModSSL, Nginx
Создание csr запроса в CentOS (Linux или MacOS) осуществляется с помощью утилиты OpenSSL, кто не знает, что это такое, то в нескольких словах, это кроссплатформенное программное решение, которое позволяет работать с технологиями SSL/TLS, позволяет управлять и взаимодействовать с криптографическими ключами. В версии CentOS 7, она уже идет под капотом, но если у вас OpenSSL еще не установлен, то делается это вот такой командой:
yum install openssl
В Debian или Ubuntu, команда будет выглядеть вот так.
apt-get install openssl
Теперь при наличии OpenSS в системе, вы сможете произвести генерацию CSR запроса.
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out ca.csr
У вас будет сгенерированно два файла:
- private.key > это ваш закрытый ключ (приватный), это самый секретный ключ, сообщать и передавать его никому нельзя. Обязательно сделайте резервную копию этого файла, может пригодиться.
- ca.csr > это сам запрос на сертификат, который вы передадите в удостоверяющий центр, для выпуска и подписания вашего сертификата.
Хочу отметить, что полученные файлы вы обнаружите в каталоге, где выполняете команду OpenSSL.
Давайте теперь пробежимся по полям, которые вам нужно будет заполнить, вводите тут максимально корректную информацию, в противном случае можете от этого пострадать.
- Country Name (двухбуквенный код страны) — Так как я живу в России, то пишу RU
- State or Province (Район, Область) — Заполняется на английском, в моем случае Moscow
- Locality (Полное название города) — Moscow
- Organization (Официальное наименование организации) — Pyatilistnik inc. Примечение: При заказе сертификата физическим лицом (актуально для SSL-сертификатов с проверкой домена (DV-Domain Validation), в этом поле необходимо указать полное имя владельца сертификата, а в поле Organizational Unit — название вашей площадки или бренда.
- Organizational Unit (необязательное поле: отдел/департамент) — IT
- Common Name (Имя домена, на который оформляется SSL-сертификат) — pyatilistnik.org
В итоге вот содержимое этих файлов, содержимое ca.csr, нужно передать удостоверяющему центру, для выпуска вашего сертификата.
Генерация csr запроса через онлайн сервисы
Самый удобный способ для начинающих веб-мастеров, так как не требует абсолютно никаких знаний в администрировании серверов. Вы просто открываете онлайн форму и заполняете поля, на выходе вы получите CSR запрос. Я вам предложу два сервиса, которыми пользуюсь. Первый это , о нем я рассказывал в статье про выпуск сертификата на 3 года за 1800 рублей. Заполняем поля и нажимаем сгенерировать. Вам будет создан Certificate Signing Reques запрос, а так же закрытый ключ. Второй сервис делающий csr запрос на сертификат это , вы также заполняете все поля и жмете сгенерировать CSR. Вы итоге вы так же получаете закрытый ключ и сам запрос на сертификат. Его вам позволят сохранить и так же продублируют на почту
Обратите внимание справа есть ссылка на декодер CSR, он позволяет расшифровать эту абракадабру. В специальное поле вбиваем ваш Certificate Signing Reques и жмем декодировать
В итоге вы получаете всю контактную информацию.
Подготовка к выпуску SSL-сертификата
Для выпуска сертификата Certbot проверяет виртуальный хост в конфигурации Apache, это позволяет автоматически выпускать и продлевать SSL. Делает он это путем поиска директивы ServerName, которая должна соответствовать домену, для которого выпускается сертификат.
Если вы не пропустили первый пункт, VirtualHost для вашего домена в /etc/apache2/sites-available/domain.name.conf с директивой ServerName добавлен должным образом.
Если же вы пропустили первый пункт, или у вас уже был создан конфигурационный файл, исправьте его, чтобы ServerName содержал имя вашего домена, после чего сохраните и перезапустите Apache:
$ systemctl restart apache2
На этом подготовка конфигурационных файлов для работы с Certbot заканчивается.
Как добавить корневой сертификат в доверенные в Linux в веб браузеры
Chrome, Chromium, Firefox и созданные на их основе веб браузеры доверяют корневым сертификатам, установленным на уровне системы. То есть вам достаточно добавить в доверенные CA сертификат как это показано в предыдущем разделе.
Причём эти браузеры хотя и используют NSS, они игнорируют общесистемные сертификаты NSS, которые можно добавить в файл /etc/pki/nssdb!
Тем не менее приложения, которые используют NSS (такие как Firefox, Thunderbird, Chromium, Chrome) хранят свои списки доверенных сертификатов в файлах cert9.db. Чтобы добавить свой сертификат в каждый из этих файлов можно использовать скрипт.
Сохранить следующий код в файл CAtoCert9.sh:
#!/bin/bash
certfile="root.cert.pem"
certname="My Root CA"
for certDB in $(find ~/ -name "cert9.db")
do
certdir=$(dirname ${certDB});
certutil -A -n "${certname}" -t "TCu,Cu,Tu" -i ${certfile} -d sql:${certdir}
done
В этом файле измените значение certfile на имя файла вашего сертификата и значение certname на имя вашего сертификата, сохраните и закройте файл.
Затем запустите его следующим образом:
bash ./CAtoCert9.sh
В результате в домашней папке пользователя будут найдены все файлы cert9.db и в каждый из них будет добавлен указанный CA сертификат.
Вы можете добавить CA сертификаты в графическом интерфейсе каждого браузера.
- В настройках Chrome: Конфиденциальность и безопасность → Безопасность → Настроить сертификаты → Центры сертификации
- В настройках Chromium: Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации
Нажмите кнопку «Импорт»:
Выберите файл с сертификатом.
Укажите, какие полномочия вы даёте этому сертификату:
В настройках Firefox: Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:
Нажмите кнопку «Импортировать»:
Выберите файл с сертификатом.
Укажите, какие полномочия вы даёте этому сертификату:
Получаем сертификат от Let’s Encrypt
Итак, я считаю, что вы настроили почтовый сервер по предложенной выше ссылке. Значит, у вас установлен веб сервер Apache, а так же все в порядке с dns записями. Сертификатов мы получим сразу два. Для доменных имен:
- mail.site.ru — имя почтового сервера, этот сертификат будут использовать postfix и apache
- webmail.site.ru — домен для web интерфейса почты, будет использовать веб сервер
Для настройки получения сертификатов let’s encrypt и настройки apache, нам нужно будет установить несколько пакетов. Напоминаю, что речь идет про Centos 8. В других системах настройка будет аналогичной, только имена пакетов могут отличаться.
# dnf install certbot python3-certbot-apache mod_ssl
Пакеты эти живут в репозитории epel, так что если он еще не подключен, подключите.
# dnf install epel-release
Дальше нам нужно добавить 2 виртуальных домена в настройки apache. Для этого создаем 2 конфига в директории /etc/httpd/conf.d/.
1. mail.site.ru.conf
<VirtualHost *:443> ServerName mail.site.ru DocumentRoot /var/www/mail.site.ru/ <Directory /var/www/mail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/mail.site.ru-error.log CustomLog /var/log/httpd/mail.site.ru-access.log combined </VirtualHost> <VirtualHost *:80> ServerName mail.site.ru DocumentRoot /var/www/mail.site.ru/ <Directory /var/www/mail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/mail.site.ru-error.log CustomLog /var/log/httpd/mail.site.ru-access.log combined </VirtualHost>
2. webmail.site.ru.conf
<VirtualHost *:443> ServerName webmail.site.ru DocumentRoot /var/www/webmail.site.ru/ <Directory /var/www/webmail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/webmail.site.ru-error.log CustomLog /var/log/httpd/webmail.site.ru-access.log combined </VirtualHost> <VirtualHost *:80> ServerName webmail.site.ru DocumentRoot /var/www/webmail.site.ru/ <Directory /var/www/webmail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/webmail.site.ru-error.log CustomLog /var/log/httpd/webmail.site.ru-access.log combined </VirtualHost>
По сути конфиги идентичные, только названия доменов разные. Теперь можно проверить конфигурацию apache и перезапустить его.
# apachectl -t # apachectl reload
Если увидите ошибку:
AH00526: Syntax error on line 85 of /etc/httpd/conf.d/ssl.conf: SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or is empty
Просто удалите конфиг /etc/httpd/conf.d/ssl.conf. Он нам не нужен.
Если нет ошибок, то можно запускать certbot и получать сертификаты. Делается это очень просто.
# certbot --apache
Если все прошло без ошибок, то вы увидите в директории /etc/letsencrypt/live две папки с сертификатами для каждого из доменов.
Так же certbot автоматически добавит в конфигурации виртуальных хостов apache несколько дополнительных параметров.
<VirtualHost *:443>
ServerName webmail.site.ru
DocumentRoot /var/www/webmail.site.ru/
<Directory /var/www/webmail.site.ru/>
Options -Indexes +FollowSymLinks
AllowOverride All
</Directory>
ErrorLog /var/log/httpd/webmail.site.ru-error.log
CustomLog /var/log/httpd/webmail.site.ru-access.log combined
SSLCertificateFile /etc/letsencrypt/live/mail.site.ru/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.site.ru/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
<VirtualHost *:80>
ServerName webmail.site.ru
DocumentRoot /var/www/webmail.site.ru/
<Directory /var/www/webmail.site.ru/>
Options -Indexes +FollowSymLinks
AllowOverride All
</Directory>
ErrorLog /var/log/httpd/webmail.site.ru-error.log
CustomLog /var/log/httpd/webmail.site.ru-access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =mail.site.ru
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI}
</VirtualHost>
В этот виртуальный хост установите веб почту, если вам она нужна.
Подготовка конфигурационных файлов
Необходимо создать конфигурационный файл для OpenSSL. Создадим файл , скопируем в него следующее содержимое root-config.txt.
Раздел является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела :
Раздел содержит ряд значений по умолчанию:
Policy_strict будет применяться для всех подписей корневого центра сертификации, и корневой центр сертификации будет использоваться только для создания промежуточных центров сертификации.
Применим для всех подписей промежуточных центров серфтификации, так как промежуточные центры сертификации это подписывающие серверы, и клиентские сертификаты могут приходить от различных третьих лиц.
Параметры из секции применяются когда создаются сертификаты или запросы на подписывание сертификатов.
Секция определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.
Следующие несколько секций являются расширениями, которые могут применять при подписывании сертификатов. Например, при указании аргумента командной строки -extensions v3_ca будут применены расширения из секции . Эти расширения будут применяться при создании корневого сертификата.
При создании сертификата промежуточного центра сертификации будут применяться расширения из . Параметр указывает, что не может быть никаких дальнейших центров сертификации ниже промежуточного центра сертификации.
Расширение будет применяться при подписывании клиентских сертификатов, таких, которые используются для аутентификации удаленных пользователей.
Расширение будет применяться при подписывании серверных сертификатов, таких, которые используются для веб-серверов.
Расширение будет автоматически применяться при создании списков отзыва сертификатов (CRL — certificate revocation lists).
Расширение будет применяться при подписывании сертификата OCSP (Online Certificate Status Protocol, онлайн протокол статуса сертификатов).
Создание файла цепочки сертификатов
Когда приложение (например, веб-браузер) пытается проверить сертификат, подписанный промежуточным центром сертификации, оно также должно проверить промежуточный сертификат от корневого центра сертификации. Для выполнения проверки цепочки доверия создадим цепочку сертификатов центра сертификации для предоставления приложениям.
Чтобы создать цепочку сертификатов требуется объеденить промежуточные и корневые сертификаты вмете. Позже мы будем использовать этот файл для проверки сертификатов подписанных промежуточным центром сертификации.
Наш файл цепочки сертификатов должен содержать корневой сертификат, потому что клиентские приложения ничего не знают о нем. Лучшим вариантом, особенно, если вы администратор сети, является установка корневого сертификата на каждом клиенте, которому требуется подключаться к приложению.
Подписывание серверного и клиентского сертификатов
Подпишем сертификаты используя наш промежуточный центр сертификации. Эти подписанные сертификаты можно использовать в различных ситуациях, таких как защищать соединения к веб серверу или аутентифицировать клиентов, присоединяющихся к сервису.
Указанные ниже шаги с вашей точки сзрения, где вы выступаете в качестве центра сертификации. Стороннее лицо, однако, вместо этого может создать свой собственный частный ключ и запрос на подпись сертификата (CSR) без раскрытия вам своего частного ключа. Они дают вам собственный CSR, а вы отдаете им подписанный сертификат. В этом случае, пропустите команды genrsa и req.
Как SSL-сертификат помогает защитить данные?
На самом деле схема защиты трафика основана на его шифровании открытым ключом и его расшифровке закрытым ключом. Понятие SSL-сертификата применимо в контексте подтверждения того факта, что открытый ключ действительно принадлежит именно тому домену, с которым происходит соединение. Таким образом, в данной схеме присутствуют две составляющие:
- Пара ключей (открытый и закрытый) — для шифрования/расшифровки трафика;
- Подпись открытого ключа. Гарантирующая, что он подлинный и обслуживает именно тот домен, для которого и был создан.
Обе эти составляющие и представляют собой то, что принято обозначать понятием SSL-сертификат. Подпись является гарантией, поскольку выдаётся авторитетным центрами сертификации. Это доступные всем онлайн-сервисы (достаточно воспользоваться любой поисковой системой), которым можно отправить свой ключ, заполнив соответствующую анкету. Далее сервис (центр сертификации) обрабатывает данные из анкеты и сам ключ и высылает уже подписанный ключ обратно его владельцу
Среди самых популярных на сегодняшний день центров сертификации являются такие как Comodo.
Важно заметить, что зашифрованный открытым ключом трафик возможно расшифровать только соответствующим ему закрытым ключом. В свою очередь подпись для открытого ключа от авторитетного цента говорит, что зашифрованный трафик пришёл от «своего» или подлинного узла и его можно принять в обработку, т
е. расшифровать закрытым ключом.
Создание промежуточного сертификата
Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци ().
Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации ().
Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.
Шаг 4 — Распространение публичного сертификата Центра сертификации
Мы настроили ЦС и можем использовать его в качестве корня доверия для любых систем, которые захотим настроить для этого. Сертификат ЦС можно добавлять на серверы OpenVPN, веб-серверы, почтовые серверы и т. д. Каждый пользователь или сервер, которому потребуется подтвердить подлинность другого пользователя или сервера в вашей сети, должен иметь копию файла , импортированную в хранилище сертификатов операционной системы.
Чтобы импортировать публичный сертификат ЦС во вторую систему Linux, например на сервер или локальный компьютер, нужно предварительно получить копию файла с сервера ЦС. Вы можете использовать команду для ее вывода в терминал, а затем скопировать и вставить ее в файл на втором компьютере, который импортирует сертификат. Также вы можете использовать , и другие подобные инструменты для передачи файла между системами. Мы используем для копирования и вставки текстовый редактор , поскольку этот вариант подойдет для всех систем.
Запустите следующую команду на сервере ЦС от имени пользователя без прав root:
На терминале появится примерно следующее:
Скопируйте все, включая строки и и символы дефиса.
Используйте или предпочитаемый текстовый редактор на второй системе Linux, чтобы открыть файл с именем :
Вставьте в редактор содержимое, скопированное вами из сервера ЦС. После завершения редактирования сохраните и закройте файл. Если вы используете , вы можете сделать это, нажав , а затем и для подтверждения.
Теперь у нас имеется копия файла на второй системе Linux, и мы можем импортировать сертификат в хранилище сертификатов операционной системы.
На системах с Ubuntu и Debian выполните следующие команды в качестве вашего пользователя без прав root для импорта сертификата:
Ubuntu and Debian derived distributions
Чтобы импортировать сертификат сервера ЦС в систему на базе CentOS, Fedora или RedHat, скопируйте и вставьте содержимое файла в файл , как описано в предыдущем примере. Затем скопируйте сертификат в директорию и запустите команду .
CentOS, Fedora, RedHat distributions
Теперь вторая система Linux будет доверять любому сертификату, подписанному нашим сервером ЦС.
Примечание. Если вы используете ЦС с веб-серверами и браузер Firefox, вам нужно будет импортировать публичный сертификат в Firefox напрямую. Firefox не использует локальное хранилище сертификатов операционной системы. Подробную информацию о добавлении сертификата ЦС в Firefox можно найти в статье поддержки Mozilla «Настройка Центров сертификации (ЦС) в Firefox».
Если вы используете ЦС для интеграции со средой Windows или настольными компьютерами, ознакомьтесь с документацией по использованию .
Если вы используете это обучающее руководство для выполнения предварительных требований другого обучающего руководства или уже знакомы с процессом подписания и отзыва сертификатов, вы можете остановиться здесь. Если вы хотите узнать больше о подписании и отзыве сертификатов, в следующем необязательном разделе вы найдете подробное описание каждого из этих процессов.
