Linux ssl certificate установка

Устанавливаем SSL-сертификат на веб-сервер Apache под Linux

Зачем нужен SSL-сертификат

Secure Sockets Layer — уровень защищённых сокетов. По сути это означает: шифрование, аутентификацию и проверку целостности данных. Без SSL-сертификата:

• веб-сервер может отдавать контент по протоколу https, но браузер будет слева в адресной строке подсвечивать протокол красным и сообщать, что соединение не защищено;
• поисковики Яндекс и Google будут ранжировать ваш сайт ниже конкурентов с валидными SSL-сертификатами;
• страницу вашего сайта смогут за дефейсить хакеры, т.е. открыть сайт, который в доменном имене будет отличаться от вашего на один символ;
• если не включить принудительный редирект на https в настройках веб-сервера, то трафик будет идти по http без шифрования;
• без SSL-сертификата вы не сможете принимать платежи на сайте.

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

Какие бывают SSL-сертификаты и чем они отличаются

• Self-Signed Certificate (cамоподписанный) — бесполезный и бесплатный. Его можно сгенерировать самому и тут нет удостоверяющего центра. Уровень доверия нулевой.
• SGC (Server Gated Cryptography) — сертификат с высоким уровнем шифрования для старых браузеров. Браузеры настолько старые, что смысла в нём нет.
• SAN/UCC (United Communications Certificate) — мультидоменный сертификат для Microsoft Exchange.
• Code Signing — для разработчиков, чтобы подписывать программное обеспечение, чтобы была гарантия, что это оригинальный дистрибутив и никто не внёс туда изменений.
• Wildcard SSL Certificate (и на все поддомены) — на домен и все поддомены. Но это не может быть сертификат с расширенной проверкой организации.
• Domain Validation (DV SSL) — проверка домена — проверяется только то, что вы собственник домена. Подойдёт физическим лицам, у которых на сайте нет передачи данных пользователей, коммерческой деятельности.
• Organization Validation (OV SSL) — проверка организации. В браузере не будет в адресной строке отображаться зелёным цветом сертификат.
• Extended Validation (EV SSL) — с расширенной проверкой организации. Зелёным будет отображаться в адресной строке. Такой сертификат следует приобретать, если ведётся коммерческая деятельность или передаются персональные данные. Есть варианты Multi-Domain, т.е. включить заданный список дополнительных доменов, которые не обязательно должны быть поддоменами.

Цена SSL-сертификатов слабо зависит от его типа, поэтому, если у вас организация, то получайте Extended Validation (EV SSL) сертификат. При покупке SSL-сертификата полезно, чтобы он распространялся и на поддомены, если они у вас, конечно, есть.

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

Установка SSL-сертификата

Итак, вы приобрели сертификат. Теперь его нужно установить к вам на сайт. Здесь мы рассмотрим установку на сайт под управлением веб-сервера Apache.

В браузере вводим адрес нашего сервера и проверяем, что Apache работает и есть сертификат.

Важно учесть

Весь контент на сайте должен отдаваться по https и загружаться тоже по https. Это касается каких-то внешних библиотек, шрифтов, картинок, где есть внешняя ссылка http://. Веб-мастер Яндекса подскажет вам есть ли у вас такой контент. Если есть, то сайт не получит значок Защищённое соединение. Если хотя бы какая-то часть контента страницы подгружается по http://, то вся страница уже не может считаться безопасной.

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

Источник

Генерация и использование SSL-сертификатов в Linux

В целях безопасности, в частности во избежание перехвата конфиденциальных, персональных или важных данных. Многие владельцы сайтов в сети защищают трафик с помощью SSL-сертификатов. Естественно, защите подлежит только тот трафик, который связан непосредственно с запросами и передачей данных с определённым адресом — адресом сайта. Системные администраторы, сотрудники техподдержки должны ориентироваться в вопросах, касающихся создания и внедрения SSL-сертификатов для хостов. Поскольку предоставляют соответствующие услуги. Для этих целей в системах Linux существует утилита openssl. Она является свободной реализацией методов защиты, протокола SSL, а также генерации сертификатов.

Как SSL-сертификат помогает защитить данные?

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

• Пара ключей (открытый и закрытый) — для шифрования/расшифровки трафика;
• Подпись открытого ключа. Гарантирующая, что он подлинный и обслуживает именно тот домен, для которого и был создан.

Обе эти составляющие и представляют собой то, что принято обозначать понятием SSL-сертификат. Подпись является гарантией, поскольку выдаётся авторитетным центрами сертификации. Это доступные всем онлайн-сервисы (достаточно воспользоваться любой поисковой системой), которым можно отправить свой ключ, заполнив соответствующую анкету. Далее сервис (центр сертификации) обрабатывает данные из анкеты и сам ключ и высылает уже подписанный ключ обратно его владельцу. Среди самых популярных на сегодняшний день центров сертификации являются такие как Comodo.
Важно заметить, что зашифрованный открытым ключом трафик возможно расшифровать только соответствующим ему закрытым ключом. В свою очередь подпись для открытого ключа от авторитетного цента говорит, что зашифрованный трафик пришёл от «своего» или подлинного узла и его можно принять в обработку, т. е. расшифровать закрытым ключом.

