Лекция
Привет, Вы узнаете о том , что такое ssl сертификат, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое ssl сертификат, установка ssl сертификата, настройка https , настоятельно рекомендую прочитать все из категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend) .
Протокол SSL является промышленным стандартом и используется миллионами web-сайтов для обеспечения безопасности транзакций пользователей. Технология SSL поддерживается всеми основными интернет-браузерами и операционными системами, совместимость более 99%.
Для создания защищенного соединения по протоколу SSL между web-сервером и браузером необходим цифровой SSL сертификат, который однозначно идентифицирует отдельных пользователей и серверы.
TLS (англ. Transport Layer Security — безопасность транспортного уровня), как и его предшественник SSL (англ. Secure Sockets Layer — уровень защищенных сокетов) — криптографические протоколы, обеспечивающие защищенную передачу данных между узлами в сети Интернет . TLS и SSL используют асимметричную криптографию для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.
Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).
TLS-протокол основан на спецификации протокола SSL версии 3.0, разработанной компанией Netscape Communications . Сейчас развитием стандарта TLS занимается IETF. Последнее обновление протокола было в RFC 5246 (Август 2008) и RFC 6176 (Март 2011).
SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:
SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года
Принцип работы SSL и TLS, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
В текущей версии протокола доступны следующие алгоритмы:
Алгоритмы могут дополняться в зависимости от версии протокола. До последней версии протокола TLS 1.2 были доступны также следующие алгоритмы симметричного шифрования, но они были убраны как небезопасные: RC2, IDEA, DES.
Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.
Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
генерируеся клиентом вместе с запросом на получение открытого ключа. Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. Данный сертификат никому не раскрывается.
У этих сертификатов есть дополнительные опции:
SSL сертификаты с проверкой домена не содержат информации о названии компании — в них указано лишь доменное имя, на которое выдан сертификат. Сертификат такого вида может приобрести как юридическое, так и физическое лицо.
Для такого сертификата есть как платный вариант его получения, так и бесплатный.
Среди платных сервисов является наиболее известный comodo
Среди бесплатных сервисов -
|
Let's Encrypt - это некоммерческий центр сертификации (certificate authority, CA), который выпускает SSL-сертификаты бесплатно и создан для того, чтобы большая часть сайтов смогла перейти к работе по шифрованному протоколу (HTTPS).
|
Бесплатные SSL-сертификаты — на 3 года от WoSign https://buy.wosign.com/free/
StartSSL https://www.startssl.com/
и другие
Для сертификата не требуется предоставление каких-либо документов. Оформление происходит в течение одного-двух рабочих дней.
Сертификаты с проверкой компании кроме информации о доменном имени также содержат информацию об организации. Такие сертификаты пользуются большим доверием у пользователей.
Выпуск сертификата обычно осуществляется в течение 4-7 дней. Сертификат может быть выпущен только на юридическое лицо.
Wildcard SSL сертификаты предназначены для защиты неограниченного количества субдоменов одним сертификатом. Сертификат выдается на доменное имя *.domain.com и при этом защищает доменные имена вида www.domain.com, mail.domain.com, something.domain.com и т.д.
Существуют Wildcard SSL сертификаты с проверкой домена и проверкой организации. Сертификат с проверкой домена может также получить физическое лицо.
Сертификаты расширенной проверки имеют самый высокий кредит доверия у клиентов. Когда пользователь находится на сайте с Extended Validation SSL сертификатом, браузер подсвечивает адресную строку зеленым цветом.
Данные сертификаты особенно рекомендуются для использования банкам и другим финансовым организациям.
Сертификаты разработчика (Code Signing) предназначены для подписания программного кода цифровой подписью. Широко используются для подписания ПО, которое распространяется через интернет.
Самозаверенный сертификат — специальный тип сертификата, подписанный самим его субъектом. Технически данный тип ничем не отличается от сертификата, заверенного подписью удостоверяющего центра (УЦ), только вместо передачи на подпись в УЦ пользователь создает свою собственную сигнатуру. Проще говоря, создатель сертификата сам является в данном случае УЦ. Все корневые сертификаты доверенных УЦ являются самозаверенными.
Поскольку самозаверенный сертификат не заверяется удостоверяющим центром, в соответствии с п. 3.3 RFC 2459, такой сертификат невозможно отозвать.
Теоретически, это позволяет осуществить Man-in-The-Middle-атаку, при которой злоумышленник может перехватить сертификат узла-инициатора шифрованного соединения и вместо него отправить узлу назначения свой поддельный, с помощью которого передаваемые данные можно будет дешифровать
При этом, подобным образом скомпрометированный сертификат нельзя будет отозвать, так как он не заверен УЦ.
Чтобы защитить сервер при помощи SSL сертификата нужно пройти несколько шагов:
1) Оформить заказ в системе и провести оплату .
2) Создать CSR запрос.
3) Установить ваш SSL сертификат.
Так же существуют срвисы предоставлящи выдачу , подтверждение и продление сертификатов - бесплатно, напрмиер certbot letscrypt
Как такого продления не существует. Об этом говорит сайт https://intellect.icu . Просто заказывается выпуск нового сертификата с новым сроком дейтвия. и заменяются существующие настройки и сертификаты на сервере на новые.
Сертификат должен быть отозван если:
Отзыв сертификата можно провести в любой момент. Такое требование может прислать как лицо, подавшее заявку на его выпуск, так и субъект, который за него заплатил. Необходимо понимать, что отзыв сертификата не равнозначен возврату расходов.
Отзыв сертификата - досрочное прекращение его действия. Отозванные сертификаты возобновлению не подлежат.
Методы отзыва сертификата:
Блокировкой сертификата является временное прекращение его действительности на срок действия этого сертификата, в течение которого сертификат можно возобновить. В случае, если по истечению срока заявитель не возобновит действию сертификата, он будет анулирован.
Методы блокировки сертификата:
Для возобновления заблокированного сертификата необходимо подать заявление установленного образца в центр сертификации ключей.
Чтобы приобрести SSL сертификат вам необходимо будет сгенерировать CSR (Certificate Signing Request) на вашем сервере. CSR представляет собой кусок зашифрованного текста, содержащий информацию о компании и доменном имени.
В большинстве случаев CSR содержит следующие поля: страна (Country), регион (State/Province), город (Locality/City), организация (Organization), отдел (Organizational Unit) и доменное имя (Common Name). Обратите внимание:
1. Поле "страна" должно содержать код из двух символов, соответствующий стране. Для Украины код "UA", для России "RU", для остальных стран смотрите полный список кодов.
2. Поля "регион" и "город" должны содержать полные названия, например "Kievskaya Oblast", "Kiev".
3. Поле "организация" — полное юридическое название компании или ФИО предпринимателя, если сертификат оформляется на него.
4. Поле "отдел" — отдел организации, который занимается покупкой сертификата, например "IT".
5. "Доменное имя" — полное доменное имя, на которое приобретается сертификат, например "www.ssl.com".
Если вы генерируете CSR для Wildcard SSL сертификата, доменное имя должно быть указано с "*." (например *.ssl.com). Символ звездочки (*) будет означать любую последовательность символов, не содержащих точку.
После создания CSR вы сможете передать нам его в процессе оформления сертификата.
Итак для того, чтобы получить SSL сертификат самое первое, что нужно сделать, это сформировать специальный запрос на выпуск сертификата, так называемый (Certificate Signing Request). При формировании этого запроса вам будет задан ряд вопросов, для уточнения деталей о вашем домене и вашей компании. После завершения ваш веб сервер создаст 2 типа криптографических ключей — приватный ключ и публичный ключ.
Публичный ключ не является секретным и он помещается в запрос CSR.
Вот пример такого запроса:
-----BEGIN CERTIFICATE REQUEST-----
MIIC3 ...........................................
... ....
Px9x4fm+/xfgjfgjfgjLxJ+EHzQ==
-----END CERTIFICATE REQUEST-----
Данные которые содержатся в этом ключе можно легко проверить с помощью сервисов CSR Decoder.
Как пример:
CSR Decoder 1 https://www.sslshopper.com/csr-decoder.html или
CSR Decoder 2. https://certlogik.com/decoder/
Второй сервис выдает больше информации о CSR и проверяет ее на валидность, поле Signature в результатах проверки.
Если мы вставим такой запрос в форму для его расшифровки, то увидим, какие данные содержатся в публичном ключе.
CSR Information:
Common Name: site.com — доменное имя, которое мы защищаем таким сертификатом
Organization: MyOrg — название организации, которой принадлежит домен
Organization Unit: Hosting department — подразделение организации
Locality: Kiev — город, где находится офис организации
State: Kiev — область или штат
Country: UA — двухбуквенный код, страны офиса.
Email: support@site.com — контактный email технического администратора или службы поддержки
Важный момент — обратите внимание на поле Country — формат этого поля подразумевает только двухбуквенный код по стандарту ISO 3166-1, если вы не уверены в коде вашей страны, то проверить его можно например тут: Таблица ISO-3166-1. Я обращаю внимание на это поле, потому, что самая частая ошибка у наших клиентов при генерации запроса CSR — это неправильный код страны. И как следствие с такой CSR произвести выпуск сертификата невозможно.
После того как CSR сгенерирован вы можете приступать к оформлению заявки на выпуск сертификата. Во время этого процесса центр сертификации (CA — Certification Authority) произведет проверку введенных вами данных, и после успешной проверки выпустит SSL сертификат с вашими данными и даст возможность вам использовать HTTPS. Ваш сервер автоматически сопоставит выпущенный сертификат, со сгенерированным приватным ключем. Это означает, что вы готовы предоставлять зашифрованное и безопасное соединение между вашим сайтом и браузером клиентов.
В сертификате хранится следующая информация:
Это организация, которая обладает правом выдачи цифровых сертификатов. Она производит проверку данных, содержащихся в CSR, перед выдачей сертификата. В самых простых сертификатах проверяется только соотвествие доменного имени, в самых дорогих производится целый ряд проверок самой организации, которая запрашивает сертификат. Об этом мы поговорим ниже.
Так вот, разница между самоподписными бесплатным и платными сертификатами, выданными центром сертификации как раз и заключается в том, что данные в сертификате проверены центром сертификации и при использовании такого сертификата на сайте ваш посетитель никогда не увидит огромную ошибку на весь экран.
Говоря в общем, SSL сертификаты содержат и отображают (как минимум одно из) ваше доменное имя, ваше название организации, ваш адрес, город и страницу. Также сертификат всегда имеет дату окончания и данные о центре сертификации, ответственного за выпуск сертификата. Браузер подключается к защищенному сайту, получает от него SSL сертификат и делает ряд проверок: он не просрочен ли сертификат, потом он проверяет, выпущен ли сертификат известным ему центром сертификации (CA) используется ли сертификат на сайте, для которого он был выпущен.
Если один из этих параметров не проходит проверку, браузер отображает предупреждение посетителю, чтобы уведомить, что этот сайт не использует безопастное соединение SSL. Он предлагает покинуть сайт или продолжить просмотр, но с большой осторожностью. Это последнее, что вы должны увидеть ваши потенциальные клиенты.
Центров сертификации существует достаточно много, вот перечень самых популярных:
Comodo — работает с 1998 штабквартира в Jersey City, New Jersey, США.
Geotrust — основан в 2001, в 2006 продан Verisign, штабквартира Mountain View, California, США
Symantec — бывший Verisign в состав которого входит и Geotrust. Купил всех в 2010 году.
Thawte — основан в 1995, продан Verisign в 1999.
Trustwave — работает с 1995, штабквартира Chicago, Illinois, США.
Как видим самый крупный игрок на рынке SSL сертификатов это Symantec, который владеет тремя крупнейшими центрами сертификации — Thawte, Verisgin и Geotrust.
Основное отличие между разными центрами сертификации — в цене сертификатов и в том, в каком количестве браузеров установлен их корневой сертификат. Ведь если в браузере нет корневного сертификата этого центра сертификации, то посетитель с таким браузером все равно получит ошибку при входе на сайт с сертификатом от такого центра.
Что касается перечисленных выше центров сертификации, то их корневые сертификаты установлены в, пожалуй, 99,99% всех существующих браузеров.
Чтобы проверить, корневые сертификаты каких центров сертификации установлены в вашем браузере, достаточно в настройках вашего браузера найти такую опцию. (В Chrome Настройки -> показать дополнительные настройки -> управление сертификатами -> Доверенные корневые центры сертификации). В Chrome установлено более 50 таких корневых сертификатов.
Важный момент — частенько у клиентов возникала ситуация, когда SSL сертификат на серверe установлен, но при заходе на сайт браузер все равно выдает ошибку. Такая ситуация может возникнуть или из-за отсутствия в файле ca-bundle.crt корневого сертификата центра выдавшего сертификат или из-за того, что корневой сертификат устарел. Корневые сертификаты также имеют свой срок действия (в браузерах они обновляются при обновлении браузера).
С июля 2010 года сертификационные центры перешли на использование ключей 2048bit RSA Keys, поэтому для корректной работы всех новых сертификатов необходимо устанавливать новые корневые сертификаты.
Если новые корневые сертификаты не установлены — это может вызвать проблемы с корректной установкой сертификата и распознаванием его некоторыми из браузеров.
По окончанию процесса покупки, вам будет доступен SSL сертификат. Сам по себе SSL сертификат представляет собой текстовый файл, содержащий зашифрованную информацию, которую ваш сервер сможет расшифровать при установке.
Перед тем как начать установку, сохраните ваш сертификат в отдельный файл и держите его в безопасном месте — это даст вам возможность легко переустановить сертификат в случае сбоя.
В некоторых вам также будет предоставлен корневой сертификат, который необходимо будет установить.
Процесс установки не сложный, но зависит от программного обеспечения сервера, на который сертификат устанавливается. Справа в меню предоставлены инструкции по установке для популярных веб серверов.
1. Скопируйте файлы сертификата на ваш сервер.
2. Найдите файл конфигурации Apache для редактирования.
Обычно такие файлы конфигурации хранятся в /etc/httpd. Основной файл конфигурации в большинстве случаев называется httpd.conf. В некоторых случаях блоки могут находиться в нижней части файла httpd.conf. Иногда вы можете найти блоки отдельно под директорией, например /etc/httpd/vhosts.d/ или /etc/httpd/sites/ или в файле с названием ssl.conf.
Если вы открываете файл в текстовом редакторе, вы должны убедиться в наличии блоков которые содержат настройки Apache.
3. Установите блоки SSL для задания конфигурации.
Если необходимо, чтобы сайт работал и с защищенным соединением и с незащищенным, вам необходим виртуальный хост для каждого соединения. Сделайте копию существующего незащищенного виртуального хоста и создайте его для SSL-соединения как описано в п. 4.
4. Создайте блоки для подключения SSL-соединения.
Ниже приведен очень простой пример виртуального хоста для SSL-соединения. Части, выделенные жирным должны быть добавлены в SSL конфигурацию:
DocumentRoot /var/www/html2
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/root.crt
Поисправляйте имена файлов для согласования с файлами сертификатов:
1. Скопируйте файлы сертификата на сервер.
Скопируйте ваш сертификат (your_domain_name.crt) и корневой сертификат (root.crt), вместе с .key-файлом, который вы генерировали при создании CSR-запроса в директорию на вашем сервере, куда вы собираетесь установить сертификат. Для обеспечения безопасности, сохраняйте файлы с пометкой "только чтение".
2. Соедените сертификат с корневым сертификатом.
Вам необходимо соединить файл сертификата с файлом корневого сертификата в единый .pem файл, выполнив следующую команду:
cat root.crt >> your_domain_name.crt
3. Измените файл виртуального хоста Nginx.
Откройте ваш файл виртуального хоста Nginx для сайта, который вы защищаете. Если вам необходимо, чтобы сайт работал и с защищенным соединением (https), и с незащищенным (http), вам нужен серверный модуль для каждого типа соединения. Сделайте копию существующего серверного модуля для незащищенного соединения и вставьте ниже оригинала. После этого добавьте строчки, который приведены ниже жирным шрифтом:
server {
listen 443;
ssl on;
ssl_certificate /etc/ssl/your_domain_name.crt; (or .pem)
ssl_certificate_key /etc/ssl/your_domain_name.key;
server_name your.domain.com;
access_log /var/log/nginx/nginx.vhost.access.log;
error_log /var/log/nginx/nginx.vhost.error.log;
location / {
root /home/www/public_html/your.domain.com/public/;
index index.html;
}
}
Настройка имен файлов:
Создание клиентского закрытого ключа и запроса на сертификат (CSR).
Для создания подписанного клиентского сертификата предварительно необходимо создать запрос на сертификат, для его последующей подписи.
Аргументы команды полностью аналогичны аргументам использовавшимся при создании самоподписанного доверенного сертификата (см. $1), но
отсутсвует параметр -x509.
# openssl req -new -newkey rsa:1024 -nodes -keyout client01.key \
-subj /C=RU/ST=Msk/L=Msk/O=Inc/OU=Web/CN=usr/emailAddress=usr@dm.ru \
-out client01.csr
В результате выполнения команды появятся два файла client01.key и client01.csr. Просмотреть данные закрытого ключа и запроса на
сертификат (CSR) вы можете с помощью команд:
# openssl rsa -noout -text -in client01.key (для ключа)
# openssl req -noout -text -in client01.csr (для запроса)
Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).
При подписи запроса используются параметры заданные в файле ca.config
# openssl ca -config ca.config -in client01.csr -out client01.crt -batch
Описание аргументов:
ca Подпись запроса с помощью CA.
-config ca.config Использовать конфигурационный файл ca.config.
-in client01.csr CSR находится в файле client01.csr
-out client01.crt Сохранить сертификат в файл client01.crt
-batch Не спрашивать подтверждения подписи.
В результате выполнения команды появится файл клиентского сертификата client01.crt. Просмотреть данные сертификата вы можете с помощью
команды:
# openssl x509 -noout -text -in client01.crt
Подготовка данных для передачи клиенту.
Для передачи полученных в результате предыдущих операций файлов клиенту, обычно используется файл в формате PKCS#12. В этот файл
упаковывается и защищается паролем вся информация необходимая клиенту для инсталяции сертификата в броузер.
# openssl pkcs12 -export -in client01.crt -inkey client01.key \
-certfile ca.crt -out client01.p12 -passout pass:passwwww
Описание аргументов: pkcs12 Работа с файлами формата PKCS#12. -export Экспортирование данных в файл. -in client01.crt Файл клиентского сертификата. -inkey client01.key Файл закрытого ключа. -certfile ca.crt Файл доверенного сертификата. -out client01.p12 Сохранить данные в файл client01.p12. -passout pass:passwwww Установить пароль passwwww на файл (пароль может быть любым, в том числе и пустым) На этом процесс создания клиентского сертификата завершен. Теперь необходимо передать клиенту файл client01.p12 и пароль к нему любым удобным безопасным способом, а также проинструктировать его о процедуре инсталяции сертификата в броузер.
Создадим файлы cert.key и cert.crt, в которых будут храниться секретный ключ и открытый сертификат, основанный на нем. Сертификат будет действителен в течение Хдней; (ключ с опцией -nodes будет нешифрованным).
openssl req -x509 -nodes -days X -newkey rsa:2048 -keyout cert.key -out cert.crt
Х нужно заменить на нужное кол-во дней. После вызова команды надо будет ответить на вопросы о владельце и т.д. На вопрос “Common Name” нужно отвечать именем домена для которого планируется использовать этот сертификат. В результате выполнения команды у вас будет 2 файла: cert.key(с секретным ключом сервера) и cert.crt(с публичным ключом), которые уже можно использовать в конфигах серверов.
Например(файлы сертификата предварительно положены в каталог /etc/ssl/ ):
Nginx
server {
listen 443;
server_name site.ru;
ssl on;
ssl_certificate /etc/ssl/cert.crt;
ssl_certificate_key /etc/ssl/cert.key;
location / {
root /var/www/site.ru;
}
}
Apache
NameVirtualHost *:443
ServerName site.ru
ServerAdmin admin@site.ru
SSLEngine on
SSLCertificateKeyFile /etc/ssl/cert.key
SSLCertificateFile /etc/ssl/cert.crt
DocumentRoot /var/www/site.ru/
Options -Indexes FollowSymLinks -MultiViews
AllowOverride All
Options -Indexes FollowSymLinks -MultiViews
AllowOverride All
Order deny,allow
allow from all
DirectoryIndex index.htm index.php
Можно автоматизировать ввод ответов с помощью опции -subj:
openssl req \ -x509 -nodes -days 365 \ '''-subj '/C=RU/..../CN=имя_домена' \''' -newkey rsa:2048 -keyout cert.key -out cert.crt
Важное замечание, эти сертификаты имеют короткий срок дйствия- 4 месяца , возможно автоматические пробление с подтверждением, так же существуют ограничение по типу выдаваемого суртификата
Проверить что никто не слушает 80 порт
sudo apt-get update
установить apt-get install nginx
если нужно , то удалить и перустановить
sudo apt-get remove nginx* sudo apt-get purge nginx*
add the repository.
если не установлен apt-get install certbot
Регистрацию нужно сделать только один раз:
certbot register --email me@example.com
начала попробуем получить необходимый сертификат в режиме для тестов:
certbot certonly --dry-run -d example.com -d www.example.com
В конце программа должна отчитаться об успешной работе:
The dry run was successful.
Теперь можно смело получать сертификат уже в самом деле. Не забудьте явно указать все необходимые поддомены, такие как www.
Так можно сгенерировать только сертификат certbot certonly -d example.com -d www.example.com
Убедимся что полученный сертификат — именно тот, что нам нужен:
# openssl x509 -text -in /etc/letsencrypt/live/example.com/cert.pem
Certificate:
Signature Algorithm: ...
Validity
Not Before: Jan 3 06:00:00 2022 GMT
Not After : Apr 3 06:00:00 2022 GMT
X509v3 extensions:
...
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com
Или, если подробности вам не нужны:
cat /etc/letsencrypt/live/*/cert.pem | openssl x509 -text |
grep -o 'DNS:[^,]*' | cut -f2 -d:
Команда должна вывести список доменов в сертификате.
Полный рабочий пример конфига:
server {
server_name www.example.com;
listen www.example.com:443 ssl; # default_server;
# выше можно добавить default_server для клиентов без SNI
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.1 8.8.8.8;
# исключим возврат на http-версию сайта
add_header Strict-Transport-Security "max-age=31536000";
# явно "сломаем" все картинки с http://
add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";
# далее все что вы обычно указываете
#location / {
# proxy_pass ...;
#}
}
Так ж существуют плагины которые позволяют не только генерировать . продлевать сертифкаты но и изменять автоматически конфиги вебсрвера для полученных сертифкатов например certbot для nginx
And finally, install sudo certbot renew --dry-run package with apt-get.
/etc/nginx/sites-available/example.com
. . . server_name example.com www.example.com; . . .
nginx -t sudo ufw status sudo systemctl reload nginx sudo certbot --nginx -d example.com -d www.example.com sudo certbot renew --dry-run
Чтобы уставноить сертифкат просто дя нового домена, то запустите certbot
root@user# certbot
Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator nginx, Installer nginx Which names would you like to activate HTTPS for? -------------------------------------------------------------------------------1: intellect.icu - ваш домен которыйимеет сертифкат2: www.intellect.icu - ваш домен который еще не имет сртифкат------------------------------------------------------------------------------- Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel): ___
выберите 2 есили нужен принудитльный редирект (ркоменднутся)
1) При создании соединения например с сервисом Push сообщений возникает ошибка OpenSSL Error messages: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown причина- или сертификат вооще неверный или закончился срок его действия
2) при запуске certbot ошибка
ERROR:certbot.log:The server experienced an internal error :: The service is down for maintenance or had an internal error. Check https://letsen
DEBUG:acme.client:Received response:
HTTP 503
Server: nginx
Content-Type: application/problem+json
Content-Length: 178
Connection: keep-alive
ETag: "5a590733-b2"b'{\n "type": "urn:acme:error:serverInternal",\n "detail": "The service is down for maintenance or had an internal error. Check https://letsencrypt.status.io/ for mor
2019-11-17 21:07:08,312:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/usr/bin/certbot", line 11, in
load_entry_point('certbot==0.23.0', 'console_scripts', 'certbot')()
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1266, in main
return config.func(config, plugins)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1023, in run
le_client = _init_le_client(config, authenticator, installer)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 642, in _init_le_client
return client.Client(config, acc, authenticator, installer, acme=acme)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 230, in __init__
acme = acme_from_config_key(config, self.account.key, self.account.regr)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 46, in acme_from_config_key
return acme_client.BackwardsCompatibleClientV2(net, key, config.server)
File "/usr/lib/python3/dist-packages/acme/client.py", line 718, in __init__
directory = messages.Directory.from_json(net.get(server).json())
File "/usr/lib/python3/dist-packages/acme/client.py", line 1041, in get
self._send_request('GET', url, **kwargs), content_type=content_type)
File "/usr/lib/python3/dist-packages/acme/client.py", line 943, in _check_response
raise messages.Error.from_json(jobj)
acme.messages.Error: urn:acme:error:serverInternal :: The server experienced an internal error :: The service is down for maintenance or had an internal error. Check ht
certbot.log:An unexpected error occurred:
:ERROR:certbot.log:The server experienced an internal error :: The service is down for maintenance or had an internal error. Check https://letsen
зайдите на сайт https://letsencrypt.status.io/
или установите certbot
проверьте статус системы возможно временная неполадка
Service Disruption API UnavailableService Disruption Incident Status Service Disruption Components acme-v01.api.letsencrypt.org (Production), acme-v02.api.letsencrypt.org (Production) Locations High Assurance Datacenter 1, High Assurance Datacenter 218:41 UTC [Identified] We have identified the problem with our production database and expect to restore service within one hour. API прерывания обслуживания недоступен Статус инцидента Нарушение обслуживания [Определено] Мы определили проблему с нашей производственной базой данных и ожидаем восстановить обслуживание в течение одного часа. Места ЦОД 1 с высокой степенью надежности, ЦОД 2 с высокой степенью надежности
Выводы из данной статьи про ssl сертификат указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое ssl сертификат, установка ssl сертификата, настройка https и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)
Термины: Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)