что это такое и особенности создания

32364

Прочитать позже

АУДИТ САЙТА — СЕРТИФИКАТ HTTPS

Инструкцию одобрил
SEO-специалист в Luxeo

Илья Беланенко

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

Содержание:

1. Что собой представляет самоподписанный сертификат SSL?
2. Какими бывают самозаверенные сертификаты SSL?
3. Преимущества и недостатки самоподписанных сертификатов SSL
4. Заключение

Что собой представляет самоподписанный сертификат SSL?

Технически такой сертификат не отличается от версии, подписанной доверенным центром. Разница — в подписи, заверяющей сертификат.

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

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

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

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

Хотите узнать, как с помощью Serpstat найти и исправить технические ошибки на сайте?

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

Какими бывают самозаверенные сертификаты SSL?

Их создают вручную с помощью специальных программ или библиотек. Например, для Windows можно воспользоваться криптографическим хранилищем OpenSSL или консолью PowerShell. Эти инструменты генерируют сертификаты SSL, создают открытые и секретные ключи.

Создание самоподписанного сертификата SSL через OpenSSL подразумевает использование таких команд:

out /home/devuser/cert/cert.crt — место локации сертификата;
newkey rsa:2048 — автоматическое создание ключа, если у вас его нет;
req-x509 — запрос на генерацию самоподписанного сертификата;
keyout /home/devuser/cert/mykey.key — запрос на генерацию ключа.

Затем после ввода пароля необходимо описать данные вашего сервера. Для пропуска определенного параметра оставьте точку «.» в конце командной строки:

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

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

New-SelfSignedCertificate -DnsName localhost -CertStoreLocation cert:\LocalMachine\My

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

Так выглядит самоподписанный сертификат SSL на сервере Nginx:

Где cert.crt означает открытый ключ, а cert.key — секретный ключ.

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

Site.ru — домен ресурса, для которого вы генерируете сертификат.

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

Преимущества и недостатки самоподписанных сертификатов SSL

Плюсы самозаверенных версий

Возможность генерировать бесконечное количество сертификатов.

Отсутствие платы за подпись.

Скорость создания. Нет потребности ожидать ответа от центра сертификации.

Недостатки самоподписанных сертификатов

Риск потери данных пользователей.

Постоянное предупреждение о неизвестном издателе.

Отсутствие гарантий, что данные с сайта не попадут в третьи руки.

Отсутствие доверия со стороны людей, так как на сайте нет значка подписи центра сертификации.

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

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

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

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

Заключение

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

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

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

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

Задавайте вопросы в комментариях или пишите в техподдержку. 🙂 А также вступайте в чат любителей Серпстатить и подписывайтесь на наш канал в Telegram.

Serpstat — набор инструментов для поискового маркетинга!

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

Набор инструментов для экономии времени на выполнение SEO-задач.

7 дней бесплатно

Оцените статью по 5-бальной шкале

3.25 из 5 на основе 11 оценок

Нашли ошибку? Выделите её и нажмите Ctrl + Enter, чтобы сообщить нам.

Используйте лучшие SEO инструменты

Подбор ключевых слов

Поиск ключевых слов – раскройте неиспользованный потенциал вашего сайта

Возможности Serpstat

Возможности Serpstat – комплексное решение для эффективного продвижения вебсайтов

Кластеризация ключевых слов

Кластеризация ключевых слов автоматически обработает до 50 000 запросов в несколько кликов

SEO аудит страницы

Проанализируйте уровень оптимизации документа используя SЕО аудит страницы

Рекомендуемые статьи

How-to

Анастасия Сотула

Что такое addurl Google и как работает аддурилка

How-to

Анастасия Сотула

Как купить сайт и не облажаться

How-to

Анастасия Сотула

Как проверить отсутствие аффилиатов и выйти из-под аффилиат-фильтра

Кейсы, лайфхаки, исследования и полезные статьи

Не успеваешь следить за новостями? Не беда! Наш любимый редактор подберет материалы, которые точно помогут в работе. Только полезные статьи, реальные кейсы и новости Serpstat раз в неделю. Присоединяйся к уютному комьюнити 🙂

Нажимая кнопку, ты соглашаешься с нашей политикой конфиденциальности.

Поделитесь статьей с вашими друзьями