Общий порядок создания SSL-сертификата, ключи и подпись

Во время создания SSL-сертификата происходит последовательная обработка следующих видов ключей:

• *.key – это сами ключи шифрования, открытий и/или закрытый;
• *.csr – ключ, содержащий сформированный запрос для получения подписи сертификата от центра сертификации, а сам запрос — это открытый ключ и информация о домене и организации, связанной с ним;
• *.crt, *.cer, *.pem – это, собственно, сам сертификат, подписанный центром сертификации по запросу из файла *.csr.

Для начала нужно создать закрытый ключ:

Здесь команда genrsa генерирует RSA-ключ, опция -des3 указывает алгоритм шифрования ключа. А опция -out указывает, что ключ должен быть получен в виде файла server.key. Число 2048 — это сложность шифрования. При выполнении этой команды пользователю будет предложено ввести пароль для шифрования. Поскольку указан его алгоритм опцией -des3. Если это личный ключ и его планируется использовать на сервере, который можно настроить в собственных целях, то естественно шифрование обязательно. Однако, многие серверы требуют закрытые ключи без шифрования (например хостинг-площадки, поскольку предоставляют универсальную услугу по заказу SSL-сертификатов). Поэтому перед генерацией закрытого ключа нужно определиться, как он будет использоваться.

Теперь нужно создать запрос на подпись — CSR-файл, который будет включать только что сгенерированный ключ server.key:

При выполнении этой команды пользователю необходимо ввести информацию о домене и организации. Причём наименование домена следует вводить точно, например, если идентификатор URL сайта https://mycompany.com, то ввести нужно mycompany.com. Для URL-идентификатора www.mycompany.com уже необходим отдельный сертификат.
Теперь файл server.csr со сформированным запросом на подпись можно отправить в выбранный центр сертификации.

Подписание SSL-сертификатов

Получить подписанный сертификат, когда имеется закрытый ключ и запрос на подпись можно несколькими способами: воспользоваться услугой авторитетных центров сертификации, отправив им запрос (CSR-файл) и получив в ответ готовый сертификат *.crt. Либо можно сделать сертификат самоподписанным. Т. е. подписать его тем же ключом, который использовался при создании файла CSR. Для этого следует выполнить команду:

Здесь опция -days указывает количество дней, в течение которых выпускаемый сертификат server.crt будет действителен. В данном случае на протяжении одного года.
Также можно создать самоподписанный сертификат из имеющегося закрытого ключа без использования CSR-файла. Но в этом случае нужно вводить информацию CSR-запроса:

Параметр -x509 задаёт формат генерируемого сертификата. Он является самым распространённым и используется в большинстве случаев. Опция -new позволяет запрашивать информацию для запроса у пользователя.

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

Использование SSL-сертификатов для домена

Для использования сертификата доменом, для которого он был создан, необходимо соответствующим образом настроить виртуальный хост этого домена. Для начала нужно сохранить файлы *.crt и *.key где-нибудь, где доступ к ним может получить только их владелец. Например в

/ssl/certs/ нужно поместить файл server.crt, в

/ssl/private/ — файл server.key. Далее, в конфигурационном файле виртуального хоста нужно определить следующие директивы:

Важно заметить, что для SSL-соединений домена должен быть отдельный конфигурационный файл (или просто отдельная конфигурация в одном файле) виртуального хоста для него. Это необходимо, поскольку обычные HTTP-соединения обрабатываются по порту 80, а HTTPS (SSL) — по 443. Это отдельные конфигурации одного виртуального хоста (хотя это не совсем верное определение). Также для Apache должен быть включен модуль SSL. Типичная конфигурация может выглядеть следующим образом:

Как подключить ssl сертификата в nginx читайте в этой статье.

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Сертификаты

Содержание

Сертификаты

Одной из наиболее распространенных форм криптографии сегодня является криптография на открытых ключах. Криптография на открытых ключах использует открытый (public) и закрытый (secret) ключи. Система выполняет шифрование с использованием открытого ключа. Расшифрована такая информация может быть только с использованием закрытого ключа.

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

Типы сертификатов

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

Продолжая пример с HTTPS, сертификат, подписанный CA, предоставляет два важных свойства в отличие от самоподписанного сертификата:

Браузеры (обычно) автоматически распознают такой сертификат и позволяют устанавливать защищенные соединения без предупреждения пользователя.

Когда CA выпускает подписанный сертификат, он гарантирует идентичность организации, которая предоставляет интернет страницы браузеру.

