Как создать самоподписанный сертификат ssl centos

Обновлено: 04.07.2024

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

Что такое сертификаты?

В этой инструкции мы будем иметь дело с такими видами ключей:

  • .pem, .crt, .cer - готовый, подписанный центром сертификации сертификат, расширения разные, но означают одно и то же. Если совсем просто, то сертификат, это подписанный открытый ключ, плюс немного информации о вашей компании;
  • .key - закрытый или открытый ключ;
  • .csr - запрос на подпись сертификата, в этом файле хранится ваш открытый ключ плюс информация, о компании и домене, которую вы указали.

А теперь рассмотрим как создать сертификат openssl, как его подписать и что для этого нужно сделать. Генерация ключей openssl - это довольно простая задача, если во всем разобраться.

Создание закрытого ключа и запроса на подпись

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

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

openssl req -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

Опция -newkey указывает, что нужно создать новую пару ключей, а в параметрах мы сообщаем тип rsa и сложность 2048 байт. Опция -nodes указывает, что шифровать ключ не нужно, опция -new указывает что нужно создать запрос csr. Если у вас уже есть закрытый ключ, то вы можете создать для него csr запрос такой командой:

openssl req -key domain.key -new -out domain.csr

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

openssl genrsa -des3 -out domain.key 2048

openssl x509 -in domain.crt -signkey domain.key -x509toreq -out domain.csr

Параметр -x509toreq указывает, что нужно использовать сертификат для X509 для получения CSR. X509, это сертификаты, подписанные сами собой. Обычно сертификат подписывается другим сертификатом, а этот был подписан сам собой. Если вы получили сертификат от CA, то этот параметр не нужен.

Подпись сертификатов OpenSSL

Первый способ я рассматривать не буду. Здесь все просто. Либо используете утилиту сервиса, либо заполняете веб форму и получаете готовый сертификат. Второй вариант гораздо интереснее. Мы подпишем наш сертификат сами, ключом, на основе которого он был создан:

openssl x509 -signkey domain.key -in domain.csr -req -days 365 -out domain.crt

С помощью параметра -days мы указываем что сертификат будет действительным в течение 365 дней, то есть в течение года. Вы можете объединить все в одну команду и сразу создать закрытый ключ, csr и подписанный сертификат:

openssl req -newkey rsa:2048 -nodes -keyout domain.key
-x509 -days 365 -out domain.crt

Или создаем самоподписанный сертификат openssl из существующего закрытого ключа без csr:

openssl req -key domain.key -new -x509 -days 365 -out domain.crt

Опция -new говорит, что нужно запросить информацию о csr у пользователя. Чтобы браузер доверял ключу нужно этот же сертификат импортировать в список доверенных. А теперь рассмотрим третий способ выполнить создание сертификата OpenSSL - подписать его с помощью собственного CA, центра сертификации.

Вот вы сейчас думаете что это что-то такое сложное, да? А нет, это обычная папка, в которой лежит защищенный паролем закрытый ключ, с помощью которого мы будем подписывать все другие ключи. А открытая пара этого ключа должна быть добавлена во все браузеры, которые будут ему доверять.

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

Дальше нужно создать самоподписанный сертификат openssl для нашего CA:

openssl req -newkey rsa:4096 -x509 -extensions x509_ca -keyout /etc/ca/certs/ca.key -out /etc/ca/certs/ca.crt -days 3654

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

openssl ca -extensions x509_client -in

Готово, теперь наш сертификат подписан. Но теперь, чтобы браузеры ему доверяли нужно добавить сертификат CA в список доверенных браузера.

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

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

openssl req -text -noout -verify -in domain.csr

Смотрим содержимое сертификата в режиме обычного текста:

openssl x509 -text -noout -in domain.crt

Проверяем действительно ли сертификат подписан нужным CA:

openssl verify -verbose -CAfile ca.crt domain.crt

Просмотр закрытого ключа:

openssl rsa -check -in domain.key

Чтобы проверить связаны ли между собой закрытый ключ, сертификат и открытый ключ можно подсчитать сумы md5 для этих ключей, если значения совпадут, то есть вероятность что это ключи из одной пары:

openssl rsa -noout -modulus -in domain.key | openssl md5
$ openssl x509 -noout -modulus -in domain.crt | openssl md5
$ openssl req -noout -modulus -in domain.csr | openssl md5

Выводы

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

