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

Процесс получения цифрового сертификата в удостоверяющем центре (УЦ)

Получение цифрового сертификата (или SSL/TLS-сертификата) — многоэтапный процесс, требующий предоставления и проверки определенных данных. Конкретный список зависит от типа сертификата (DV, OV, EV, код-подпись и т.д.) и политик центра сертификации (CA), но общий набор обязательных данных и действий следующий:

1. Генерация пары ключей и запроса на сертификат (CSR)

Перед обращением в УЦ необходимо локально сгенерировать приватный ключ (Private Key) и запрос на подпись сертификата (Certificate Signing Request, CSR). В CSR включается информация о субъекте сертификата.

Ключевые поля в CSR:

• Common Name (CN) — для веб-сертификатов это полное доменное имя (FQDN), например www.example.com. Для сертификатов кода — имя организации.
• Organization (O) — юридическое название компании.
• Organizational Unit (OU) — подразделение (например, IT Department).
• Locality (L) и State/Province (ST) — город и область/штат.
• Country (C) — двухбуквенный код страны (например, RU).
• Публичный ключ — автоматически включается из сгенерированной пары.

Пример генерации CSR с помощью OpenSSL:

# Генерация приватного ключа RSA (2048 бит)
openssl genrsa -out private.key 2048

# Создание CSR на основе ключа. Будет запрошено ввод данных субъекта.
openssl req -new -key private.key -out request.csr

# Альтернативно, все данные можно указать одной командой
openssl req -new -key private.key -out request.csr \
  -subj "/C=RU/ST=Moscow/L=Moscow/O=Example LLC/OU=DevOps/CN=example.com"

2. Выбор типа сертификата и предоставление данных для валидации

После создания CSR вы выбираете тип сертификата в УЦ и предоставляете данные для проверки ваших прав на его получение.

• Для Domain Validation (DV) сертификата:

    *   Необходимо **доказать право владения доменом**. Это самый простой тип.
    *   УЦ может потребовать:
        *   Создать DNS-запись (например, `_acme-challenge.example.com` со специальным значением).
        *   Разместить проверочный файл по указанному HTTP/HTTPS пути.
        *   Подтвердить право через email, отправленный на адрес, указанный в WHOIS (например, `admin@example.com`).

• Для Organization Validation (OV) и Extended Validation (EV) сертификатов:

    *   Требуется **юридическая проверка организации**. Помимо данных из CSR, необходимо предоставить:
        *   **Официальные регистрационные документы** (выписка из ЕГРЮЛ, ИНН, ОГРН).
        *   **Подтверждение физического адреса** и телефона организации.
        *   **Подтверждение того, что заявитель является уполномоченным представителем** организации (часто через звонок с УЦ на официальный номер компании).
    *   Для **EV-сертификатов** проверка максимально строгая, требует больше времени и документов, но дает "зеленую строку" в браузере.

3. Отправка запроса и прохождение валидации

• Вы отправляете CSR в УЦ через его веб-интерфейс или API (например, ACME-протокол, используемый Let's Encrypt).
• Проходите выбранный метод валидации (DNS, HTTP, Email или организационную проверку).
• УЦ проверяет предоставленные данные через публичные реестры (WHOIS, государственные базы данных) и с помощью отправленных вами доказательств.

4. Получение и установка сертификата

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

• Сам сертификат (обычно в форматах .crt, .pem, .cer).
• Цепочку сертификатов (chain) или промежуточный сертификат, необходимый для корректной проверки цепочки доверия браузерами.
• Ваш приватный ключ (который вы сгенерировали на первом шаге и никогда не передаете УЦ).

Пример итоговой цепочки доверия для установки на веб-сервере Nginx:

# Файл сертификата вашего домена
server.crt

# Файл цепочки сертификатов (intermediate + root), полученный от УЦ
ca-bundle.crt

# Ваш приватный ключ, сгенерированный на шаге 1
server.key

Конфигурация в Nginx:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;
    # Часто цепочку нужно объединить с основным сертификатом в один файл
    # ssl_certificate /etc/ssl/certs/server_chained.crt;
}

Ключевой принцип безопасности

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

Таким образом, для получения сертификата вы указываете в CSR свои идентификационные данные, а затем предоставляете УЦ строго определенные доказательства того, что вы являетесь законным владельцем домена и/или организации, на которую эти данные оформляются.