Процесс получения сертификата из CA довольно прост. Короткий обзор его приведен ниже:

Создайте пару из открытого и закрытого ключей.

Создайте запрос на сертификат на основе открытого ключа. Запрос на сертификат содержит информацию о вашем сервере и управляющей им компании.

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

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

Установите это сертификат на ваш защищенный сервер и настройте соответствующие приложения на его использование.

Создание запроса на подпись сертификата (CSR)

Вне зависимости от того получаете ли вы сертификат от CA или создаете самоподписаный, первым шагом будет создание ключа.

Если сертификат будет использоваться системными сервисами такими, как Apache, Postfix, Dovecot и т.п., уместно создать ключ без пароля. Отсутствие пароля позволяет сервису стартовать с минимальным ручным вмешательством, обычно это предпочтительный вариант запуска сервиса.

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

Для генерации ключей CSR запроса, запустите следующую команду из терминала:

Теперь вы можете ввести вашу кодовую фразу. Для лучшей безопасности рекомендуется использовать не менее восьми символов. Минимальная длина при использовании -des3 — 4 символа. Фраза должна включать цифры и/или знаки препинания и не должно быть словом из словаря. Также не забывайте, что ваша фраза будет чувствительна к регистру.

Повторите ввод для проверки. В случае корректного ввода ключ сервера будет создан и записан в файл server.key.

Теперь создадим небезопасный ключ, без кодовой фразы и поменяем имена ключей:

Небезопасный ключ теперь называется server.key и вы можете использовать его для создания CSR без кодовой фразы.

Для создания CSR выполните следующую команду в терминале:

У вас будет запрошена кодовая фраза (при использовании ключа с паролем — прим. пер.). Если введена корректная фраза, у вас запросят название компании, имя сайта, email и пр. Как только вы введете все эти подробности, будет создан запрос CSR и сохранен в файл server.csr.

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

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

Для создания самоподписанного сертификата, запустите следующую команду в терминале:

Эта команда попросит вас ввести кодовую фразу. Как только вы введете корректную фразу, ваш сертификат будет создан и сохранен в файл server.crt.

Установка сертификата

Вы можете установить файлы ключа server.key и сертификата server.crt (или файл сертификата, выданный вашим CA), запуском следующих команд в терминале:

Теперь просто настройте любое приложение с возможностью использования криптографии на открытых ключах для использования этих файлов ключа и сертификата. Например, Apache может предоставить HTTPS, Dovecot предоставляет IMAPS и POP3S, и т.д.

Центр сертификации

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

1. Сначала создайте каталоги для хранения сертификата CA и необходимых файлов:

2. Центр сертификации требует несколько дополнительных файлов для своей работы; один для хранения последнего серийного номера, использованного CA, другой для записи какие сертификаты были выпущены:

3. Третий файл — это файл настроек CA. Хотя он не строго обязателен, но очень удобен для выпуска множества сертификатов. Отредактируйте /etc/ssl/openssl.cnf, изменив секцию [ CA_default ]:

4. Далее создайте самоподписанный сертификат:

Вам будут заданы вопросы по деталям сертификата.

5. Теперь установим корневой сертификат и ключ:

6. Теперь вы готовы приступить к выпуску сертификатов. Первое, что вам потребуется — запрос на сертификат (CSR). Смотрите детали в разделе Создание запроса на подпись сертификата (CSR). Получив CSR, введите следующую команду для создания сертификата, подписанного нашим центром:

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

7. Теперь у вас должен появиться новый файл /etc/ssl/newcerts/01.pem, с таким же содержанием, что и в предыдущем выводе. Выделите и скопируйте все, начиная со строки ——BEGIN CERTIFICATE—— и до строки ——END CERTIFICATE—— в файл с названием по сетевому имени сервера, где он будет установлен. Например, mail.example.com.crt — вполне хорошее описательное имя.

Последующие сертификаты будут иметь имена 02.pem, 03.pem и т.д.

8. Наконец, скопируйте новый сертификат на компьютер, для которого он выпущен, и настройте соответствующие приложения на его использование. Место по умолчанию для установки сертификатов — каталог /etc/ssl/certs. Это позволяет многим сервисам использовать один и тот же сертификат без чрезмерного усложнения прав доступа к файлу.

Для приложений, которые могут быть настроены на использование сертификата CA, вы можете скопировать файл /etc/ssl/certs/cacert.pem в каталог /etc/ssl/certs/ на каждом сервере.

Ссылки

Для более детальных инструкций по использованию криптографии смотрите SSL Certificates HOWTO на tlpd.org.

Страница Википедии HTTPS содержит больше относительно HTTPS.

Для дополнительной информации по OpenSSL смотрите домашнюю страницу OpenSSL.

Также хорошее глубокое руководство Network Security with OpenSSL от O’Reilly.

Источник