SSL-сер­ти­фи­кат – это спо­соб шиф­ро­ва­ния инфор­ма­ции сай­та с целью создать более защи­щен­ное соеди­не­ние. Кро­ме того, такой сер­ти­фи­кат может предо­ста­вить посе­ти­те­лям сай­та иден­ти­фи­ка­ци­он­ную инфор­ма­цию вир­ту­аль­но­го сер­ве­ра. SSL-сер­ти­фи­кат мож­но полу­чить в цен­тре сер­ти­фи­ка­ции (ЦС); тем не менее, суще­ству­ют и само­сто­я­тель­но под­пи­сан­ные сер­ти­фи­ка­ты, кото­рые не нуж­да­ют­ся в под­твер­жде­нии сто­рон­ни­ми лицами.

1: Установка mod_ssl

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

2: Создание нового каталога

Далее нуж­но создать новый ката­лог для хра­не­ния клю­ча и сертификата:

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

Созда­вая сер­ти­фи­кат, необ­хо­ди­мо ука­зать срок его дей­ствия; для это­го изме­ни­те зна­че­ние 365 нуж­ным коли­че­ством дней. Без изме­не­ний сле­ду­ю­щая стро­ка создаст сер­ти­фи­кат со сро­ком дей­ствия в 365 дней.

Итак, дан­ная коман­да созда­ет SSL­-сер­ти­фи­кат и закры­тый ключ, кото­рый защи­ща­ет его, а затем раз­ме­ща­ет эти фай­лы в новом каталоге.

Кро­ме того, эта коман­да выве­дет в тер­ми­нал спис­кок полей, кото­рые долж­ны быть заполнены.

Наи­бо­лее важ­ным из них явля­ет­ся поле «Common Name». В нем нуж­но ука­зать офи­ци­аль­ное домен­ное имя (или IP-адрес сай­та, если тако­го име­ни еще нет).

4: Настройка сертификата

Теперь все необ­хо­ди­мые ком­по­нен­ты сер­ти­фи­ка­та гото­вы. Сле­ду­ю­щее, что нуж­но сде­лать, — это настро­ить вир­ту­аль­ные хосты для отоб­ра­же­ния ново­го сертификата.

Открой­те файл ssl.conf:

Най­ди­те раз­дел, кото­рый начи­на­ет­ся с <VirtualHost _default_:443> и отре­дак­ти­руй­те его, как опи­са­но ниже.

Най­ди­те сле­ду­ю­щие три стро­ки и убе­ди­тесь, что они име­ют пра­виль­ные расширения:

Гото­во! Теперь вир­ту­аль­ный хост Apache настро­ен долж­ным обра­зом. Сохра­ни­те все вне­сен­ные изме­не­ния и закрой­те файл.

Так же необ­хо­ди­мо добавить:

NameVirtualHost *:443
в вир­ту­ал­хост домена,
данные:
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
так же мож­но доба­вить в вир­ту­ал­хост домена

5: Перезапуск Apache

На дан­ном эта­пе сер­ти­фи­кат пол­но­стью готов к рабо­те. Оста­лось толь­ко пере­за­пу­стить Apache, что­бы акти­ви­ро­вать вне­сен­ные изменения.

SSL (Secure Socket Layer) и его улучшенная версия TLS (Transport Socket Layer) - это протоколы безопасности, которые используются для защиты веб-трафика, отправляемого из веб-браузера клиента на веб-сервер.

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

Самоподписанный SSL-сертификат, в отличие от других SSL-сертификатов, которые подписаны и которым доверяет центр сертификации (CA), является сертификатом, подписанным лицом, которому он принадлежит.

Его создание совершенно бесплатно, и это дешевый способ шифрования вашего локального веб-сервера. Однако использование самозаверяющего SSL-сертификата в производственной среде крайне не рекомендуется по следующим причинам:

  1. Самозаверяющий сертификат SSL, поскольку он не подписан центром сертификации, генерирует предупреждения в веб-браузерах, предупреждая пользователей о потенциальном риске, если они решат продолжить. Эти предупреждения являются нежелательными и будут отговаривать пользователей от посещения вашего веб-сайта, что может привести к снижению веб-трафика. В качестве обходного пути к этим предупреждениям организации обычно рекомендуют своим сотрудникам просто игнорировать предупреждения и действовать дальше. Это может породить опасную привычку у пользователей, которые могут решить и дальше игнорировать эти предупреждения на других интернет-сайтах, что может стать жертвой фишинговых сайтов.
  2. Самозаверяющие сертификаты имеют низкий уровень безопасности, поскольку они реализуют низкоуровневые технологии шифрования и хэши. Таким образом, уровень безопасности может не соответствовать стандартным политикам безопасности.
  3. Кроме того, не поддерживаются функции инфраструктуры открытых ключей (PKI).

