Adding self trusted SSL certificate for localhost on Ubuntu(NGINX)
The core function of an SSL certificate is to protect server-client communication. In general terms, your data is locked, gets securely transferred over the network and can be unlocked only by the recipient.
The SSL protocol includes two sub protocols: the record protocol and the handshake protocol. The handshake protocol defines how a web client and web server establish an SSL connection, including cryptographic systems whereas record protocol defines how communicating hosts will exchange data using SSL.
Handshake process
1. Server presents its SSL certificate to authenticate itself to the client. Server certificates follow the X.509 certificate format defined by the Public Key Cryptography Standards (PKCS).
2. The authentication process uses public key encryption to validate the digital certificate and to confirm that a server is, in fact, the server it claims to be.
3. Optionally, it also allows the client to authenticate itself to the server. Post server authentication, client must send it’s certificate to server for authentication. Once a client’s identity is authenticated, SSL connection can be established.
4. Your certificate needs to be issued by a valid certificate authority like Amazon, Godaddy etc
Why do we need to secure localhost?
As a developer, you often keep the client and server on same system to speed up your development. Also, in a local testing environment, usually you only work with dummy data. Therefore, the need for securing data in-transit is also not there. In that case the probability of data getting leaked over network is almost zero and hence the need to secure your localhost diminishes. But the need to secure localhost arises when you start using third party API’s. Most of these API’s accept request from SSL connections only.
What’s self trusted certificate?
There are lots of organisations that provide SSL certificate (Amazon, Cloudfare, etc). These organisations validate your domain’s web presence before issuing certificates. But as you are looking for SSL for local domain it’ss not even possible, as it’s a special domain that no one can claim ownership of. In that case you attest the certificates yourself.
How to add SSL certificates for localhost?
This can be divided in three step:
- Generate certificates
- Configuring NGINX to use it
- Adding it to the cert database for browser usage.
Generating Certificates
1. Install OpenSSL
Note: You can choose any OpenSSL tar
2. Create conf for OpenSSL
3. Content for ssl.conf
4. Generate certificates
req is a command that indicates the use of x509.
x509 is a certificate data management command, indicates the creation of a self-signed certificate;
nodes is a command that skips the use of a passphrase;
days 1024 is a term that sets the certificate validity period in days
newkey rsa: 2048 is a command that generates a new private key using the RSA algorithm with a key length of 2048 bits;
keyout localhost.key is the path to place the private key file;
out localhost.crt is the path to place the certificate file;
config openssl.cnf is the path to the configuration file.
Configuring NGINX
- Copy certificate and key to ssl directory
2. NGINX conf
Add the following lines your *.conf file
If you want to redirect all your HTTP request to HTTPS then add the following code in the *.conf file
Check NGINX conf and reload NGINX
Adding certificates to database
Now if you will open your local website, your website will throw error “Your connection is not secure”. Reason being, NGINX is redirecting it to https domain, but the browser thinks that the certificate is not authentic as it was self attested.
We need to add the generated SSL certificate to the database that browser uses. For this we will use “certutil” utility which is part of the libnss3-tools package.
To add certificate to the database, navigate to the directory where localhost.crt is kept and then run the following command.
Now reboot NGINX, close the browser (incognito too) and reopen browser. Restarting of browser is important or else it will not read the update database. While navigating to the your local domain, you can see secure lock over the domain in the url.
Note: This has been tested on Chrome and opera. And it is working fine on these browsers. Firefox will throw error “Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT”. In that case you need to go to settings and add your local domains certificate to exception. Or you can simply click on “Accept Risk and Continue”.
Все об SSL-сертификате: зачем нужен и как установить на свой сайт
Для того, чтобы объяснить, что такое HTTPS, обратимся к истокам.
Большая часть запросов в интернете проходит по протоколу HTTP. Его придумали еще в 90-х годах для передачи текстов с гиперссылками (документы, в которых вшиты ссылки для перехода к другим документам). Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol.
Сайт — это по сути своей документ, который состоит из файлов: текста, картинок, видео и так далее. При помощи HTTP браузер просит сервер отправить данные разного формата для отображения страницы.
Для того, чтобы его открыть, протокол HTTP подходил идеально. За исключением одного «но» — его использование не подразумевает шифрование данных. То есть, пока запрос идет от клиента (вас) к серверу и обратно, к информации о вас и о вашем запросе могут иметь доступ посторонние, например, интернет-провайдер или злоумышленники.
В целях повышения безопасности в интернете компания Netscape Communications в 2000-м году выпустила расширение протокола HTTP — HTTPS (HyperText Transfer Protocol Secure). При использовании HTTPS данные передаются поверх криптографических протоколов SSL или TLS и зашифровываются. Для того, чтобы сайт мог работать по протоколу HTTPS, на домен должен быть выпущен и установлен SSL-сертификат.
Перейдем к понятию SSL/TLS. SSL — это сертификат, который подтверждает подлинность веб-сайта. Аббревиатура переводится как Secure Sockets Layer.
SSL-сертификат подтверждает ваш домен или организации и позволяет установить безопасное соединение. Он содержит индивидуальный ключ вашего домена, с помощью которого информация между сервером и клиентом (вами) зашифровывается.
Протокол SSL был выпущен более 25 лет назад компанией NetScape в нескольких версиях, но ни одна из них не могла полностью обеспечить безопасность данных пользователей. Поэтому в 1999 году компания IEFT создала новую версию сертификата — TLS (Transport Layer Security), которая смогла решить проблемы предшественника. Первые версии протокола сейчас не актуальны, но TLS-соединение 2008 и 2018 года все еще используются в наши дни.
Интересно, что компания IEFT не могла использовать в названии аббревиатуру SSL по юридическим причинам (права на имя принадлежали NetScape), но в обиходе мы до сих пор чаще используем именно название первого протокола.
Правильная настройка работы на вашем сайте SSL-сертификата — это гарантия, что данные между пользователем и веб-сайтом или двумя системами зашифрованы. К таким данным относятся имена, адреса, номера телефонов, номера банковских карт и другая информация. SSL не позволяет сторонним пользователям, в том числе и злоумышленники, воспользоваться ими.
SSL-сертификат позволяет установить TLS-соединение с сервером, которое работает по следующей схеме:
MNorin.com
Блог про Linux, Bash и другие информационные технологии
TLS и SSL: Необходимый минимум знаний
TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.
Что такое SSL и что такое TLS?
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. 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
Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
Корневой сертификат
Чуть выше я упомянул корневой сертификат. Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.
Запрос на подпись (CSR, Certificate Sign Request)
Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.
Клиентский сертификат
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
Цепочка действий по генерации сертификатов
Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.
Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.
Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.
Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.
Просмотр информации о сертификате
Содержимое сертификата можно просмотреть таким образом:
Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.
Серверный сертификат
Для подписи сертификата для сервера нам нужно выполнить следующие действия:
1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно
В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата
Таким образом сертификат сервера подписан и мы будем знать, какой организацией выдан этот сертификат. После подписи готовый сертификат можно использовать по назначению, например, установить на веб-сервер.
Установка SSL/TLS-сертификата на сервер с nginx
Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:
1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private
2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):
3) Перезапустить nginx
4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.
Установка SSL/TLS-сертификата на сервер с Apache
Установка SSL/TLS-сертификата на Apache выглядит примерно так же.
1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории
2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен
3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:
При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:
Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку
Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf
4) Перезапустить веб-сервер Apache
Создание клиентского сертификата
Клиентский сертификат создается примерно так же, как серверный.
Если необходим клиентский сертификат в формате PKCS12, создаем его:
Теперь можно использовать клиентский сертификат для работы с нашим сервером.
Настройка nginx на использование клиентских сертификатов
Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:
После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.
Настройка Apache на использование клиентских сертификатов
Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:
Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.
«Прослушка» информации о сертификате при помощи openssl
Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.
На стороне сервера запускаем прослушку порта при помощи openssl:
На стороне клиента обращаемся к серверу, например, culr’ом:
В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.
Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:
Со стороны сервера ошибка выглядит так:
Со стороны клиента так:
Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):
Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.
Безопасность
При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.
В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.
Как настроить SSL-сертификат на Nginx
Репутация веб-ресурсов во многом зависит от уровня безопасности и уровня защиты персональных данных на сервере. В случае с сайтами речь идет о включении протокола HTTPS, а для этого требуется подключение сертификата SSL.
Сегодня рассмотрим настройку SSL на примере наиболее популярного веб-сервера Nginx. Большинство хостинг-провайдеров поддерживают именно его.
Настройка SSL в Nginx с Let’s Encrypt
Мы будем устанавливать бесплатный сертификат от некоммерческого удостоверяющего центра Let’s Encrypt. Готовый к эксплуатации веб-сервер необходимо подготовить к дальнейшей установке SSL: перед началом процедуры требуется зарегистрировать домен и привязать его к конкретному аккаунту на хостинге. Сертификат выдается на определенное имя сайта.
Шаг 1: Настройка виртуального хоста
Если на веб-сервере еще не настраивался виртуальный хост, это нужно сделать вручную, иначе не получится установить SSL на Nginx. Например, для сайта test.ru конфигурация будет выглядеть так, как показано в нижеследующем примере. Команда просмотра:
Простейшее содержимое выглядит так:
После создания файла рекомендуется проверить конфигурацию веб-сервера командой:
Если никаких ошибок не выдается, следующий шаг – перезагрузка Nginx:
Теперь нужно убедиться, что каталог /var/www/test.ru/public_html/ действительно существует. Если его нет, он создается вручную до последующих действий. В нем следует расположить какой-либо файл для проверки его доступности, например index.html с содержимым «Hi user». Поможет это сделать команда:
Проверяется правильность действий через браузер или утилитой CURL:
Шаг 2: Установка Certbot
Получать сертификаты SSL рекомендуется через клиента Certbot. Он автоматизирует часть работы по настройке протокола HTTPS. Инсталлировать его следует только из официального репозитория, чтобы исключить риски получения на сервер вредоносных программ. Команда для загрузки:
Первый пакет содержит непосредственно саму утилиту, а второй подключает расширение, которое позволяет работать с веб-сервером Nginx. После установки программа сразу готова к применению, поэтому можно продолжать настройку.
Шаг 3: Получение сертификата
Приложение Certbot способно устанавливать сертификат автоматически. Но в нашей инструкции с помощью него будет только сгенерирован ключ, а установка в Nginx проведена вручную. Чтобы создать и подписать SSL нужно ввести команду:
После запуска в первый раз запрашивается email администратора. Туда будут отправляться письма об истечении срока действия сертификата (заодно и новости проекта). После ввода адреса следует согласиться с лицензионным соглашением и ответить на вопрос, допускается ли передача контакта партнерским организациям. После указания нужных реквизитов начнет создаваться SSL-сертификат.
Важно отметить, что сгенерированные файлы сертификата будут сохранены в каталоге /etc/letsencrypt/live/test.ru/. Там располагается следующий перечень модулей:
- cert.pem – непосредственно сам сертификат;
- chain.pem – файл цепочки;
- privkey.pem – приватный ключ, он прописывается в поле ssl_sertificate_key;
- fullchain.pem – совмещенное содержимое первых двух файлов.
Последнее вносится в поле ssl_sertificate. Остается инсталлировать ключ безопасности в систему веб-сервера и проверить подключение нового протокола.
Шаг 4: Настройка виртуального хоста для SSL
С этой целью создается конфигурационный файл виртуального хоста. Он активирует функционал прослушивания порта 443. Также в нем прописывается ряд директив для настройки SSL. Команда для создания:
Примерное содержимое файла:
После сохранения изменений в только что созданном файле требуется перезагрузка веб-сервера командой:
Все, сертификат подключен. Можно приступать к дальнейшим работам по созданию и публикации сайта. Он будет защищен по самым современным стандартам (шифрованием трафика).
Проверить подключение можно при помощи сайта SSLlabs. Нужно открыть браузер и ввести ссылку, в которой следует заменить имя домена на собственное: https://www.test.ru/ssltest/analyze.html?d=test.ru&latest.
Шаг 5: Дополнительная безопасность
По умолчанию в системе остаются включенными все доступные протоколы обмена информацией. Поэтому для увеличения уровня безопасности рекомендуется вручную отключить ряд из них, при этом принудительно активировать наиболее эффективный режим. Здесь понадобится директива ssl_protocols:
В этом примере подключается поддержка протоколов семейства TSL версии 1.2 и 1.3. При высоких требованиях к безопасности рекомендуется активировать все существующие методы шифрования и вручную добавить шифры, которые хочется использовать.
На завершающем этапе остается сообщить серверу, что нужно использовать именно их, а не те, что предлагает клиент:
Перед дальнейшим использованием стоит перезапустить веб-сервер и еще раз убедиться, что все внесенные изменения приняты и SSL-сертификат определяется без ошибок.
Обновление сертификата
Если планируется использовать сертификат SSL от Let’S Encrypt более 90 дней, его придется систематически обновлять. И делать это рекомендуется заранее, минимум за 30 дней до истечения срока действия. Иначе возникают риски временной неработоспособности протокола SSL, когда сайт перестает открываться по прежним ссылкам (браузеры предупреждают об ошибке).
Выполняется процедура обновления командой:
После ее ввода будут проверены все ранее выпущенные и установленные в системе сертификаты и заново созданы те, по которым сроки подходят к концу. Если хочется настроить автоматический перевыпуск SSL, нужно ввести команду cron:
В таком виде она каждый понедельник в 2:30 будет выполнять проверку актуальности всех SSL и записывать результат в файл с указанным названием.