SSL сертификаты для серверов

h

Материалы и реквизиты серверного сертификата (X.509 v3)

Серверный цифровой документ для защищённого канала представляет собой бинарный контейнер формата ASN.1 DER (или PEM-кодировку Base64), соответствующий стандарту X.509 версии 3. Ключевые поля: Subject Public Key Info (алгоритм и открытый ключ), Issuer (реквизиты удостоверяющего центра), Validity (notBefore / notAfter), Serial Number (уникальный идентификатор, присвоенный ЦС), Subject Alternative Name (расширение SAN для многодоменных конфигураций). В поле Basic Constraints установлен флаг CA:FALSE, так как серверный документ не является корневым. Все версии с 2024 года используют SHA-256 (или выше) для подписи; SHA-1 запрещён в RFC 9155.

Различия по криптографическому материалу: RSA vs ECDSA

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

Спецификация ECC и гибридные конфигурации

Современные серверные прокси (nginx 1.25+, LiteSpeed 6.2+) позволяют выкладывать два сертификата на один IP (протокол TLS ALPN). Спецификация: ECDSA для клиентов с поддержкой TLS 1.3 (сокращение handshake на 35-40% за счёт более быстрого вычисления ECDHE), RSA как fallback для старых браузеров (Windows 7/IE 11). Для разработки под высоконагруженные проекты (>10k RPS) рекомендуются связки ключевых материал: Ed25519 (BoringSSL, Go, LibreSSL) — кривая с RFC 8709, обеспечивающая подпись за 300 мкс. Однако Ed25519 не сертифицирован для FIPS 140-3 в классических HSM (hardware security module).

Уровни валидации и стандарты качества (DV, OV, EV)

Стандарт CA/Browser Forum (v.2.0.3) определяет три уровня проверки субъекта, которые прямо влияют на качество выпуска и процедуры аудита.

Процедура сборки цепочки и требования к промежуточным звеньям

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

  1. Серверный документ — листовой (end-entity) с Issuer = CN промежуточного ЦС.
  2. Промежуточные (intermediate CAs) — от 1 до 3 звеньев. Каждый имеет CA:TRUE и Path Length Constraint (если задан). Глубина более 4 звеньев запрещена практиками (влияет на размер handshake).
  3. Корневой (root CA) — самоподписанный, хранится в операционной системе клиента (Apple/Google/Microsoft Trust Store). На сервере не распространяется, так как доверие начинается с root.

Для корректной сборки используется конкатенация файлов PEM в порядке: endpoint.crt + intermediate.crt. Альтернатива — формат PKCS#7 (p7b) с дальнейшим импортом в OpenSSL. Проверка целостности цепочки: openssl verify -CAfile /path/to/root.crt -untrusted /path/to/chain.pem server.crt.

Протокол валидации статуса — OCSP Must-Staple

Для актуальности отозванных документов обязательно применение OCSP Stapling (RFC 6961). Механика: веб-сервер (nginx, Apache httpd 2.4+, IIS 10) опрашивает OCSP-ответчик удостоверяющего центра (URI из расширения AIA) и прикрепляет подписанный ответ (OCSP response) непосредственно к handshake TLS. Параметры: подпись ответа должна быть от указанного в Certificate Authority Information Access (CA Issuers). Время действия ответа — до 7 дней (рекомендация CA/Browser Forum). Если OCSP-ответчик содержит revoked status — браузер разрывает соединение. Флаг Must-Staple (Extended Key Usage: 1.3.6.1.5.5.7.1.24) включает принудительную проверку на стороне клиента. Серверные стапели запрещены для корневых сертификатов.

Качество производства: аудит ЦС и стандарты безопасности

Процесс выпуска серверных сертификатов регулируется международными стандартами: WebTrust for Certification Authorities (принципы 1–8), ETSI EN 319 401 (общий полиси), ETSI EN 319 411-2 (требования к EV). Каждый УЦ (Certificate Authority) проходит ежегодный внешний аудит (Big4 или специализированная фирма). Технические реквизиты аудита включают:

Документация производителя поставляется в форматах PEM (+ ключ в OpenSSL или PKCS#12), PFX (Microsoft IIS), DER для аппаратных балансировщиков (F5, Citrix ADC). Каждый продукт обязан содержать Policy OID (2.23.140.1.2.1 — DV, 2.23.140.1.2.3 — EV). Проверка качества на стороне разработчика: openssl x509 -in server.pem -text -noout.

Добавлено: 07.05.2026