Вы уверены?

Спасибо, мы сохранили ваши новые настройки рассылок.

Сообщить об ошибке

Отменить

Как выпустить самоподписанный SSL сертификат и заставить ваш браузер доверять ему / Хабр

Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2016 года.

На production нет проблем с сертификатами. Обычно хостинг провайдер предоставляет удобный интерфейс для подключения сертификата. Выпуск сертификата тоже дело не сложное. Но во время работы над проектом каждый разработчик должен позаботиться о сертификате сам.

В этой статье я расскажу, как выпустить самоподписанный SSL сертификат и заставить браузер доверять ему.

Чтобы выпустить сертификат для вашего локального домена, понадобится корневой сертификат. На его основе будут выпускаться все остальные сертификаты. Да, для каждого нового top level домена нужно выпускать свой сертификат. Получить корневой сертификат достаточно просто.

Сначала сформируем закрытый ключ:

openssl genrsa -out rootCA.key 2048

Затем сам сертификат:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Нужно будет ввести страну, город, компанию и т.д. В результате получаем два файла:

rootCA.key и

rootCA.pem

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

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

if [ -z "$1" ]
then
  echo "Please supply a subdomain to create a certificate for";
  echo "e.g. mysite.localhost"
  exit;
fi

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

if [ -f device.key ]; then
  KEY_OPT="-key"
else
  KEY_OPT="-keyout"
fi

Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):

DOMAIN=$1
COMMON_NAME=${2:-$1}

Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:

SUBJECT="/C=CA/ST=None/L=NB/O=None/CN=$COMMON_NAME"
NUM_OF_DAYS=999

В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (страна, город, компания и т. д). Все значение, кроме CN можно поменять на свое усмотрение.

Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.

openssl req -new -newkey rsa:2048 -sha256 -nodes $KEY_OPT device.key -subj "$SUBJECT" -out device.csr

Формируем файл сертификата. Для этого нам понадобится вспомогательный файл с настройками. В этот файл мы запишем домены, для которых будет валиден сертификат и некоторые другие настройки. Назовем его

v3.ext. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = %%DOMAIN%%
DNS.2 = *.%%DOMAIN%%

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

v3. ext

Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:

cat v3.ext | sed s/%%DOMAIN%%/$COMMON_NAME/g > /tmp/__v3.ext

Выпускаем сертификат:

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days $NUM_OF_DAYS -sha256 -extfile /tmp/__v3.ext

Переименовываем сертификат и удаляем временный файл:

mv device.csr $DOMAIN.csr
cp device.crt $DOMAIN.crt
# remove temp file
rm -f device.crt;

Скрипт готов. Запускаем его:

./create_certificate_for_domain.sh mysite.localhost

Получаем два файла:

mysite.localhost.crt и

device.key

Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:

Запускаем браузер, открываем https://mysite.localhost и видим:

Браузер не доверяет этому сертификату. Как быть?

Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:

Обновляем страницу в браузере и:

Успех! Браузер доверяет нашему сертификату.

Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.

Делитесь в комментариях, используете ли вы https для локальной разработки?

Максим Ковтун,

Руководитель отдела разработки

Что такое самозаверяющий сертификат? Преимущества, риски и альтернативы

Сертификаты SSL/TLS

7 января 2021 г.

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

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

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

Давайте разберем некоторые ключевые различия:

Общедоступные доверенные сертификаты

Общедоступные доверенные сертификаты SSL/TLS используются для общедоступных веб-серверов и приложений. Общедоступный сертификат может быть выдан только внешним доверенным сторонним ЦС (например, Entrust, DigiCert и т. д.), который проверяет владельца домена.

Частные доверенные сертификаты

Частные доверенные сертификаты SSL/TLS используются для аутентификации пользователей и устройств во внутренней сети. Частный доверенный сертификат может быть выпущен либо общедоступным ЦС, либо, что чаще, любой организацией, которая использует свою собственную выделенную внутреннюю инфраструктуру открытых ключей (например, ЦС Microsoft).

Что такое самозаверяющий сертификат?

Другая стратегия заключается в выпуске самозаверяющих SSL-сертификатов. Самозаверяющий сертификат — это сертификат, который вообще не подписан центром сертификации — ни частным, ни общедоступным. В этом случае сертификат подписывается собственным закрытым ключом, а не запрашивается у общедоступного или частного ЦС.

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

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

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

