Можно ли иметь несколько SSL-сертификатов на одном IP-адресе?

Краткий ответ

Да, можно. Технология SNI (Server Name Indication), ставшая стандартом, позволяет размещать несколько SSL/TLS-сертификатов на одном IP-адресе и одном сетевом порту (обычно 443 для HTTPS). Это решает ключевую проблему ранних версий SSL/TLS, где для каждого уникального доменного имени, защищённого сертификатом, требовался отдельный IP-адрес.

Подробное объяснение: как это работает

Проблема без SNI

В основе SSL/TLS-рукопожатия лежит обмен криптографическими ключами до передачи каких-либо данных приложения (например, HTTP-запроса). В старых реализациях (без SNI) сервер на одном IP-адресе не мог знать, для какого домена клиент хочет установить соединение, до момента расшифровки пакетов. А чтобы расшифровать, ему уже нужен правильный сертификат. Возникал замкнутый круг.

Решение: SNI (Server Name Indication)

SNI — это расширение протокола TLS, описанное в RFC 6066. Его суть проста: клиент (браузер, curl, и т.д.) в самом начале рукопожатия, в сообщении ClientHello, указывает hostname (имя сервера), к которому он пытается подключиться. Это происходит в незашифрованном виде.

Пример упрощённого процесса:

1. Клиент хочет подключиться к https://shop.example.com.
2. В ClientHello он отправляет расширение SNI с значением shop.example.com.
3. Сервер (например, Nginx или Apache), прослушивающий IP:PORT, получает это имя.
4. Сервер сверяется со своей конфигурацией и выбирает SSL-сертификат, привязанный именно к shop.example.com.
5. Сервер продолжает рукопожатие, используя уже выбранный сертификат.

Практическая реализация

Вот пример конфигурации для Nginx, обслуживающего два сайта с разными сертификатами на одном IP:

# Конфигурация первого сервера (виртуального хоста)
server {
    listen 443 ssl;
    server_name example.com www.example.com;

    # Уникальные сертификаты для первого домена
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;

    location / {
        root /var/www/example.com;
    }
}

# Конфигурация второго сервера на том же IP и порту
server {
    listen 443 ssl;
    server_name api.example.com;

    # Уникальные сертификаты для второго домена
    ssl_certificate     /etc/ssl/api.example.com.crt;
    ssl_certificate_key /etc/ssl/api.example.com.key;

    location / {
        root /var/www/api;
    }
}

И аналогичный пример для Apache:

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example

    SSLEngine on
    SSLCertificateFile "/etc/pki/tls/certs/example.com.crt"
    SSLCertificateKeyFile "/etc/pki/tls/private/example.com.key"
</VirtualHost>

<VirtualHost *:443>
    ServerName api.example.com
    DocumentRoot /var/www/api

    SSLEngine on
    SSLCertificateFile "/etc/pki/tls/certs/api.example.com.crt"
    SSLCertificateKeyFile "/etc/pki/tls/private/api.example.com.key"
</VirtualHost>

Ключевые аспекты и ограничения

Поддержка клиентов

• Почти повсеместна. Все современные браузеры (Chrome, Firefox, Safari, Edge), операционные системы и библиотеки (OpenSSL, GnuTLS) поддерживают SNI.
• Важное исключение: очень старые клиенты, такие как Internet Explorer на Windows XP, или старые версии Android (ниже 2.3), не поддерживают SNI. Для них соединение с SNI-сервером может завершиться ошибкой. На практике это перестаёт быть актуальной проблемой, но в средах со строгими требованиями к legacy-поддержке это учитывают.

Альтернативные решения (если SNI не подходит)

1. Wildcard-сертификат (*.example.com). Позволяет защитить неограниченное количество поддоменов одного уровня одним сертификатом. Но не подходит для разных доменов второго уровня (example.com и example.net) или многоуровневых поддоменов (например, *.prod.east.example.com потребует отдельный wildcard).
2. Сертификат с Subject Alternative Name (SAN). Можно создать один сертификат, в который через поле SAN внесён список множества различных доменных имён. Это удобно для контроля, но любое изменение списка требует перевыпуска всего сертификата.
3. Использование нескольких IP-адресов. Исторический метод, который до сих пор может быть актуален для:

    *   Критических сервисов, где нельзя допустить отказ даже для пользователей со старым ПО.
    *   Сценариев, где требуется выделенный IP для соответствия стандартам (некоторые требования PCI DSS в прошлом).
    *   Очень старых систем, где ПО сервера или сетевые устройства не поддерживают SNI.

Безопасность и SNI

• SNI передаётся в открытом виде. Это означает, что наблюдатель (провайдер, государственные органы) может видеть, к какому доменному имени вы подключаетесь, даже если содержимое сессии зашифровано. Эта "утечка метаданных" — одна из причин появления Encrypted Client Hello (ECH), следующего шага в развитии TLS, который шифрует и эту часть рукопожатия.

Вывод для DevOps-инженера

В современной практике SNI — это стандарт де-факто. Он позволяет:

• Экономить IP-адреса (что критично в условиях истощения IPv4).
• Гибко управлять десятками и сотнями доменов на одном веб-сервере или балансировщике нагрузки (например, в облачных средах или SaaS-платформах).
• Упрощать развёртывание и обслуживание.

При проектировании инфраструктуры вы почти всегда будете полагаться на SNI. Необходимость в wildcard или SAN-сертификатах возникает из соображений удобства управления, а не из-за технических ограничений. Понимание работы SNI необходимо для правильной настройки веб-серверов, балансировщиков (Nginx, HAProxy, облачные ALB), CDN и решения проблем с SSL/TLS.