Тем не менее, использование самозаверяющего SSL-сертификата - неплохая идея для тестирования сервисов и приложений на локальном компьютере, требующем шифрования TLS/SSL.

В этом руководстве вы узнаете, как установить локальный самозаверяющий сертификат SSL на веб-сервере Apache localhost в серверной системе CentOS 8.

Перед началом работы убедитесь, что у вас есть следующие основные требования:

  1. Экземпляр сервера CentOS 8.
  2. Веб-сервер Apache, установленный на сервере
  3. Имя хоста уже настроено и определено в файле/etc/hosts. В этом руководстве мы собираемся использовать tecmint.local в качестве имени хоста для нашего сервера.

Шаг 1. Установка Mod_SSL на CentOS

1. Для начала вам необходимо убедиться, что веб-сервер Apache установлен и работает.

Вот ожидаемый результат.


Если веб-сервер не запущен, вы можете запустить и включить его при загрузке с помощью команды.


После этого вы можете подтвердить, что Apache запущен и работает.

2. Чтобы включить установку и настройку локального самозаверяющего SSL-сертификата, требуется пакет mod_ssl.

После установки вы можете проверить его установку, запустив.


Также убедитесь, что установлен пакет OpenSSL (OpenSSL устанавливается по умолчанию в CentOS 8).


Шаг 2. Создайте локальный самоподписанный сертификат SSL для Apache

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

В этом примере мы создали каталог в/etc/ssl/private.

Теперь создайте ключ и файл локального сертификата SSL с помощью команды:

Давайте посмотрим, что на самом деле означают некоторые параметры в команде:


Шаг 3. Установите локальный самоподписанный сертификат SSL на Apache

Убедитесь, что между тегами виртуального хоста есть следующие строки.

Сохраните и выйдите из файла. Чтобы изменения вступили в силу, перезапустите Apache с помощью команды:

5. Чтобы внешние пользователи могли получить доступ к вашему серверу, вам необходимо открыть порт 443 через брандмауэр, как показано.

Шаг 3. Тестирование локального самозаверяющего SSL-сертификата на Apache

Так что просмотрите домен или IP-адрес вашего сервера

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


Чтобы перейти на свой веб-сайт, нажмите вкладку «Дополнительно», как показано выше:


Затем добавьте исключение в браузер.


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


Мы надеемся, что теперь вы сможете продолжить, создать и установить самозаверяющий сертификат SSL на веб-сервере Apache localhost в CentOS 8.

TLS (Transport Layer Security) и его предшественник SSL (Secure Socket Layers) – это криптографические протоколы, которые используются для защиты передачи данных в Интернете.

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

Данное руководство поможет создать самоподписанный SSL-сертификат для веб-сервера Nginx на сервере CentOS 7.

Требования

  • Сервер CentOS 7.
  • Пользователь с доступом к sudo (инструкции по созданию такого пользователя – в этой статье).

1: Установка Nginx и настройка брандмауэра

Сначала нужно установить веб-сервер Nginx.

Пакета Nginx нет в официальных репозиториях CentOS. Его можно найти в дополнительном репозитории EPEL (Extra Packages for Enterprise Linux). Добавьте EPEL на сервер, чтобы загрузить пакет веб-сервера.

sudo yum install epel-release

Чтобы установить Nginx, введите:

sudo systemctl start nginx

Убедитесь, что сервис запущен:

Также нужно включить Nginx как сервис:

sudo systemctl enable nginx
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.

Теперь нужно разблокировать в брандмауэре порты 80 и 443.

Примечание: Если на вашем сервере не настроен брандмауэр, вы можете приступать к следующему разделу.

Если вы используете firewalld, введите следующие команды, чтобы открыть порты:

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

sudo iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT

2: Создание SSL-сертификата

Для работы TLS/SSL использует комбинацию открытого сертификата и закрытого ключа. Закрытый ключ хранится на сервере и не разглашается. SSL-сертификат используется открыто, он доступен всем пользователям, запрашивающим контент.

Каталог /etc/ssl/certs, предназначенный для хранения сертификатов, существует на сервере по умолчанию. Создайте каталог для ключей, /etc/ssl/private, и ограничьте доступ к нему.

sudo mkdir /etc/ssl/private
sudo chmod 700 /etc/ssl/private

Чтобы создать самоподписанный сертификат и ключ, запустите команду:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Команда задаст ряд вопросов. Рассмотрим компоненты команды подробнее:

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

