Ssl сертификат клиентский – Клиентский SSL сертификат: для чего используется

Клиентский SSL сертификат: для чего используется

Клиентский SSL сертификат: для чего используется

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

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

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

Как получить клиентский сертификат?

Самый лучший способ получить клиентский сертификат – это воспользоваться приложением OpenSSL.

OpenSSL – популярный инструмент, который активно используется разными компаниями для управления сертификатами: получения самоподписанных сертификатов ЦС (центра сертификации), управления сертификатами сервера, сертификатами пользователя и отозванными сертификатами.

Как происходит авторизация клиентов?

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

Яркий пример такой авторизации – это платежная система WebMoney Transfer с ее клиентом WM Keeper Light. Подобная схема авторизации является очень надежной, поэтому она активно применяется в банковской сфере.

Чтобы реализовать процесс авторизации по клиентским SSL сертификатам, необходимо выполнить следующее:

1. Получить свой собственный доверенный сертификат Certificate Authority, чтобы потом с его помощью подписывать и верифицировать клиентские сертификаты.
2. Создать клиентские сертификаты, которые затем будут передаваться клиентам. Такие сертификаты должны быть подписаны доверенным сертификатом.
3. Настроить сервер, чтобы он должным образом запрашивал и верифицировал клиентские SSL-сертификаты.

Работа с ключами обычно осуществляется при помощи утилиты OpenSSL, про которую мы писали в следующей статье.

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

www.leaderssl.ru

Авторизация клиентов в nginx посредством SSL сертификатов / Habr

Введение:

Поскольку на моём сервере используется nginx, то был установлен модуль SSL
Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.

Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты

Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:

cd /path/to/nginx/config/
mkdir ssl && cd ssl

Шаг 1. Создание собственного самоподписанного доверенного сертификата.

Собственный доверенный сертификат (Certificate Authority или CA) необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.
С помощью приведенной ниже команды создается закрытый ключ и самоподписанный сертификат.

openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500 -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected] -out ca.crt 

Описание аргументов:

req Запрос на создание нового сертификата.
-new Создание запроса на сертификат (Certificate Signing Request – далее CSR).
-newkey rsa:1023 Автоматически будет создан новый закрытый RSA ключ длиной 1024 бита. Длину ключа можете настроить по своему усмотрению.
-nodes Не шифровать закрытый ключ.
-keyout ca.key Закрытый ключ сохранить в файл ca.key.
-x509 Вместо создания CSR (см. опцию -new) создать самоподписанный сертификат.
-days 500 Срок действия сертификата 500 дней. Размер периода действия можете настроить по своему усмотрению. Не рекомендуется вводить маленькие значения, так как этим сертификатом вы будете подписывать клиентские сертификаты.

Шаг 2. Сертификат сервера

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr

Подпишем сертификат нашей же собственной подписью

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
 

Чтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата

openssl rsa -in server.key -out server.nopass.key

Конфиг nginx

listen *:443;
ssl on;
ssl_certificate /path/to/nginx/ssl/server.crt;
ssl_certificate_key /path/to/nginx/ssl/server.nopass.key;
ssl_client_certificate /path/to/nginx/ssl/ca.crt;
ssl_verify_client on;

keepalive_timeout 70;
fastcgi_param SSL_VERIFIED $ssl_client_verify;
fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
fastcgi_param SSL_DN $ssl_client_s_dn;

теперь сервер готов принимать запросы на https.

Однако если вы попытаетесь зайти на сайт, он выдаст ошибку:

400 Bad Request
No required SSL certificate was sent

Что ж, логично, в этом-то и вся соль!

Шаг 3. Создание клиентских сертификатов

3.1 Подготовка CA

Создадим конфиг
nano ca.config

со следующим содержимым:

[ ca ]
default_ca = CA_CLIENT # При подписи сертификатов # использовать секцию CA_CLIENT

[ CA_CLIENT ]
dir = ./db # Каталог для служебных файлов
certs = $dir/certs # Каталог для сертификатов
new_certs_dir = $dir/newcerts # Каталог для новых сертификатов

database = $dir/index.txt # Файл с базой данных подписанных сертификатов
serial = $dir/serial # Файл содержащий серийный номер сертификата (в шестнадцатеричном формате)
certificate = ./ca.crt # Файл сертификата CA
private_key = ./ca.key # Файл закрытого ключа CA

default_days = 365 # Срок действия подписываемого сертификата
default_crl_days = 7 # Срок действия CRL
default_md = md5 # Алгоритм подписи

policy = policy_anything # Название секции с описанием политики в отношении данных сертификата

[ policy_anything ]
countryName = optional # Поля optional - не обязательны, supplied - обязательны
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional  

Далее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле

mkdir db
mkdir db/certs
mkdir db/newcerts
touch db/index.txt
echo "01" > db/serial

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

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

openssl req -new -newkey rsa:1024 -nodes -keyout client01.key -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected] -out client01.csr

В результате выполнения команды появятся два файла client01.key и client01.csr.

3.3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

При подписи запроса используются параметры заданные в файле ca.config

openssl ca -config ca.config -in client01.csr -out client01.crt -batch

В результате выполнения команды появится файл клиентского сертификата client01.crt.

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

3.4. Создание сертификата в формате PKCS#12 для браузера клиента

openssl pkcs12 -export -in client01.crt -inkey client01.key -certfile ca.crt -out client01.p12 -passout pass:q1w2e3

3.5 Подключение к полученному ssl cерверу с помощью curl

curl -k --key client.key --cert client1.crt --url "https://site.com"

Использована опция -k, потому что сертификат в примере самоподписанный

Использованное ПО

Полезные ссылки

Надеюсь, был кому-то полезен.

P.S. Этот пост был моей первой публикацией 16 января 2011 года, старая копия удалена (по желанию администрации сайта и потому, что она не была привязана к моему аккаунту).

habr.com

Цифровые SSL сертификаты. Разновидности, как выбрать? / TutHost corporate blog / Habr

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

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

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

Для того, чтобы активировать возможность работы протокола HTTPS как раз и нужны цифровые SSL сертификаты (также потребуется выделенный IP для конкретного сайта).

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

Как получить SSL сертификат?

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

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

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

По какому принципу работает SSL сертификат?

Публичный ключ не является секретным и он помещается в запрос CSR.
Вот пример такого запроса:
——BEGIN CERTIFICATE REQUEST——
MIIC3zCCAccCAQAwgZkxCzAJBgNVBAYTAlVBMQ0wCwYDVQQIEwRLaWV2MQ0wCwYD
VQQHEwRLaWV2MRQwEgYDVQQKEwtIb3N0QXV0b21hdDEQMA4GA1UECxMHaG9zdGlu
ZzEmMCQGCSqGSIb3DQEJARYXc3VwcG9ydEBob3N0YXV0b21hdC5jb20xHDAaBgNV
BAMTE3d3dy5ob3N0YXV0b21hdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDTg7iUv/iX+SyZl74GcUVFHjFC5IqlTNEzWgLWrsSmxGxlGzXkUKid
NyXWa0O3ayJHOiv1BSX1l672tTqeHxhGuM6F7l5FTRWUyFHUxSU2Kmci6vR6fw5c
cgWOMMNdMg7V5bMOD8tfI74oBkVE7hV95Ds3c594u7kMLvHR+xui2S3z2JJQEwCh
mflIojGnSCO/iv64RL9vjZ5B4jAWJwrruIXO5ILTdis41Z1nNIx3bBqkif0H/G4e
O5WF6fFb7etm8M+d8ebkqEztRAVdhXvTGBZ4Mt2DOV/bV4e/ffmQJxffTYEqWg8w
b465GdAJcLhhiSaHgqRzrprKns7QSGjdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOC
AQEAuCfJKehyjt7N1IDv44dd+V61MIqlDhna0LCXh2uT7R9H8mdlnuk8yevEcCRI
krnWAlA9GT3VkOY3Il4WTGg3wmtq6WAgLkVXQnhIpGDdYAflpAVeMKil8Z46BGIh
KQGngL2PjWdhMVLlRTB/01nVSKSEk2jhO8+7yLOY1MoGIvwAEF4CL1lAjov8U4XG
NfQldSWT1o8z9sDeGsGSf5DAXpcccx0gCyk90HFJxhbm/vTxjJgchUFro/0goVpB
credpKxtkwBMuCzeSyDnkQft0eLtZ9b9Q4+ZNDWsPPKxo/zWHm6Pa/4F4o2QKvPC
Px9x4fm+/xHqkhkR79LxJ+EHzQ==
——END CERTIFICATE REQUEST——

Данные которые содержатся в этом ключе можно легко проверить с помощью сервисов CSR Decoder. Как пример: CSR Decoder 1 или CSR Decoder 2. Второй сервис выдает больше информации о CSR и проверяет ее на валидность, поле Signature в результатах проверки.

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

CSR Information:
Common Name: tuthost.ua — доменное имя, которое мы защищаем таким сертификатом
Organization: TutHost — название организации, которой принадлежит домен
Organization Unit: Hosting department — подразделение организации
Locality: Kiev — город, где находится офис организации
State: Kiev — область или штат
Country: UA — двухбуквенный код, страны офиса.
Email: [email protected] — контактный email технического администратора или службы поддержки

Важный момент — обратите внимание на поле Country — формат этого поля подразумевает только двухбуквенный код по стандарту ISO 3166-1, если вы не уверены в коде вашей страны, то проверить его можно например тут: Таблица ISO-3166-1. Я обращаю внимание на это поле, потому, что самая частая ошибка у наших клиентов при генерации запроса CSR — это неправильный код страны. И как следствие с такой CSR произвести выпуск сертификата невозможно.

После того как CSR сгенерирован вы можете приступать к оформлению заявки на выпуск сертификата. Во время этого процесса центр сертификации (CA — Certification Authority) произведет проверку введенных вами данных, и после успешной проверки выпустит SSL сертификат с вашими данными и даст возможность вам использовать HTTPS. Ваш сервер автоматически сопоставит выпущенный сертификат, со сгенерированным приватным ключем. Это означает, что вы готовы предоставлять зашифрованное и безопасное соединение между вашим сайтом и браузером клиентов.

Какие данные содержит в себе SSL сертификат?

• полное (уникальное) имя владельца сертификата
• открытый ключ владельца
• дата выдачи ssl сертификата
• дата окончания сертификата
• полное (уникальное) имя центра сертификации
• цифровая подпись издателя

Что такое центры сертификации (CA)?

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

Говоря в общем, 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.

Есть ли разница в каком центре сертификации заказывать сертификат?

Чтобы проверить, корневые сертификаты каких центров сертификации установлены в вашем браузере, достаточно в настройках вашего браузера найти такую опцию. (В Chrome Настройки -> показать дополнительные настройки -> управление сертификатами -> Доверенные корневые центры сертификации). В Chrome установлено более 50 таких корневых сертификатов.

Важный момент — частенько у клиентов возникала ситуация, когда SSL сертификат на серверe установлен, но при заходе на сайт браузер все равно выдает ошибку. Такая ситуация может возникнуть или из-за отсутствия в файле ca-bundle.crt корневого сертификата центра выдавшего сертификат или из-за того, что корневой сертификат устарел. Корневые сертификаты также имеют свой срок действия (в браузерах они обновляются при обновлении браузера).

С июля 2010 года сертификационные центры перешли на использование ключей 2048bit RSA Keys, поэтому для корректной работы всех новых сертификатов необходимо устанавливать новые корневые сертификаты.
Если новые корневые сертификаты не установлены — это может вызвать проблемы с корректной установкой сертификата и распознаванием его некоторыми из браузеров.
Ссылки на странички центров сертификации, где можно скачать новые корневые сертификаты даны ниже.

RapidSSL Certificate

Итак мы вплотную подошли к видам SSL сертификатов.

Какие виды SSL сертификатов существуют?

Между собой сертификаты отличаются свойствами и уровнем валидации.

Типы сертификатов по типу валидации

• Сертификаты, которые подтверждают только доменное имя (Domain Validation — DV).
• Сертификаты, которые подтверждают домен и организацию (Organization Validation — OV).
• Сертификаты, с расширенной проверкой (Extendet Validation — EV).

Сертификаты, подтверждающие только домен

Важный момент, что это письмо может быть отправлено только на так называемый approver email, который вы указываете при заказе сертификата. И к адресу approver email есть определенные требования, он должен быть либо в том же домене для которого вы заказываете сертификат, либо он должен быть указан в whois домена.
Если вы указываете email в том же домене, что и сертификат, то указывать любой emal тоже нельзя, он должен соответствовать одному из шаблонов:
admin@
administrator@
hostmaster@
postmaster@
webmaster@

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

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

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

Процесс выдачи сертификатов OV

Что проверяется в таких случаях?

1. Наличие организации в международных желтых страницах — проверяется не всеми центрами сертифации
2. Наличие в whois домена названия вашей организации — а вот это уже проверят обязательно, и если такое название там не указано от вас скорей всего затребуют гарантийное письмо, в котором нужно указать, что домен действительно принадлежит организации, иногда могут затребовать подтверждение от регистратора
3. Свидетельство о государственной регистрации — требуют все реже, чаще сейчас производится проверка через специальные компании, которые производят проверку существования организации по своим каналам. Например для Украины вас могут проверить по базе ЕДРПОУ
4. Счет от телефонной компании, в которой содержится название вашей организации и ваш номер телефона, указанный в заказе — таким образом проверяется валидность вашего телефона. Требуют все реже.
5. Проверочный звонок — все чаще правильность телефона проверяют осуществляя звонок, на номер телефона, указанный вами в заказе. При звонке спросят сотрудника, указанного в административном контакте. Не у всех центров сертификации есть русскоговорящие сотрудники, поэтому предупредите человека, который отвечает на телефон, что возможен звонок от англоязычной компании.

Сертификаты с расширенной проверкой.

Вот как это выглядит на сайте у Thawte.

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

SSL cертификаты с расширенной проверкой (EV) выпускаются только когда центр сертификации (CA) выполняет две проверки, чтобы убедиться, что организация имеет право использовать определенный домен плюс центр сертификации выполняет тщательную проверку самой организации. Процесс выпуска сертификатов EV стандартизирован и должен строго соотвествовать правилам EV, которые были созданы на специализированном форуме CA/Browser Forum в 2007 году. Там указаны необходимые шаги, которые центр сертификации должен выполнить перед выпуском EV сертификата:

1. Должен проверить правовую, физическую и операционную деятельности субъекта.
2. Должен убедиться, что организация соответствует официальным документам.
3. Необходимо убедиться, что организация имеет исключительное право на использование домена, указанного в сертификате EV.
4. Необходимо убедиться, что организация полностью авторизована для выпуска EV сертификата.

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

EV сертификаты используются для всех типов бизнеса, в том числе для государственных и некоммерческих организаций. Для выпуска необходимо 10-14 дней.

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

Типы SSL сертификатов по своим свойствам.

Обычные SSL сертификаты

SGC сертификаты

Wildcard сертификаты

Совет: посчитайте количество поддоменов, на которые нужен сертификат, иногда бывает выгодней купить отдельно несколько обычных сертификатов.
Цена: от 180$ в год. Как видите, если у вас меньше 9 поддоменов, то дешевле купить обычный сертификат, хотя в использовании будет удобней один wildcard.

SAN сертификаты

EV сертификаты

Сертификаты c поддержкой IDN

• Thawte SSL123 Certificate
• Thawte SSL Web Server
• Symantec Secure Site
• Thawte SGC SuperCerts
• Thawte SSL Web Server Wildcard
• Thawte SSL Web Server with EV
• Symantec Secure Site Pro
• Symantec Secure Site with EV
• Symantec Secure Site Pro with EV

Как выбрать самый дешевый сертификат?

Чем еще отличаются сертификаты между собой

• Скоростью выпуска. Быстрее всего выпускаются сертификаты с валидацией только домена, дольше всего с EV валидацией, от 7 рабочих дней.
• Количество перевыпусков сертификата — у большинства центров сертификации неограниченно. Требуется, если допустили ошибку в данных об организации.
• Гарантия — для некоторых сертификатов есть гарантия от 10.000 $. Это гарантия скорее не для покупателя сертификата, а для посетителя сайта, где установлен сертификат. В случае если посетитель сайта с таким сертификатом пострадает от фрауда и потеряет деньги, то центр сертификации обязуется их ему компенсировать до суммы указанной в гарантии. То есть центр сертификации как бы дает гарантию на свои сертификаты и что их невозможно установить на «левый» домен. На практике такие случае мне не известны поэтому на этот параметр можно не обращать внимание.
• Бесплатный тестовый период — из платных сертификатов есть у symantec secure site, geotrust rapidssl, comodo positive ssl, thawte ssl web server. Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free
• Возврат средств — есть почти у всех сертификатов в течении 30 дней, хотя бывают и сертификаты без периода moneyback

Полезные утилиты:

1. OpenSSL — самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
   http://www.openssl.org/
2. CSR Decoder — утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
   CSR Decoder 1 или CSR Decoder 2
   
3. DigiCert Certificate Tester — утилита для проверки корректно самого сертификата
   http://www.digicert.com/help/?rid=011592
   http://www.sslshopper.com/ssl-checker.html
   

В следующих частях постараюсь рассказать про остальные виды сертификатов.

P.S. с удовольствием отвечу на любые вопросы связанные с выбором SSL сертификата в комментариях.
P.P.S. Желающие получить 30% скидку на ssl сертификаты — пишите в личку.

Update: Важный момент — некоторые сертификаты умеют работать на доменах с www и без www, то есть для защиты www.domain.com и domain.com достаточно одного сертификата, но заказывать его нужно на www.domain.com
Актуально для сертификатов:
• RapidSSL
• QuickSSL Premium
• True BusinessID
• True BusinessID with EV

habr.com

TLS и SSL: Необходимый минимум знаний

Что такое 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. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

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

$ openssl genrsa -out root.key 2048
Generating RSA private key, 2048 bit long modulus
..........+++
...........................................+++
e is 65537 (0x10001)

$ openssl req -new -key root.key -out root.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petersburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:IT Service
Common Name (e.g. server FQDN or YOUR name) []:My Company Root Certificate
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:My Company

$ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem
Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
Getting Private key

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

$ openssl x509 -noout -issuer -enddate -in root.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
notAfter=Jan 22 11:49:41 2025 GMT

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

Серверный сертификат

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

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата

$ openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
...................................................................................+++
..........................+++
e is 65537 (0x10001)

$ openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petersburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:IT Service
Common Name (e.g. server FQDN or YOUR name) []:www.mycompany.com
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365
Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected]
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in server.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected]
notAfter=Jan 25 12:22:32 2016 GMT

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

Установка 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) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

server {
       listen 443;
       server_name www.mycompany.com;

       root html;
       index index.html index.htm;

       ssl on;
       ssl_certificate server.pem;
       ssl_certificate_key server.key;

       ssl_session_timeout 5m;

       # Не рекомендуется использовать SSLv3 !!!
       # Он здесь только для примера
       ssl_protocols SSLv3 TLSv1;
       ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
       ssl_prefer_server_ciphers on;

       location / {
               try_files $uri $uri/ =404;
       }
}

3) Перезапустить nginx

4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.

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

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin [email protected]

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

        SSLEngine on

        SSLCertificateFile    /etc/ssl/certs/server.pem
        SSLCertificateKeyFile /etc/ssl/private/server.key

        # Эта директива добавляет файл, содержащий список
        # всех сертификатов, которыми подписан сертификат сервера
        #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

NameVirtualHost *:443

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

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

Клиентский сертификат создается примерно так же, как серверный.

$ openssl genrsa -out client.key 2048

Generating RSA private key, 2048 bit long modulus
........................+++
..................................................+++
e is 65537 (0x10001)

$ openssl req -new -key client.key -out client.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Saint-Petersburg
Locality Name (eg, city) []:^C
mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petrersburg  
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:Engineering
Common Name (e.g. server FQDN or YOUR name) []:Ivan Ivanov
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365

Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected]
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in client.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected]
subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected]
notAfter=Jan 25 13:17:15 2016 GMT

Если необходим клиентский сертификат в формате PKCS12, создаем его:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12

Enter Export Password:
Verifying - Enter Export Password:

Теперь можно использовать клиентский сертификат для работы с нашим сервером.

Настройка nginx на использование клиентских сертификатов

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

# Корневой сертификат(ы), которым(и) подписан клиентский
ssl_client_certificate /etc/nginx/certs/clientroot.pem;
# Возможные варианты: on | off | optional | optional_no_ca
ssl_verify_client optional;
# Глубина проверки цепочки сертификатов, которыми подписан клиентский
ssl_verify_depth 2;

После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.

Настройка Apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

# Директория, содержащая корневые сертификаты для проверки клиентов
SSLCARevocationPath /etc/apache2/ssl.crl/
# или файл, содержащий сертификаты
SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Опция верификации клиента. Возможные варианты:
# none, optional, require and optional_no_ca
SSLVerifyClient require
# Глубина просмотра цепочки подписей. По умолчанию 1
SSLVerifyDepth  2

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

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

openssl s_server -accept 443 -cert server.pem -key server.key -state

На стороне клиента обращаемся к серверу, например, culr’ом:

curl -k https://127.0.0.1:443

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Со стороны сервера ошибка выглядит так:

140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:

Со стороны клиента так:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

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

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.

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

• Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
• Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
• Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
• Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
• Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
• Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
• Нажмите, чтобы поделиться в Skype (Открывается в новом окне)

mnorin.com

Авторизация по клиентским TLS/SSL сертификатам в NGINX — Geek Notes

Простой и удобный способ авторизации на сайте или в приложениях по клиентским TLS/SSL сертификатам.

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

Шаг 1. Создание центра сертификации

Чтобы приступить к работе сперва необходимо настроить центр сертификации (CA), это довольно просто. Если на сервере установлен OpenSSL, то СА по умолчанию настроен и готов к работе. Теперь создадим свой собственный доверенный сертифика, он необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.

Шаг 1.2. Создаем приватный ключ центра сертификации.

openssl genrsa -out ca.key 4096

Шаг 1.3. Создаем самоподписанный сертификат.

openssl req -new -sha256 -x509 -days 1095 -key ca.key -out ca.crt

Шаг 2. Создание сертификата сервера

Шаг 2.1 Создаем приватный ключ для веб-сервера.

openssl genrsa -out server.key 4096

Шаг 2.2. Создаем сертификат для веб-сервера.

openssl req -new -key server.key -sha256 -out server.csr

Шаг 2.3. Подписываем сертификат веб-сервера нашим центром сертификации.

openssl x509 -req -days 1095 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 0x`openssl rand 16 -hex` -sha256 -out server.pem

Шаг 3. Создание клиентского сертификата

Шаг 3.1. Создаем клиентский приватный ключ по тому же принципу.

openssl genrsa -out client.key 4096

Шаг 3.2. Создаем клиентский сертификат.

openssl req -new -key client.key -sha256 -out client.csr

Шаг 3.3. Подписываем сертификат нашим центром сертификации.

openssl x509 -req -days 1095 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 0x`openssl rand 16 -hex` -sha256 -out client.pem

Шаг 4. Создание сертфиката в формате PKCS#12 для браузеров.

openssl pkcs12 -export -in client.pem -inkey client.key -name "Sub-domain certificate for some name" -out client.p12

Добавляем сертификаты в систему на примере MacOS

Загружаем client.p12 и установим его в систему.

Переходим в связку ключей и в свойствах установленного сертификата меняем уровень доверия на “Всегда доверять”.

Раскрываем ветку сертификата и предоставляем полный доступ для программ в его свойствах:

Для того, чтобы соединение было доверенным между сервером и клиентом, то обязательно установим корневой сертификат на клиентское устройство (ca.crt)

bogachev.biz

Что такое SSL, TLS, установка и настройка сертификата https

Основная установка и настройка будет проходить под Debian 8 Jessie, вебсервер NGINX, в бекенде Apache или PHP-FPM.
Инструментарий: Far Manager и Putty.
Команды вводятся в консоль SSH.
Если вы авторизованы не под root, добавляйте перед консольными командами sudo

Что такое SSL, TLS

SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который обеспечивает безопасную связь между сервером и клиентом. Этим протоколом шифруется интернет-трафик, который невозможно прослушать. В 2014 году был скомпрометирован (была обнаружена уязвимость), из-за чего на основании протокола SSL 3.0 был создан стандарт TLS, учитывающий ошибки предшественника, а SSL фактически прекратил своё развитие.

TLS (англ. Transport Layer Security — безопасность транспортного уровня) — криптографический протокол, обеспечивающий защищённую передачу данных от сервера к клиенту. TLS является потомком SSL 3.0. В основе работы лежат симметричное шифрование для конфиденциальности, асимметричная криптография для аутентификации и коды аутентичности сообщений для сохранения их целостности.

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).

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

Почему нужно использовать SSL/TLS

Есть как минимум одна веская причина: вы не сможете воспользоваться преимуществами нового протокола HTTP2 (HTTP/2 приходит на смену текущему стандарту HTTP/1.1), если для вашего сайта не установлен и настроен сертификат безопасности SSL/TLS.

Также безопасность данных в интернете является всё более востребованной и актуальной темой. И чем дальше, тем больше: Google заявил, что наличие SSL-шифрования на сайте является положительным фактором в ранжировании сайта в поисковой выдаче. Также, наличие HTTPS является обязательным атрибутом для каждого e-commerce сайт

sheensay.ru

Для чего нужен SSL-сертификат?

Для чего нужен SSL-сертификат?

• увеличения прибыли;
• защиты вашего бренда;
• защиты Вашего сайта.

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

1. Подключите к вашему сайту кодирование с использованием SSL-сертификатов.

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

2. Разместите знак использования доверенной марки (кодирования) около кнопки заказа.

Большинство клиентов хотят больших доказательств безопасности, чем изображение закрытого замка, отображаемое в браузере при каждом SSL-соединении. 54% online-покупателей в Великобритании покинули Интернет-магазин на стадии оплаты, не закончив покупку. Причиной этому послужило то, что сайт не смог вызвать у клиента ощущения безопасности и доверия. Всё же 87% online-покупателей Великобритании считают свою информацию в безопасности, если видят на сайте знак использования кодирования (SiteSeal/TrustLogo).

«Мы разместили логотипы Secured Seal на страницах оплаты и выяснилось, что количество законченных платежей повысилось приблизительно на 10% по сравнению с результатом предыдущей недели». Уоррен Джонас, Голова Управления Обслуживания, Opodo

3. Получите больше заказов с использованием премиальных SSL-сертификатов.

Участившиеся случаи обмана и мошенничества в сети Интернет, вынуждают клиентов задумываться о подлинности средств идентификации. Новые высокозащищённые браузеры дают гарантии идентичности online-информации, содержащейся в Вашем SSL-сертификате. Надпись ‘Comodo’ появляется рядом с Вашим фирменным знаком, для большего подтверждения идентичности. Покупайте Comodo EV SSL-сертификат.

4. Не ждите пока будет пробита брешь в вашей защите и злоумышленники получат доступ к вашим данным.

Стандарт безопасности The Payment Card Industry (PCI) требует, чтобы продавцы защищали финансовую информацию их клиентов, в противном случае на продавца накладываются штрафы или ограничения. Регулярные проверки на наличие уязвимостей через внешние IP адреса помогают продавцам оценивать риски взлома web-сайтов, на которых хранятся данные счёта кредитной карты. Независимо от того, сколько сделок Вы обрабатываете год, проверка уязвимости Вашей сети является хорошей бизнес-практикой.

5. Будьте лидером в вопросах безопасности.

Если Ваш сайт отображается в новейших браузерах с высокой степенью защиты, а сайт Вашего конкурента нет, то Ваша компания внушает клиенту больше доверия, Ваш бизнес выглядит более надёжным и законным. Это — конкурентоспособное преимущество в мире электронной коммерции. Будьте первым среди конкурентов в использовании SSL-сертификатов расширенной проверки (EV) и тогда в зелёной адресной строке браузера, рядом с названием Вашей компании будет высвечиваться логотип “Comodo”. Это повысит степень доверия Вашему сайту.

www.leaderssl.ru