Приватный ключ ssl что это
Что такое private key (pKey) зачем он нужен и с чем его едят?
Где же находится мой Private Key
Если ваш сертификат уже установлен, выполните следующие действия, чтобы найти файл секретного ключа для этих популярных операционных систем.
Apache
Местоположение вашего личного ключевого файла будет указано в главном файле конфигурации Apache, который называется httpd.conf или apache2.conf. Директива SSLCertificateKeyFile укажет путь на вашем сервере, где хранится ваш ключ.
Nginx
Вы сможете найти местоположение секретного ключа в файле виртуальных хостов вашего сайта. Перейдите к серверному блоку для этого сайта (по умолчанию в каталоге /var/www/). Откройте основной файл конфигурации для сайта и найдите директиву ssl_certificate_key которая предоставит вам путь к файлу для частного ключа (некоторые пользователи имеют отдельный файл конфигурации для своего SSL, например ssl.conf).
Windows (IIS)
На серверах Windows ОС управляет вашими файлами сертификатов для вас в скрытой папке, но вы можете получить закрытый ключ, экспортировав файл «.pfx», содержащий сертификаты и закрытый ключ. Подробнее процедура трансфера описана в разделе Экпорт-Ипорт сертификатов
Где еще может быть мой приватный ключ?
Если вы работаете с сервером, который обеспечивает рабочие соединения HTTPS, то ключ находится где-то на этом сервере или доступен для этого сервера на другом сервере, в противном случае протокол HTTPS работать не будет. Возможно, ваша организация использует специальную настраиваемую конфигурацию. Вы можете попробовать выполнить поиск на вашем сервере файла «.key» или выполнить шаги, по установке нового сертификат, которые должны указать где сохранить частного ключ. На некоторых платформах OpenSSL сохранит файл .key в том же каталоге, откуда была запущена команда -req
Частный, секретный, приватный ключ является «ключевым ключом», который расшифровывает зашифрованные данные, отправленные на сервер во время сеанса SSL. Если секретный ключ был скомпрометирован, зашифрованные данные могут быть легко дешифрованы тем, кто получил этот закрытый ключ. Таким образом, жизненно важно, чтобы закрытый ключ оставался защищенным на сервере в любое время. Открытый ключа встроена в файл CSR и отправляется в компанию CA. При одобрении и выдаче сертификата SSL компания Центр сертификации в цифровом виде подписывает открытый ключ и отправляет его вам для установки на сервер в соответствии с вашим закрытым ключом.
Как найти или восстановить секретный ключ SSL сертификата в среде IIS MicroSoft?
SSL-сертификат установлен, но отсутствует закрытый ключ. Каковы шаги по восстановлению секретного ключа сертификата SSL в среде Microsoft Internet Information Services (IIS)? Сертификаты SSL не включают закрытый ключ. Закрытый ключ находится на сервере, который сгенерировал запрос подписи сертификата (CSR). При правильной установке сертификат сервера будет соответствовать закрытому ключу, как показано ниже.
Решение: Чтобы восстановить закрытый ключ, выполните следующие действия.
Если Windows смог восстановить закрытый ключ, вы увидите следующее сообщение:
Выпуск SSL-сертификата
Содержание
Приватный ключ
Приватный ключ является самым важным элементом при выпуске сертификата.
Если приватный ключ скомпрометирован, то это несёт угрозу информационной безопасности. При попадании приватного ключа к злоумышленнику ни о какой надёжной передачи данных речи быть не может, т.к. злоумышленник может расшифровать трафик этим ключём.
Если приватный ключ потерян или повреждён, то работа web-сервера будет не возможна, т.к. не получится зашифровать / расшифровать передаваемый трафик. Так же при утере или повреждении приватного ключа мы не сможем сменить или перевыпустить сертификат, т.к. на основе приватного ключа генерируется CSR-запрос в центр сертификации.
Для того, чтобы избежать риска компрометации приватного ключа его можно создать зашифрованным. При создании ключа с шифрованием будет запрошен пароль. Этот пароль впоследствии всегда будет запрашиваться при доступе к ключу. В том числе и при запуске web-сервера, чтении информации о сертификате. Мы будем использовать ключ без шифрования. Для создания такого ключа необходимо выполнить следующую команду:
CSR-запрос
Сертификат
Теперь мы можем выпускать сертификат. Для этого есть 2 пути:
Удостоверяющим центром может быть один из популярных сервисов: VeriSign, Thawte, Comodo, StartSSL и другие.
Так же вы сами можете создать свой центр сертификации и выпускать (подписывать) свои сертификаты.
Настройка web-сервера
Большое количество ценной информации по настройке и безопасности можно найти в статье Security/Server Side TLS.
Для работы Forward Secrecy на основе алгоритма Diffie-Hellman (DHE) необходимо сгенерировать файл dhparam.pem командой:
Если ваш сертификат подписан промежуточным (intermediate) сертификатом, вам необходимо указать web-серверу всю цепочку сертификатов, иначе сертификат будет выдавать ошибку. Обычно удостоверяющий центр прямо говорит об этом и предлагает скачать сертификаты всей цепочки.
Настройка Apache
Настройка Nginx
Для удобства общие для всех доменов настройки вынесены в отдельный файл ssl.conf :
Если вы хотите, чтобы пользователей автоматически перекидывало на HTTPS-протокол, то в настройках сайта укажите:
Настройка сайта для работы по протоколу HTTPS:
Проверить правильность настройки web-сервера и корректность сертификатов можно на ресурсе SSL Server Test
Что такое открытый и закрытый ключ шифрования SSL
Ключ шифрования – криптографический термин. Это секретная информация (набор цифр и букв), которую использует специальный алгоритм для шифрования/ расшифровки сообщений, постановке/ проверке цифровых подписей и т.п. Количество информации в ключе измеряется в битах: чем больше битов в ключе, тем надежней зашифрована информация.
Ключи шифрования бывают:
Асимметричная криптография — более надежная с точки зрения того, что злоумышленники, перехватившие часть трафика, не смогут получить всю информацию, так как для расшифровки им понадобится вторая часть ключа, а она хранится непосредственно у пользователя.
Данные вашего сайта под защитой
Установите SSL-сертификат, и ваш сайт будет работать по безопасному соединению HTTPS
Открытый и закрытый ключ сертификата
Одна из сфер употребления системы асимметричного шифрования — SSL-сертификаты. Подробнее о нем вы можете прочитать в статье Для чего нужен SSL-сертификат. Длина шифра SSL (иными словами, степень его надежности) складывается из длины открытой и закрытой частей ключа:
Размер ключа SSL гарантирует защищенность зашифрованной информации и сохранность передачи данных. Данные шифруются при обращении браузера к серверу с помощью открытого публичного ключа. Закрытый ключ шифрования генерируется при выпуске SSL-сертификата и сообщается только администратору домена. Такое шифрование применяется на этапе расшифровки информации, поступающей от браузера.
Поясним процесс обмена информацией между браузером и сервером по защищенному соединению с помощью наглядного примера, используемого в криптографии.
У нас есть два персонажа: Боб (сервер) и Алиса (браузер пользователя). Боб передает Алисе навесной замок. Открыть этот замок может только Боб, так как ключ есть только у него.
Замок = публичный (открытый) ключ.
Ключ от замка = приватный (закрытый) ключ.
Получив замок, Алиса надевает его на ящик, в котором содержится некая секретная информация, и посылает обратно Бобу. Аналогично, браузер шифрует сообщение публичным ключом и отдает серверу.
Ящик с замком попадет к Бобу, тот откроет замок своим ключом и узнает секретную информацию. Так, сервер расшифровывает сообщение закрытым ключом, который есть только у него.
Основы SSL
SSL — семейство протоколов для установки шифрованного соединения между двумя сторонами, желающими обмениваться данными. Это обмен в процессе которого соединяющиеся стороны договариваются какие механизмы шифрования каждый из них поддерживает, какую длину ключа использовать, режимы шифрования, производится обмен сертификатами, несимметричный алгоритм шифрования используется для обмена ключом симметричного протокола шифрования, который потом используется при дальнейшем взаимодействии. Такой начальный обмен данными называется handshake.
Симметричный ключ генерируется во время handshake и действует только для одной SSL сессии. Если сессия не остается активной, ключ устаревает (expire). Максимальное время после которого SSL сессия устаревает (expire) может быть задано. После устаревания сессии handshake должен быть повторен с начала. Результатом установки сессии является новый симметричный ключ.
Сертификаты и ключи
Прежде чем углубляться в детали SSL, нужно ввести понятие ключей и сертификатов. SSL/TLS используют асимметричное шифрование для аутентификации и для обмена симметричным ключом, который будет использоваться для шифрования данных во время сессии.
Асимметричное шифрование использует пары ключей для шифрования — приватный ключ и соответствующий ему публичный ключ. Данные зашифрованные одним ключом могут быть расшифрованы парным ключом. Аналогично данные подписанные одним ключом, могут быть проверены вторым ключом. Приватный ключ, как предполагает его имя, должен храниться в секрете.
Сертификаты.
Сертификат состоит из публичного ключа, вместе с некоторой идентифицирующей владельца информацией и даты прекращения срока действия ключа. Также сертификат содержит цифровую подпись организации выдавшей сертификат (certificate authority CA). Цифровая подпись гарантирует, что сертификат не подделан. Сертификат обычно выдается веб-серверу, приложению или пользователю. Сертификат является способом распространения публичного ключа шифрования.
Если клиент шифрует сообщение публичным ключом сервера (из сертификата сервера), клиент может быть уверен, что только легальный сервер сможет расшифровать сообщение. В процессе установления SSL/TLS сессии, клиент создает часть сессионного ключа, шифрует сообщение с помощью публичного ключа сервера и передает на сервер. Если сервер тот, за кого себя выдает, он сможет расшифровать сообщение с помощью приватного ключа и достать из сообщения сессионный ключ.
Сертификаты бывают двух типов.
Self-signed сертификаты — сертификаты введенные для тестирования, чтобы разработчики, не дожидаясь получения официально-подписанного сертификата могли тестировать свое программное обеспечение. Self-signed сертификат отличается тем, что подлинность его невозможно проверить, если только вы его не сделали лично или не получили на цифровом носителе из надежного источника. В остальном self-signed сертификаты точно такие, как и официальные. Программно они могут использоваться точно также.
Доверие (Trust)
Ключевым понятием SSL соединения является концепция доверия (trust) сертификату. Важным является способ получения сертификата, используемого для соединения. Если вы получаете сертификат из надежного источника, например лично от владельца сайта, вы можете быть уверенным что сертификат подлинный и вы действительно соединяетесь с настоящим сайтом. Однако при установке соединения из веб-браузера, к примеру, сертификат сервера может получаться с самого сервера, с которым вы устанавливаете соединение. Встает вопрос подлинности сертификата. Что если хакер создал его собственную пару асимметричных ключей и затем сделал собственный сертификат для подделки сервера банка?
Модель доверия, простая. Каждый клиент или сервер решает, что он доверяет определенным организациям (certificate authorities (CA)) выдающим сертификаты. Доверять CA, значит доверять что любые сертификаты выданные CA легальные и что идентифицирующая информация в сертификате корректна и заслуживает доверия. Verisign — пример CA, подписывающий множество сертификатов для больших Internet компаний. Все браузеры верят Verisign по умолчанию. Идентификационная информация сертификата содержит цифровую подпись, сгенерированную CA. Клиент или сервер доверяет CA, добавляя сертификат в файл хранилище, называемый ‘truststore’. Сохранение CA сертификата в truststore позволяет java проверять цифровую подпись сертификата сгенерированную CA и решить доверять сертификату или нет.
Если хакер подкладывает поддельный сертификат для Barclay’s банка, ваш браузер будет пытаться проверить цифровую подпись у сертификата. Эта проверка будет не успешной поскольку в truststore нет сертификата, которым подписан сертификат злоумышленника.
Certificate Chain
На практике формат сертификатов таков, что в сертификат может входить множество подписей. В сертификате хранится не одна подпись а некий «Certificate Chain»
Когда генерируются приватный и публичные ключи, для публичного ключа автоматически генерируется self-signed сертификат. Т.е. изначально вы получаете пару из приватного ключа и сертификата, содержащего подписанный публичный ключ. Self-signed certificate — такой сертификат, в котором создатель ключа и подписывающий является одним лицом.
Позже, после генерации Certificate Signing Request (CSR) и получения ответа от Certification Authority (CA), self-signed (самоподписанный) сертификат заменяется на цепочку сертификатов (Сertificate Chain). В цепочку добавляется сертификат от CA, подтверждающий подлинность публичного ключа, за ним сертификат, подтверждающий подлинность публичного ключа CA.
Во многих случаях, последний сертификат в цепочке (удостоверяющий подлинность публичного ключа CA) сам является самоподписанным. В других случаях, CA в свою очередь, может вернуть не один а цепочку сертификатов. В таком случае, первым в цепочке лежит публичный ключ, подписанный CA который выдал сертификат, а вторым сертификатом может быть сертификат другого CA, подтверждающий подлинность публичного ключа первого CA, которому посылался запрос на подпись. Следом будет идти сертификат, подтверждающий подлинность публичного ключа второго CA, и т.д. до тех пор пока цепочка не закончится самоподписанным корневым root — сертификатом. Каждый сертификат в цепочке подтверждает подлинность публичного ключа предыдущего сертификата в цепочке.
Рассмотрим SSL глубже. Бывает два вида SSL соединений.
Простая аутентификация (1 way SSL authentication)
Перед установкой шифрованного SSL/TLS соединения должна быть выполнена аутентификация. Чтобы простое соединение могло быть установлено, должен быть установлен сервер с закрытым ключом, для которого получен сертификат. Клиент также должен хранить список организаций СА, которым он доверяет.
Клиент проверяет подлинность сервера перед установкой шифрованного соединения.
2 way SSL authentication (двусторонняя аутентификация)
При таком типе аутентификации и сервер, и клиент, оба предоставляют сертификаты для проверки подлинности друг-друга перед установкой шифрованного соединения.
Проверка сертификата
При односторонней аутентификации (первый тип), сервер имеет сертификат с парным приватным ключом. Данные зашифрованные с помощью публичного серверного ключа могут быть расшифрованы с помощью приватного ключа на сервере. Клиент, желающий установить соединение с сервером, проверяет сертификат сервера прежде чем переходить к установке шифрованного соединения. Клиент должен проверить следующее:
Проверяются также другие мелкие детали, такие как алгоритм шифрования цифровой подписи, длины ключа и т.д.
При 2 стороней аутентификации клиент и сервер оба владеют приватными ключами и сертификатами. Оба проверяют сертификаты друг-друга, перед установкой шифрованного соединения. Клиент проделывает проверки описанные выше и сервер выполняет те же действия над клиентским сертификатом.
Запрос подписи и подписывание сертификатов
Создание ключей и сертификатов регламентируется стандартами.
Ключи генерируются в соответствии с PKCS (http://ru.wikipedia.org/wiki/PKCS).
Когда пара состоящая из публичного и приватного ключей сгенерирована, создается объект запроса на сертификат, называющийся Certificate Signing Request (CSR), регламентируемый стандартом PKCS#10. Trusted CA (certificate authority) должен затем решить хочет ли он подписать CSR, доверяет ли он запрашивающему регистрацию клиенту и предоставленной им информации в его сертификате.
Если CA (certificate authority) рещает доверять запросу на подпись сертификата (CSR), результатом становится выпуск подисанного сертификата с идентификационной информацией предоставленной в CSR. Сертификат регламентируется стандартом X.509.
Взято:
https://dev64.wordpress.com/2013/06/12/ssl-basic/
Tags: Основы SSL
javadev.ru
Opensource проект с кодами BitBucket. Желающие могут поучавствовать в его развитии.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Руководство по OpenSSL: SSL-сертификаты, ключи и CSR
В этом руководстве разберемся как с теорией, так и узнаем как работать с сертификатами на практике при помощи утилиты OpenSSL.
Про Linux за 5 минут
Что такое сертификат SSL? Как работает SSL?
Как правило, сертификаты SSL используются на веб-страницах, которые передают и получают конфиденциальные данные конечного пользователя, такие как номер социального страхования, данные кредитной карты, домашний адрес или пароль. Онлайн формы оплаты являются хорошим примером и обычно шифруют вышеупомянутую деликатную информацию с использованием 128 или 256-битной технологии SSL.
Сертификаты SSL обеспечивают идентификацию удаленного компьютера, чаще всего сервера, но также подтверждают идентификацию вашего компьютера с удаленным компьютером для установления безопасного соединения. Обеспечение безопасности в Интернете всегда было улицей с двусторонним движением, и благодаря SSL-шифрованию сервер «пожимает руку» вашему персональному компьютеру, и обе стороны знают, с кем они общаются.
В чем разница между TLS и SSL?
Как я могу узнать, защищена ли веб-страница с помощью SSL?
Зачем мне нужен SSL-сертификат?
Давайте возьмем реальный пример. Допустим являетесь владельцем сайта интернет-магазина, м вы хотите, чтобы ваши посетители чувствовали себя в безопасности при посещении вашего интернет-магазина и, прежде всего, не стеснялись войти в систему и совершить покупку. Сертификат SSL и соединение HTTPS внушают доверие потребителей. Индустрия электронной коммерции тесно связана с доверием потребителей, и мы можем даже сказать, что ваш бизнес зависит от того, насколько ваши клиенты чувствуют себя в безопасности в течение всего процесса покупки.
Помимо очевидных причин безопасности, SSL-сертификат увеличивает SEO вашего сайта и рейтинг в Google, а также повышает доверие клиентов и, следовательно, повышает общий коэффициент конверсии. Если этого недостаточно, чтобы заставить вас задуматься о получении сертификата SSL для вашего домена, Google обязательно убедит вас. А именно, с июля 2018 года Google помечает каждый сайт без SSL как небезопасный.
Где получить сертификат SSL?
Нередко популярные браузеры не доверяют всем сертификатам, выпущенным одним центром сертификации. Например, Google Chrome не доверяет корневым сертификатам Symantec, поскольку Symantec несколько раз нарушала отраслевые политики. Это означает, что все сертификаты, укоренившиеся в Symantec, стали недействительными независимо от даты их действия.
Типы SSL-сертификатов
Убедитесь, что вы выбрали центр сертификации, который поддерживает необходимый вам тип сертификата. Для вашего удобства ниже приведено описание каждого типа сертификата:
Уровни проверки SSL-сертификатов
Центры сертификации имеют различные уровни проверки сертификатов в ответ на растущий спрос на сертификаты. Некоторые организации используют SSL только для шифрования, в то время как другие хотят показать своим клиентам, что они являются доверенной компанией. Различные потребности привели к различным уровням проверки сертификата.
Этот тип сертификата SSL идеально подходит для защиты блогов, приложений социальных сетей и личных веб-сайтов. Центр сертификации не гарантирует идентичность организации, и проверяется только владение доменом.
Центр сертификации проверяет право собственности на домен и проводит тщательное расследование организации, связанной с сертификатом EV. При рассмотрении расширенного запроса проверки соблюдаются строгие правила, и центр сертификации должен проверить следующее:
Как создать сертификат SSL
То, как сгенерировать запрос на подпись сертификата (CSR), зависит исключительно от платформы, которую вы используете, и конкретного выбранного вами инструмента.
Мы будем генерировать CSR с использованием OpenSSL.
Установка OpenSSL в Debian и Ubuntu
Сначала проверим, установлена ли у нас утилита OpenSSL при помощи команды:
Если пакет OpenSSL установлен, мы получим следующий результат:
Если вы не видите такого результата, выполните следующую команду для установки OpenSSL:
Установка OpenSSL в Red Hat и CentOS
Red Hat (версия 7.0 и более поздние) должна поставляться с предустановленной ограниченной версией OpenSSL. Он предлагает только ограниченную поддержку для IDEA, RC5 и MDC2, поэтому вы можете установить недостающие функции.
Чтобы проверить, установлен ли OpenSSL на сервере yum (например, Red Hat или CentOS), выполните следующую команду:
Эта команда должна вернуть следующий результат:
Если ваш формат вывода отличается, это означает, что OpenSSL не установлен на вашем сервере. Выполните следующую команду для установки OpenSSL:
Что такое запрос на подпись сертификата (CSR)?
Обычно вы генерируете пару CSR и ключ локально на сервере, где будет установлен сертификат SSL. Однако это не строгое правило. Вы можете сгенерировать пару CSR и ключ на одном сервере и установить сертификат на другом. Однако это усложняет ситуацию. Мы рассмотрим и этот сценарий.
SSL использует две длинные строки случайно сгенерированных чисел, которые известны как закрытые и открытые ключи. Открытый ключ доступен для публичного домена, так как он является частью вашего SSL-сертификата и сообщается вашему серверу.
Закрытый ключ должен соответствовать CSR, с которым он был создан, и, в конечном счете, он должен соответствовать сертификату, созданному из CSR. Если закрытый ключ отсутствует, это может означать, что сертификат SSL не установлен на том же сервере, который сгенерировал запрос на подпись сертификата.
CSR обычно содержит следующую информацию:
Обратите внимание, что существуют определенные соглашения об именах, которые необходимо учитывать. Название организации и название организационной единицы не должны содержать следующие символы:
Как создать CSR
Целостность сертификата зависит от того, что только вы знаете закрытый ключ. Если вы когда-либо скомпрометированы или утеряны, как можно скорее введите новый сертификат с новым закрытым ключом. Большинство ЦС не взимают плату за эту услугу.
Большинство пар ключей состоят из 2048 битов. Хотя пары ключей длиной 4096 бит более безопасны, они замедляют SSL-рукопожатия и создают нагрузку на серверные процессоры. Из-за этого большинство сайтов по-прежнему используют 2048-битные пары ключей.
Вариант 1: создать CSR
Чтобы создать открытый и закрытый ключ с запросом на подпись сертификата (CSR), выполните следующую команду OpenSSL:
Что эта команда означает:
Далее ваша система должна запустить текстовую анкету для заполнения, которую мы описывали в таблице выше:
Тут будет список всех сертификатов, останется только найти тот, что мы только что сгенерировали.
После того, как вы сгенерировали CSR с парой ключей, сложно увидеть, какую информацию она содержит, поскольку она не будет в удобочитаемом формате. Вы можете легко декодировать CSR на своем сервере, используя следующую команду OpenSSL:
Далее можно декодировать CSR и убедиться, что он содержит правильную информацию о вашей организации, прежде чем он будет отправлен в центр сертификации. В Интернете существует множество CSR-декодеров, которые могут помочь вам сделать то же самое, просто скопировав содержимое файла CSR, например sslshopper.
Вариант 2. Создание CSR для существующего закрытого ключа
Рекомендуется выдавать новый закрытый ключ всякий раз, когда вы генерируете CSR. Если по какой-либо причине вам необходимо сгенерировать запрос на подпись сертификата для существующего закрытого ключа, используйте следующую команду OpenSSL:
Вариант 3. Создание CSR для существующего сертификата и закрытого ключа
Вариант 4: Генерация самоподписанного(self-signed) сертификата
Самозаверяющий сертификат обычно используется для сред тестирования и разработки, а также в интрасети. Давайте создадим самозаверяющий сертификат, используя следующую команду OpenSSL:
Центры сертификации не проверяют самоподписанные сертификаты. Таким образом, они не так безопасны, как проверенные сертификаты. Если ЦС не подписал сертификат, каждый основной браузер отобразит сообщение об ошибке «Ненадежный сертификат», как показано на рисунке ниже.
Вариант 5: Генерация самоподписанного сертификата из существующего закрытого ключа и CSR
Если у вас уже есть CSR и закрытый ключ и вам нужно создать самозаверяющий сертификат, используйте следующую команду:
Как скопировать содержимое файла CSR
Откройте каталог, в котором находится ваш CSR-файл. Введите следующую команду:
Также рекомендуется обновить SSL-сертификат до истечения срока его действия. В противном случае потребуется покупать новый сертификат.
Как проверить свой CSR, SSL-сертификат и ключ
Как мы уже упоминали, было бы разумно проверить информацию, представленную в CSR, прежде чем подавать заявку на сертификат. Используйте следующие команды для проверки вашего запроса на подпись сертификата, SSL-сертификата и ключа:
Эта команда проверит CSR и отобразит данные, указанные в запросе:
Следующая команда проверит ключ и его действительность:
SSL сертификат
Когда вам нужно проверить сертификат, дату его истечения и кто его подписал, используйте следующую команду OpenSSL:
Закрытый ключ
Закрытый ключ кодируется и создается в формате PEM на основе Base-64, который не читается человеком. Вы можете открыть его в любом текстовом редакторе, но все, что вы увидите, это несколько десятков строк, которые кажутся случайными символами, заключенными в открывающие и закрывающие заголовки. Ниже приведен пример закрытого ключа:
В большинстве случаев вам не нужно импортировать код закрытого ключа в файловую систему сервера, так как он будет создан в фоновом режиме, пока вы создаете CSR, а затем автоматически сохраняется на сервере. Во время установки SSL-сертификата система извлекает ключ.
Проверьте, совпадают ли сертификат и закрытый ключ
Для проверки вам нужно вывести контрольные суммы md5 и сравнить их. Выполните следующую команду:
Устранение проблем с SSL
Система не извлекает закрытый ключ автоматически
Некоторые системы не автоматизируют процедуру извлечения закрытого ключа. Кроме того, если вам нужно установить существующий сертификат на другом сервере, вы, очевидно, не можете ожидать, что он получит закрытый ключ. Основная сложность здесь заключается в том, как найти точное местоположение ключа. Способ получения ключа зависит от используемой ОС сервера и от того, использовался ли интерфейс командной строки или панель управления веб-хостинга определенного типа для генерации CSR.
Как найти свой ранее установленный закрытый ключ?
Если дело в том, что ваш сертификат уже установлен, выполните следующие действия, которые помогут вам найти свой закрытый ключ в популярных операционных системах.
Nginx
Вы сможете найти местоположение личного ключа вашего сервера в файле виртуального хоста вашего домена.
Apache
Выходные данные будут отображать каталог, который содержит закрытый ключ. Смотрите пример выходных данных ниже:
Windows (IIS)
На серверах, работающих под управлением Windows Internet Information Services, операционная система сохраняет закрытый ключ в скрытой папке, так же как любая обычная ОС Windows хранит важные системные данные.
Теперь у вас есть то, что вам нужно, если вы хотите сохранить резервную копию или установить сертификат на другом сервере Windows.
Как переместить SSL-сертификат с сервера Windows на сервер, отличный от Windows?
Команды OpenSSL для конвертации CSR
Файлы FKCS12 используются для экспорта или импорта сертификатов в Windows IIS.
Конвертировать PKCS12 в PEM CSR
Конвертировать PEM в DER
Конвертировать DER в PEM
Зашифровать незашифрованный закрытый ключ
Следующая команда OpenSSL возьмет незашифрованный закрытый ключ и зашифрует его с помощью определенной вами парольной фразы.
Определите ключевую фразу для шифрования закрытого ключа.
Расшифровать зашифрованный закрытый ключ
Следующая команда OpenSSL возьмет зашифрованный закрытый ключ и расшифрует его.
При появлении запроса введите кодовую фразу для расшифровки закрытого ключа.
Проверить версию OpenSSL
Эта команда отображает версию OpenSSL, и ее параметры, с которыми она была скомпилирована:
Получим примерно такой вывод:
Заключение
Теперь вы знаете, как сгенерировать запрос на подпись сертификата с помощью OpenSSL, а также устранить наиболее распространенные ошибки.
Полезно?
Почему?
😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.
😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.