Риски самозаверяющих сертификатов и ЦС в DevOps

Эти риски усугубляются количеством встроенных самозаверяющих ЦС в инструментах DevOps и облачных службах, а также самозаверяющих сертификатов, выпущенных разработчиками.

DevOps — это скорость и гибкость. Хотя самозаверяющие сертификаты позволяют разработчикам быстро и легко получать сертификаты, они часто обходят политики, которые вы установили для обеспечения безопасности вашей сети. Независимо от того, создают ли разработчики самозаверяющий сертификат или раскручивают самозаверяющий ЦС, эти методы создают ложное чувство доверия к процессу разработки и поставки.

Итак, зачем разработчикам использовать самозаверяющие сертификаты? Лучше спросить, почему бы и нет. Обычный ручной процесс отправки запроса на подпись сертификата (CSR), а затем несколько часов ожидания для проверки и подписания просто не интуитивно понятен. Чтобы сэкономить время и нервы, разработчикам имеет смысл выбирать самозаверяющие сертификаты или встроенные центры сертификации, такие как HashiCorp Vault, Istio и Kubernetes.

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

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

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

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

Альтернатива: переход от самоподписания к самообслуживанию

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

В Keyfactor мы работаем с командами DevOps, чтобы перейти от самозаверяющих сертификатов к сертификатам как услуге. Это означает, что разработчики могут получать сертификаты с помощью автоматизированных процессов и API, напрямую интегрированных с облачными инструментами, такими как Jenkins, Ansible, Kubernetes, HashiCorp Vault, Istio и другими. При этом каждый сертификат выдается из доверенной PKI как услуги предприятия, а система безопасности обеспечивает полную видимость и контроль над каждым выданным сертификатом.

Включение PKI как услуги в DevOps

PKI как услуга (PKIaaS) — это оптимальное сочетание надежности и простоты использования. Сертификаты выдаются из доверенной частной PKI, и команды DevOps могут легко запрашивать и выдавать сертификаты с помощью процессов самообслуживания, что снижает потребность в самозаверяющих сертификатах.

Чтобы узнать больше о том, как можно устранить необходимость в самоподписанных сертификатах и ​​внедрить автоматизацию самообслуживания, запросите демонстрацию Keyfactor сегодня.

Демо-запрос

Что такое самозаверяющий сертификат

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

Что такое самозаверяющий сертификат?

Самозаверяющий сертификат TLS/SSL подписан не общедоступным доверенным центром сертификации (ЦС), а разработчиком или компанией, ответственной за веб-сайт; поскольку они не подписаны общедоступным доверенным центром сертификации, они обычно считаются небезопасными для общедоступных приложений и веб-сайтов.

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

Выражение «самозаверяющие сертификаты» обычно относится к сертификатам TLS/SSL, созданным автономно, без привязки к корневому или промежуточному сертификату. Это также может относиться к другим сертификатам цифровой подписи X.509, таким как S/MIME, подпись кода и подпись документа.

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

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

Как долго действительны самозаверяющие сертификаты?

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

В отличие от самозаверяющих сертификатов, общедоступные доверенные сертификаты TLS/SSL не могут быть выпущены более чем на 13 месяцев. До 2015 года максимальный допустимый срок действия составлял пять лет, но постепенно он был сокращен до 1 года. Это относится к сертификатам TLS/SSL с расширенной проверкой (EV) и проверкой организации (OV).

Можно ли доверять самозаверяющим сертификатам?

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

Безопасны ли самозаверяющие сертификаты?

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

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

Чем опасны самозаверяющие сертификаты?

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

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

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

Подверженность уязвимостям

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

Кроме того, организации часто не следят за своими самозаверяющими сертификатами, в результате чего просроченные или скомпрометированные сертификаты остаются незамеченными. Такие скомпрометированные сертификаты являются воротами, через которые злоумышленники могут получить доступ к сети и запустить продвинутые и изощренные вредоносные атаки, атаки «человек посередине» (MITM), фишинговые атаки и ботнеты.

Без гарантии и технической поддержки

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

Отсутствие видимости и контроля

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

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

Несоответствие требованиям безопасности

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

This entry was posted in Популярное