Ответ
При работе с TLS/SSL в инфраструктуре (настройка Ingress, сервисов, внутреннего PKI) я проверяю подлинность сертификата по следующей схеме:
1. Проверка цепочки доверия Сертификат должен быть подписан доверенным УЦ (CA). Я проверяю всю цепочку до корневого сертификата:
# Проверка цепочки с помощью OpenSSL
openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt server.crt
# Или для цепочки в одном файле
openssl verify -untrusted intermediate.crt -CAfile root.crt server.crt
2. Валидация сроков действия Сертификат не должен быть просрочен:
openssl x509 -in server.crt -noout -dates
# Вывод: notBefore и notAfter
В скриптах автоматизации я добавляю проверку:
openssl x509 -in server.crt -noout -checkend 864000 # Проверка, истекает ли в течение 10 дней
3. Проверка отзыва (CRL/OCSP) Убеждаюсь, что сертификат не отозван:
# Проверка через OCSP (пример)
openssl ocsp -issuer ca.crt -cert server.crt -url http://ocsp.example.com -text
4. Верификация соответствия домена Common Name (CN) или Subject Alternative Names (SAN) должны соответствовать домену:
openssl x509 -in server.crt -noout -subject -ext subjectAltName
5. Проверка ключа и подписи Публичный ключ в сертификате должен соответствовать приватному ключу:
# Сравнение modulus (уникальный идентификатор ключа)
openssl x509 -in server.crt -noout -modulus
openssl rsa -in server.key -noout -modulus
# Вывод должен быть идентичным
6. Практическое применение в инфраструктуре:
- В Kubernetes использую
cert-managerдля автоматической выдачи и обновления сертификатов от Let's Encrypt. - Для внутренних сервисов разворачиваю собственный CA с помощью
cfsslилиstep-ca. - Все проверки интегрирую в CI/CD пайплайны и периодические скрипты мониторинга.