PrepBro
← Назад к вопросам

Какие знаешь виды SSL?

2.0 Middle🔥 162 комментариев
#Клиент-серверная архитектура

Комментарии (2)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Виды SSL/TLS-сертификатов

SSL (Secure Sockets Layer) и его преемник TLS (Transport Layer Security) — это криптографические протоколы, обеспечивающие безопасную передачу данных в сети. На практике под термином "SSL" часто подразумевают оба протокола. **SSL-сертификаты** классифицируются по нескольким ключевым параметрам: уровню проверки, количеству защищаемых доменов и функциональному назначению. Понимание этих различий критически важно для QA-инженера при тестировании веб-приложений, анализе требований безопасности и валидации корректной реализации HTTPS.

1. Классификация по уровню валидации (проверки)

Уровень определяет глубину проверки данных организации или физического лица, проводимой Центром сертификации (Certificate Authority, CA) перед выдачей сертификата.

  • DV (Domain Validated) — с проверкой домена: Самый базовый и быстро выдаваемый тип. CA проверяет только право заявителя на владение доменным именем (например, через email или DNS-запись). В браузере отображается значок замка и протокол HTTPS, но не показывает название компании. Используется для блогов, личных сайтов, тестовых сред.

    # Пример команды для создания CSR (запроса на сертификат) — актуален для всех типов, но данные в Subject будут разными
openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

  • OV (Organization Validated) — с проверкой организации: Промежуточный уровень. Помимо владения доменом, CA проверяет юридическую информацию об организации (название, адрес, законность деятельности). Эти данные включаются в поле Subject сертификата и могут быть просмотрены пользователем при детальном изучении сертификата в браузере. Подходит для корпоративных сайтов и публичных сервисов.

  • EV (Extended Validation) — с расширенной проверкой: Наиболее строгий уровень. Процедура проверки организации максимально тщательна и регламентирована стандартами (CA/Browser Forum). Главное внешнее отличие — в адресной строке большинства браузеров (помимо замка) отображается официальное название компании на зеленом фоне. Это повышает доверие пользователей к сайтам банков, платежных систем и крупных e-commerce платформ.

2. Классификация по количеству защищаемых доменов (имён)

  • Single-Domain: Защищает одно полное доменное имя (FQDN). Например, www.example.com не включает example.com или shop.example.com. Нужен отдельный сертификат для каждого вариативного имени.

  • Wildcard (*): Защищает одно доменное имя и все его поддомены одного уровня. Обозначается звездочкой (*). Например, сертификат для *.example.com покроет blog.example.com, api.example.com, shop.example.com, но не покроет www.example.com (так как это тоже *.example.com) и уж точно не dev.api.example.com (поддомен второго уровня). Критически важен для тестирования сред с динамически создаваемыми поддоменами.

  • Multi-Domain / SAN (Subject Alternative Name): Позволяет защитить несколько различных доменных имен в рамках одного сертификата. В поле Subject Alternative Name перечисляются все FQDN. Например, один сертификат может покрывать example.com, example.net, example.org и www.example.com. Экономичен для управления несколькими связанными доменами.

3. Классификация по функциональному назначению

  • Самоподписанные (Self-Signed): Сертификат, выпущенный и подписанный собственноручно, а не доверенным CA. Не вызывает доверия у браузеров и клиентов по умолчанию (появляются предупреждения безопасности). Используется исключительно во внутренних (интранет) или тестовых средах, где можно вручную добавить корневой сертификат в хранилище доверенных.

    # Пример (Python) для простой проверки валидности сертификата на хосте (упрощённо)
import ssl
import socket

hostname = 'example.com'
context = ssl.create_default_context()
# Для теста с самоподписанным сертификатом пришлось бы отключать верификацию:
# context.check_hostname = False
# context.verify_mode = ssl.CERT_NONE

with socket.create_connection((hostname, 443)) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        cert = ssock.getpeercert()
        print(f"Сертификат для {hostname} получен.")

  • Сертификаты, подписанные доверенным ЦС (Public CA): Выпущены коммерческими (DigiCert, Sectigo) или бесплатными (Let's Encrypt) публичными центрами сертификации, чьи корневые сертификаты предустановлены в ОС и браузерах. Гарантируют отсутствие предупреждений для конечных пользователей. Let's Encrypt стал де-факто стандартом для автоматизации и выдачи бесплатных DV-сертификатов.

Практическое значение для QA Engineer

  1. Тестирование установки и совместимости: Необходимо проверять корректность установки разных типов сертификатов (особенно Wildcard и Multi-Domain) на серверах (Nginx, Apache, облачные балансировщики), отсутствие ошибок в цепочке доверия и корректное отображение в различных браузерах и мобильных ОС.
  2. Валидация безопасности: Для OV/EV-сертификатов нужно проверять, что в деталях сертификата действительно отображаются данные компании-заказчика. Для всех типов — проверять актуальность дат действия, стойкость используемого шифра (не ниже TLS 1.2, предпочтительно TLS 1.3) и отсутствие таких уязвимостей, как Heartbleed (для старых систем).
  3. Тестирование функциональности: Ключевые сценарии:
    *   **Редиректы:** Все HTTP-запросы должны корректно перенаправляться на HTTPS.
    *   **Mixed Content:** Страница, загруженная по HTTPS, не должна содержать активного контента (скрипты, стили, iframes), загружаемого по HTTP ("смешанное содержимое"), что вызывает предупреждения в консоли браузера и снижает безопасность.
    *   **HSTS (HTTP Strict Transport Security):** Проверка, что заголовок HSTS возвращается корректно, предписывая браузеру всегда использовать HTTPS.
  1. Автоматизация и тестовые среды: В CI/CD-пайплайнах и средах staging/development активно используются самоподписанные или бесплатные DV-сертификаты. QA-инженер должен обеспечить, чтобы тестовые фреймворки и скрипты (Selenium, API-тесты) могли корректно работать с ними, либо отключая верификацию в контролируемых условиях, либо импортируя тестовый корневой сертификат.

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