Самой важной строкой является Common Name: укажите в ней полное доменное имя сервера (FQDN) или свое имя. Как правило, в эту строку вносят доменное имя, связанное с сервером. В случае если доменного имени нет, внесите в эту строку IP-адрес сервера.

В целом список выглядит примерно так:

Файлы ключа и сертификата будут помещены в каталог /etc/ssl.

При использовании OpenSSL нужно также создать ключи Диффи-Хеллмана, которые необходимы для поддержки PFS (совершенной прямой секретности).

Для этого введите:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Этот процесс займёт несколько минут. Ключи DH будут помещены в /etc/ssl/certs/dhparam.pem.

3: Настройка Nginx для поддержки SSL

Итак, на данном этапе ключ и сертификат готовы. Теперь нужно отредактировать настройки Nginx.

Виртуальный хост для TLS/SSL

Создайте и откройте файл ssl.conf в каталоге /etc/nginx/conf.d.

sudo vi /etc/nginx/conf.d/ssl.conf

Добавьте в файл блок server. По умолчанию соединения TLS/SSL используют порт 443. Укажите этот номер в директиве listen. В server_name укажите доменное имя или IP-адрес сервера (значение директивы должно совпадать с тем, что вы указали ранее в Common Name). Затем добавьте строки ssl_certificate, ssl_certificate_key и ssl_dhparam и укажите в них пути к соответствующим файлам SSL.

Далее нужно определить дополнительные параметры SSL, которые обеспечивают безопасность сайта. Для этого обратимся к рекомендациям Remy van Elst на сайте Cipherli.st. Этот сайт предназначен для распространения простых и надёжных параметров шифрования для популярного программного обеспечения. Больше параметров для Nginx можно найти здесь.

Примечание: Данный список настроек подходит для более новых клиентов. Чтобы получить настройки для других клиентов, перейдите по ссылке Yes, give me a ciphersuite that works with legacy / old software.

Некоторые параметры можно откорректировать. Также нужно добавить DNS распознаватель для восходящего канала запросов (в руководстве для этого используется Google).

Примечание: Поскольку сертификат является самоподписанным, SSL stapling не будет использоваться. Nginx выдаст предупреждение, отключит stapling для данного сертификата и продолжит работу.

Теперь добавьте остальные настройки Nginx. Список дополнительных настроек зависит от потребностей сайта. Просто скопируйте из блока location по умолчанию директивы, которые настраивают document root и включают поддержку страниц ошибок.

Сохраните и закройте файл. Теперь Nginx будет использовать SSL-сертификат для шифрования трафика. В настройках указаны только самые безопасные протоколы и шифры.

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

На данный момент Nginx поддерживает шифрованные (порт 443) и нешифрованные соединения (порт 80). То есть, сайт поддерживает шифрование, но использует его не во всех случаях. Однако из соображений безопасности рекомендуется использовать шифрование на постоянной основе. Особенно это важно при передаче конфиденциальных данных.

К счастью, Nginx позволяет добавить в server-блок порта 80 по умолчанию специальные директивы редиректа. Для этого нужно просто добавить файл в каталог /etc/nginx/default.d.

Создайте новый файл ssl-redirect.conf и откройте его.

sudo vi /etc/nginx/default.d/ssl-redirect.conf

Добавьте в него строку:

Сохраните и закройте файл. Теперь все запросы, направленные на порт 80, будут переадресованы на порт 443, который поддерживает шифрование.

4: Обновление настроек Nginx

Итак, теперь настройки веб-сервера и брандмауэра откорректированы. Перезапустите Nginx, чтобы изменения вступили в силу.

Сначала нужно проверить синтаксис на наличие ошибок.

Если ошибок не обнаружено, команда вернёт:

nginx: [warn] "ssl_stapling" ignored, issuer certificate not found
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Обратите внимание на предупреждение в начале. Как говорилось ранее, веб-сервер будет возвращать предупреждение в случае использования самоподписанного сертификата. Соединения всё рано шифруются правильно.

Если в синтаксисе обнаружены ошибки, исправьте их. Затем перезапустите веб-сервер:

sudo systemctl restart nginx

5: Тестирование настроек

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

Поскольку сертификат был подписан самостоятельно, браузер сообщит о его ненадёжности:

Your connection is not private
Attackers might be trying to steal your information
(for example, passwords,messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID

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

После этого вы получите доступ к своему сайту.

Заключение

Теперь сервер Nginx может шифровать передаваемые данные, что защитит взаимодействие сервера с клиентами и предотвратит перехват трафика злоумышленниками.

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

Читайте также: