Самоподписанный SSL сертификат – преимущества и недостатки

Самоподписанный SSL сертификат - преимущества и недостатки Сертификаты
На чтение 15 мин. Просмотров 26 Опубликовано
Содержание
  1. Что такое самоподписанный ssl сертификат?
  2. Введение:
  3. 1 Подготовка CA
  4. 2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)
  5. 3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).
  6. 4. Создание сертификата в формате PKCS#12 для браузера клиента
  7. New-selfsignedcertificate: командлет powershell для генерации самоподписанного сертификата
  8. Ssl-сертификаты — инструменты — дока
  9. Главный недостаток самоподписанного ssl сертификата
  10. Использование самоподписанного ssl сертификата sha-256 в iis
  11. Использованное по
  12. Конфиг nginx
  13. Полезные ссылки
  14. Создать самоподписанный сертфикат типа code signing для подписывания кода
  15. Шаг 1. создание собственного самоподписанного доверенного сертификата.
  16. Шаг 2. сертификат сервера

Что такое самоподписанный ssl сертификат?

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

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

Введение:

Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».


Не я первый с этим столкнулся и мир давно уже использует для таких вещей

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

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

Внимание! В статье для примера используются самоподписанные сертификаты!

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

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

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

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

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

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

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

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

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

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

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

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

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

Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.

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

New-selfsignedcertificate: командлет powershell для генерации самоподписанного сертификата

Для создания самоподписанного сертификата в PowerShell нужно использовать командлет New-SelfSignedCertificate, входящий в состав модуля PKI (Public Key Infrastructure).

Чтобы вывести список всех доступных командлетов в модуле PKI, выполните команду:

Get-Command -Module PKI

Самоподписанные сертификаты рекомендуется использовать в тестовых целях или для обеспечения сертификатами внутренних интранет служб (IIS, Exchange, Web Application Proxy, LDAPS, ADRMS, DirectAccess и т.п.), в тех случая когда по какой-то причине приобретение сертификата у внешнего провайдера или разворачивание инфраструктуры PKI/CA невозможны.

Для создания сертификата нужно указать значения –DnsName (DNS имя сервера, имя может быть произвольным и отличаться от имени localhost) и —CertStoreLocation (раздел локального хранилища сертификатов, в который будет помещен сгенерированный сертификат).

Про сертификаты:  Сертификация котлового оборудования - Сертификационный центр "Квантум Групп"

Ssl-сертификаты — инструменты — дока

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

SSL-сертификат — это набор информации в бумажном или электронном виде, состоящий из:

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

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

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

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

Сертификат открытого ключа может быть получен несколькими способами:

  • Через специальный авторизованный удостоверяющий центр (центр сертификации), которому пользователь сайта может доверять. Это самый распространённый вариант работы сайта в режиме коммерческого использования. Обычно сертификат выдаётся на какой-то срок, в течение которого удостоверяющий центр ручается за владельца сайта перед пользователем.
  • Генерация сертификата самим пользователем с помощью специализированных программ. Такие сертификаты часто используются для настройки или для работы внутренних сервисов компаний. В этом случае издатель сертификата совпадает с владельцем сайта.
  • Генерация фиктивного сертификата с помощью специализированных программ. Этот способ используется для настройки инфраструктуры проекта. Сертификат в этом варианте содержит фиктивную информацию, однако отлично подходит для тестирования.

Рассмотрим схему обмена данными двух сторон A и B с помощью SSL-сертификата. Принимается, что обе стороны доверяют третьей стороне T, которая соответствует центру сертификации. У сторон A и T есть по паре ключей. Каждая пара состоит из открытого и закрытого ключа.

Сторона A пересылает стороне T свой открытый ключ. Сторона T с помощью определённых механизмов устанавливает соответствие между открытым ключом стороны A и самой стороной A (физическое или юридическое лицо). После этого сторона T пересылает стороне A сертификат, который содержит:

  • Открытый ключ стороны A.
  • Информацию о стороне A, которая позволяет её идентифицировать.
  • Информацию о стороне T, которая позволяет её идентифицировать.
  • Электронную подпись стороны T (хэш-сумму), которая генерируется по содержимому сертификата и затем зашифровывается с использованием закрытого ключа стороны T.
  • Другие данные.

Когда сторона A пересылает стороне B свой сертификат, сторона B сравнивает сгенерированную хэш-сумму на основе содержимого сертификата и хэш-сумму, которая получается при расшифровке электронной подписи стороны T с помощью открытого ключа. Если хэш-суммы совпадают, то открытый ключ стороны A действительно принадлежит именно ей. После этого сторона B может шифровать данные с использованием открытого ключа стороны A и пересылать ей эти данные в зашифрованном виде. И только сторона A может расшифровать их.

Такая схема является самой простой при использовании протокола транспортного уровня TLS.

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

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

Про сертификаты:  Стандарты сертификации мотошлемов: виды тестирования мотошлемов

Можно выбирать любой понравившийся центр, но нужно принимать во внимание несколько факторов:

  • Юрисдикция, в рамках которой центр действует. Есть множество центров сертификации, которые действуют внутри одного региона или страны. Для сайтов этого, как правило, оказывается мало.
  • Цена за услуги (изготовление сертификатов, обслуживание, продление). Платить можно и за бренд, но чаще всего в этом нет никакого практического смысла.
  • Насколько долго работает центр на рынке подобных услуг.
  • Отзывы клиентов центра. Сюда же относится и репутация. Есть несколько международных организаций, которые могут поддержать доверие к центру включением в специальный список доверенных. Аккредитация может быть произведена и контролирующим органом внутри страны, в юридическом поле которой действует компания.

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

Электронная форма сертификата определяется стандартом X.509. На уровне законодательства во многих странах есть свои законы или правила, которые повторяют, дополняют или уточняют детали этого стандарта. В области веб-приложений, в частности, используется стандарт RFC.5280. В нём описаны процедуры создания и отзыва сертификатов, которым должны следовать центры сертификации.

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

Например, авторитетная американская компания VeriSign предложила такую классификацию:

  • Class 1 — индивидуальные, для идентификации электронной почты.
  • Class 2 — для организаций.
  • Class 3 — для серверов и программного обеспечения.
  • Class 4 — для онлайн-бизнеса и транзакций между компаниями.
  • Class 5 — для частных компаний или правительственной безопасности.

В России больше прижилась схема всего из трёх классов:

  • SSL-сертификаты начального уровня для физических лиц.
  • SSL-сертификаты бизнес-класса для юридических лиц.
  • SSL-сертификаты с расширенной проверкой для юридических лиц.

Согласно этой классификации для физических лиц доступны:

  • Проверка принадлежности домена физическому лицу.
  • Шифрование передачи данных со стороны пользователя сайта.
  • Доступ к внутренним ресурсам компании.
  • Доступ к закрытой (административной) части сайта и системам аналитики.

Среди сертификатов начального уровня чаще всего пользуются следующими решениями от компаний GlobalSign, Comodo и других:

  • GlobalSign AlphaSSL (Wildcard).
  • GlobalSign DomainSSL (Wildcard).
  • Comodo SSL Wildcard (Wildcard).
  • Comodo SSL.
  • Easy Trust SSL от TrustWave.
  • QuickSSL premium от GeoTrust.
  • Thawte SSL123.

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

DomainSSL, AlphaSSL, OrganizationSSL и Comodo SSL — наиболее популярные сертификаты. При этом сертификаты имеют наименьший уровень доверия. Это дёшево и сердито. Практически никто из пользователей сайта никогда не задумается о том, какой сертификат используется.

Если важен уровень доверия, то можно использовать сертификаты бизнес-класса или сертификаты с расширенной проверкой. Этот вариант подходит очень крупным компаниям. У таких сертификатов есть множество дополнительных опций, нужных только крупному бизнесу. К сертификатам бизнес-класса относятся:

  • GlobalSign OrganizationSSL (Wildcard).
  • Comodo Premium SSL Wildcard (Wildcard).
  • Comodo InstantSSL Premium.
  • Comodo Premium SSL.
  • GeoTrust True BusinessID.
  • GeoTrust True BusinessID Wildcard (Wildcard).
  • TrustWave Premium SSL.
  • TrustWave Premium SSL Wildcard (Wildcard).
  • Symantec (VeriSign) SecureSite SSL.
  • Thawte SSL Webserver.
  • Thawte SSL Wildcard (Wildcard).

А к сертификатам с расширенной проверкой подлинности относятся:

  • GlobalSign ExtendedSSL.
  • Symantec (VeriSign) SecureSite EV SSL.
  • Symantec (VeriSign) SecureSite Pro EV SSL.
  • Comodo SSL EV.
  • Thawte SSL Webserver EV.
  • TrustWave Premium SSL EV.
  • GeoTrust True BusinessID EV.

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

С развитием международного сообщества программистов приложения с открытым исходным для многих сфер стали хорошим решением. В области применения сертификатов безопасности решение тоже не заставило себя ждать. Была создана полноценная криптографическая библиотека OpenSSL, которая позволяет не только реализовать поддержку протокола HTTPS в большинстве популярных браузеров, но и использовать самоподписанные сертификаты безопасности как для личных, так и для коммерческих проектов.

Про сертификаты:  Онлайн проверка ssl сертификата | SEO -

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

Создать ключ для генерации SSL-сертификата можно командой:

openssl genrsa -des3 -out example.com.key 2048openssl genrsa -des3 -out example.com.key 2048

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

openssl req -new -key example.com.key -out example.com.csropenssl req -new -key example.com.key -out example.com.csr

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

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

openssl req -noout -text -in example.com.csropenssl req -noout -text -in example.com.csr

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

Главный недостаток самоподписанного ssl сертификата

При всем своем удобстве, самоподписанный сертификат SSL обладает огромным недостатком: его можно применять только при обмене данными между пользователями, которые знают о самоизданном SSL сертификате и подтвердили его в браузере. Если же к каналу, защищенному таким SSL сертификатом, подключается внешний посетитель, он видит следующее предупреждение: «Сертификат безопасности не является доверенным!»

Предупреждение о самоподписанном SSL сертификате в Chrome[/caption] На данном этапе большинство пользователей предпочитает вернуться назад к безопасности и выбрать веб-сайт без риска, в связи с чем Ваш сайт может потерять значительное число посетителей.

Использование самоподписанного ssl сертификата sha-256 в iis

Обратите внимание, что при создании самоподписанный сертификат для IIS через консоль Internet Information Manager (пункт меню Create Self-Signed Certificate), создается сертификат с исопльзованием алгоритма шифрования SHA-1.

Вы можете привязать самоподписанный сертификат SHA-256, созданный в PowerShell, к сайту IIS. Если вы с помощью PowerShell создали SSL сертификат и поместили его в хранилище сертификатов компьютера, он будет автоматически доступен для сайтов IIS.

Запустите консоль IIS Manager, выберите ваш сайт, затем в настройке Site Binding, выберите созданный вами сертификат и сохраните изменения.

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

Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)

nginx 0.9.3


OpenSSL 0.9.8o 01 Jun 2021

Конфиг 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;

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

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

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

Создать самоподписанный сертфикат типа code signing для подписывания кода

В PoweShell 3.0 командлет New-SelfSifgnedCertificate позволял генерировать только SSL сертификаты, которые нельзя было использоваться для подписывания кода драйверов и приложений (в отличии сертификатов, генерируемых утилитой MakeCert).

В версии PowerShell 5 новая версия командлета New-SelfSifgnedCertificate теперь может использоваться для выпуска сертификатов типа Code Signing.

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

$cert = New-SelfSignedCertificate -Subject “Cert for Code Signing” -Type CodeSigningCert -CertStoreLocation cert:LocalMachineMy

Теперь можно подписать ваш PowerShell скрипт эти сертификатом:

Set-AuthenticodeSignature -FilePath C:PStest_script.ps1 -Certificate $cert

Если при выполнении команды появится предупреждение UnknownError, значит этот сертификат недоверенный, т.к. находится в персональном хранилище сертификатов пользователя.

Нужно переместить его в корневые сертификаты (не забывайте периодически проверять хранилище сертификатов Windows на наличие недоверенных сертфикатов и обновлять списки корневых сертификатов):

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

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

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

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

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 ssl
Оцените статью
Мой сертификат
Добавить комментарий

© 2025 Мой сертификат