Вход на сайт по сертификату как сделать

Защита почты и веб-почты с помощью SSL/TLS-сертификатов

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

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

Соединение между браузером пользователя и веб-почтой, запущенной на веб-сервере. Для простоты мы называем это «защитой веб-почты».
Соединение между почтовым сервером Plesk и агентом передачи почты (MTA) отправителя. Для простоты мы называем это «защитой почтового сервера Plesk».

1 Защита веб-почты

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

Чтобы защитить веб-почту с помощью SSL/TLS-сертификата:

Получите подстановочный SSL/TLS-сертификат или сертификат SAN, который позволяет настроить имя webmail. в SAN. Для этого у вас есть несколько возможностей:
- Получить бесплатный подстановочный сертификат от Let’s Encrypt . Если вы выберете эту опцию, пропустите шаг 2.

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

Купить сертификат в центре сертификации .
Загрузить сертификат, который у вас уже есть .

2 Защита почтового сервера в Plesk

Уточните у своего хостинг-провайдера, защищен ли ваш почтовый сервер Plesk с помощью действительного SSL/TLS-сертификата (а не самоподписанного SSL/TLS-сертификата, который используется для защиты почтового сервера по умолчанию). При использовании такого сертификата соединение между почтовым сервером Plesk и MTA отправителя шифруется, защищая письма, которые вы получаете, от взлома.

Однако в случае, если вы не оплачиваете выделенный сервер, возникает проблема. Каждый раз, когда вы входите в свой почтовый ящик, вы видите предупреждение об использовании ненадежного SSL/TLS-сертификата. Это происходит потому, что почтовый клиент обнаруживает несоответствие между именем домена, к которому привязан сертификат (доменным именем сервера Plesk) и доменным именем почты. В результате большинство почтовых клиентов воспринимают этот сертификат как ненадежный.

Если вы используете почтовый клиент Postfix или Dovecot (в Plesk для Linux) и MailEnable (в Plesk для Windows), вы можете исправить это несоответствие, привязав SSL/TLS-сертификат к вашей почте для домена.

Для других почтовых клиентов (например, qmail или Courier) сейчас нет возможности привязать отдельный SSL/TLS-сертификат к почте для домена. Будет ли соединение с почтовым сервером в этом случае защищено ― зависит от того, как ваш почтовый клиент обрабатывает ненадежные сертификаты:

Почтовый клиент подключается к почтовому серверу по SSL/TLS (даже если отображается предупреждение о том, что сертификат ненадежен). В этом случае соединение между вашей почтой и отправителем зашифровано и пересылаемые письма защищены от взлома.
Почтовый клиент отклоняет соединение с почтовым сервером по SSL/TLS, и вам приходится использовать незашифрованное соединение. В этом случае ваши пересылаемые письма находятся под угрозой взлома. Мы рекомендуем вам сменить почтовый клиент на другой, который разрешает соединения по SSL/TLS, даже если сертификат ненадежен.

Примечание: Есть еще один способ устранить несоответствие сертификатов. Если вы используете почтовый сервер в Plesk, вы можете настроить свой почтовый клиент на использование доменного имени сервера. Например, предположим, что домен сервера ― server.com , а ваш индивидуальный домен ― example.com . Если почтовый сервер защищен с помощью SSL/TLS-сертификата, привязанного к домену server.com , измените доменное имя почтового сервера с mail.example.com на server.com в настройках почтового клиента.

3 Присвоение SSL/TLS-сертификата почте для домена

Если вы используете почтовый клиент Postfix или Dovecot (в Plesk для Linux) или MailEnable (в Plesk для Windows), вы можете защитить почту для домена с помощью индивидуального SSL/TLS-сертификата. Мы рекомендуем вам сделать это, если ваш почтовый клиент показывает предупреждение о том, что SSL/TLS-сертификат, используемый для защиты почтового сервера, не удалось проверить. Как только вы защитите почту для домена отдельным SSL/TLS-сертификатом, почтовый сервер вернет сертификат, защищающий вашу почту, вместо сертификата на уровне сервера, присвоенного вашим хостинг-провайдером. В результате предупреждение больше показываться не будет.

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

Чтобы защитить почту для домена с помощью SSL/TLS-сертификата:

Получите подстановочный SSL/TLS-сертификат или сертификат SAN, который позволяет настроить имя mail. в SAN. Вы можете сделать это следующими способами:
- Получить бесплатный сертификат от Let’s Encrypt .

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

Примечание: Мы рекомендуем вам получить бесплатный подстановочный SSL/TLS-сертификат от Let’s Encrypt, так как с его помощью можно защитить не только почту для домена, но также и веб-почту, и сам домен, и несколько субдоменов (если это необходимо).

Купить сертификат в центре сертификации .
Загрузить сертификат, который у вас уже есть .

Авторизация с помощью сертификата ssl на nginx + Let’s Encrypt

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

В связи с ростом количества корпоративных клиентов, было принято решение дать доступ к учетной системе внешним пользователям. Для самостоятельного оформления заказов и отслеживания их состояний. Реализация была создан web интерфейс с необходимым функционалом и доступом. Тут же стал вопрос безопасности, кроме стандартных пользователь-пароль было решено еще усилить безопасность, для этого применили OpenVPN, но появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.), тут на глаза попались статьи про доступ по ssl сертификату.

Исходные данные:

Сервер с учетной программой + web интерфейс находятся в DMZ;
WEB-server на nginx, на него проброшены порты http(80) и https(443);
На web-server настроен proxy_pass на сервер с учетной программой, доступ только по порту 8080 и только с IP web-server, большего доступа с серверу нет(обычная безопасность);
На сайт для доступа установлен сертификат от Let’s Encrypt.

Переходим к самому процессу создания сертификата пользователя:

Для сертификатов будем использовать каталог «/etc/ssl/crm.example.ru»

Создаём структуру каталогов:

# mkdir /etc/ssl/crm.example.ru # cd /etc/ssl/crm.example.ru # mkdir db # mkdir db/certs # mkdir db/newcerts # touch db/index.txt # echo "01" > db/serial # chmod 700 ./

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

[ ca ] default_ca = CA_CITENAME # Секция по умолчанию для подписи сертификатов [ CA_CITENAME ] droot = /etc/ssl/crm.example.ru # Корневой каталог хранилища dir = $droot/db # Каталог базы хранилища certs = $dir/certs # Каталог сертификатов new_certs_dir = $dir/newcerts # Каталог для новых сертификатов (pem) database = $dir/index.txt # Файл базы сертификатов serial = $dir/serial # Файл серийного номера # Файл доверенного сертификата certificate = $droot/ca.crt # Закрытый ключ доверенного сертификата private_key = $droot/ca.key default_days = 365 # Срок действия нового сертификата (дни) default_crl_days = 7 # Срок действия списка отозванных сертификатов default_md = md5 # Использовать алгоритм MD5 policy = policy_citename # Политика секции [ policy_citename ] countryName = optional # Необязательный параметр stateOrProvinceName = optional # . localityName = optional # . organizationName = optional # . organizationalUnitName = optional # . commonName = supplied # обязательный параметр emailAddress = supplied # . [ req_distinguished_name ] countryName = Название страны (2-буквенный код) countryName_default = RU countryName_min = 2 countryName_max = 2 stateOrProvinceName = Название области (полное название) stateOrProvinceName_default = Tyumen region localityName = Название местности (например, город) localityName_default = Tyumen 0.organizationName = Название организации 0.organizationName_default = EXAMPLE organizationalUnitName = Название организационной единицы (например, отдел) commonName = Ваше имя commonName_max = 64 emailAddress = Email адрес emailAddress_max = 64

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

# openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 \ -subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=crm.example.ru/emailAddress=crm@example.ru" \ -out ca.crt

Либо, если хотите всё вводить вручную.

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

Просмотреть данные закрытого ключа и сертификата вы можете с помощью команд:

# openssl rsa -noout -text -in ca.key (для ключа) # openssl x509 -noout -text -in ca.crt (для сертификата)

Создание клиентского закрытого ключа и запроса на сертификат (CSR):

# openssl req -new -newkey rsa:2048 -nodes -keyout client01.key \ -subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=User example1/emailAddress=user@example1.ru" \ -out client01.csr

Либо, если хотите всё вводить вручную.

#openssl req -new -newkey rsa:2048 -nodes -keyout client01.key -out client01.csr

Заместо User example1 можно указать почту клиента, а за место EXAMPLE компанию клиента, это поможет отслеживать сертификаты.

В результате выполнения команды появятся два файла 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

Подготовка данных для передачи клиенту. Для передачи полученных в результате предыдущих операций файлов клиенту, обычно используется файл в формате PKCS#12. В этот файл упаковывается и защищается паролем вся информация необходимая клиенту для инсталляции сертификата в броузер.

# openssl pkcs12 -export -in client01.crt -inkey client01.key \ -certfile ca.crt -out client01.p12 -passout pass:123ewqasdcxz

Выставляем права доступа на ключи.

# chmod 600 /etc/ssl/crm.example.ru/client*.crt # chmod 600 /etc/ssl/crm.example.ru/client*.key

Переместим все созданные файлы в каталог db/certs на хранение.

# mv ./client01.* db/certs/

В nginx надо установить:

 ssl_client_certificate /etc/ssl/crm.example.ru/ca.crt; ssl_verify_client on; ssl_verify_depth 1;

Для того чтобы клиент смог подключиться по сертификату ему необходимо отправить файл client01.p12 и ca.crt, а так же сообщить пароль для установки сертификата. ca.crt необходим, так как мы не используем его для сертификации сервера, для этомо используеться Let’s Encrypt.

Процесс выдачи сертификатов можно автоматизировать, написать просто скрипт не составит труда. У нас таких клиентов не много, около 15, так что вбить всё руками не составило проблем.

Мой рабочий пример:

Окно выбора сертификата:

Работоспособность Let’s Encrypt:

В подготовке материала помогли статьи:

P.S. Проверка проводилась на Google Chrome.

Как сделать сертификат для входа на сайт?

В частности интересует WordPress. Т.е. интересует примерно такая же схема, как на «госзакупках» — нет сертификата, значит не зайдешь. Направьте на путь, подскажите, куда копать.

Вопрос задан более трёх лет назад
3268 просмотров

Комментировать

Решения вопроса 0

Ответы на вопрос 2

☺Нужен VPS? Два месяца бесплатно. Смотри профиль☺

Апач позволяет настроить авторизацию по сертификатам, wordpress здесь не причем, это более низкий уровень.
https://httpd.apache.org/docs/2.2/ssl/ssl_howto.ht.
www.opennet.ru/base/sec/ssl_cert.txt.html

Ответ написан более трёх лет назад

Комментировать

Нравится 1 Комментировать