TLS и HTTPS в Node: отдавайте всю цепочку

TLS-сервер в Node и что он на самом деле отдаёт

https.createServer — тонкая обёртка над tls.createServer: вы передаёте приватный ключ и сертификат, он терминирует TLS, и ваш обработчик запросов работает поверх расшифрованного потока. Самое важное поле — cert, и оно должно содержать полную цепочку, а не только собственный (листовой) сертификат сервера.

import { readFileSync } from "node:fs";
import { createServer } from "node:https";

const server = createServer(
  {
    key: readFileSync("privkey.pem"),
    // fullchain.pem = листовой сертификат, ЗА КОТОРЫМ идут все промежуточные, по порядку.
    // Это TLS-баг номер один в проде: вместо этого отдают cert.pem (только лист).
    cert: readFileSync("fullchain.pem"),
  },
  (req, res) => {
    res.writeHead(200);
    res.end("hello over TLS\n");
  },
);
server.listen(443);

Сертификат — это документ X.509 (стандарт формата цифровых сертификатов), связывающий открытый ключ с набором имён (Subject Alternative Names, или SAN — список разрешённых имён хостов) и подписанный издателем. Ваш лист подписан промежуточным CA, который подписан корневым CA, живущим в хранилище доверия клиента. Проверка — это движение клиента вверх по цепочке, пока он не дойдёт до уже доверенного корня. Клиент изначально доверяет только корням — промежуточного у него нет. Поэтому, если сервер отдаёт лишь лист, клиент не сможет соединить лист → корень, и проверка провалится. fullchain.pem от Let’s Encrypt существует именно для этого: это лист, склеенный с промежуточным(и). Используйте его, а не cert.pem.

Handshake: как согласовать ключ без утечки

До того как пойдёт первый байт HTTP, клиент и сервер выполняют TLS handshake: согласуют параметры, подтверждают личность сервера его сертификатом и выводят общий симметричный ключ. TLS 1.3 свёл это к одному раунду (1-RTT), потому что клиент угадывает группу обмена ключами и шлёт свою долю ключа в самом первом сообщении — так сервер может ответить всем необходимым, чтобы начать шифрование.

Клиент проверяет цепочку сертификатов (подписи валидны вплоть до доверенного корня, срок не вышел, а запрошенное имя хоста есть в SAN листа), сверяет CertificateVerify, чтобы убедиться, что сервер владеет соответствующим приватным ключом, и затем обе стороны переходят на симметричное шифрование. Асимметричная криптография аутентифицирует и обменивает ключ; основной трафик идёт быстрым симметричным (AES-GCM или ChaCha20). TLS 1.2 требовал двух раундов; если можно требовать 1.3 — handshake ощутимо дешевле.

SNI: много сертификатов на одном сокете

Один IP и порт часто обслуживают много имён хостов. Клиент сообщает серверу, какое имя ему нужно, в расширении SNI (Server Name Indication — указание имени сервера) внутри ClientHello — открытым текстом, до выбора сертификата, — чтобы сервер предъявил нужный сертификат. В Node вы выбираете сертификат по имени через SNICallback, возвращая SecureContext, собранный под каждое имя хоста:

import tls from "node:tls";
import { readFileSync } from "node:fs";
import { createServer } from "node:https";

const contexts = {
  "a.example.com": tls.createSecureContext({
    key: readFileSync("a.key"), cert: readFileSync("a.fullchain.pem"),
  }),
  "b.example.com": tls.createSecureContext({
    key: readFileSync("b.key"), cert: readFileSync("b.fullchain.pem"),
  }),
};

createServer({
  SNICallback(servername, cb) {
    const ctx = contexts[servername];
    cb(ctx ? null : new Error("unknown host"), ctx);
  },
}, handler).listen(443);

tls.createSecureContext — это переиспользуемый набор ключа, цепочки, шифров и настроек протокола; SNICallback позволяет выбрать один из них во время handshake. Так обратный прокси или мультиарендный сервер размещает десятки доменов на одном слушателе.

Возобновление сессии: пропустить дорогую часть

Полный handshake стоит асимметричной криптографии и раунда. Возобновление (resumption) позволяет вернувшемуся клиенту переиспользовать ранее согласованный секрет и пропустить большую часть этого. Два механизма: session ID — сервер хранит состояние сессии по идентификатору, а клиент предъявляет ID для возобновления (память на стороне сервера, без общего хранилища не масштабируется на кластер); и session ticket (RFC 5077) — сервер шифрует состояние сессии в непрозрачный блоб, который хранит и переотправляет клиент, без состояния на сервере, поэтому масштабируется горизонтально. В TLS 1.3 возобновление использует pre-shared keys, выведенные из тикетов, и может нести 0-RTT early data. Возобновление превращает многосообщенческий асимметричный handshake в быстрый сокращённый, снижая задержку соединения для повторных визитов.

Ошибки сертификатов, с которыми вы реально столкнётесь

Эти четыре дают большинство реальных тикетов по TLS. Константа подсказывает причину:

Заметьте: ни один из фиксов не звучит как «отключить проверку». Каждая ошибка — это механизм верификации, корректно сообщающий о реальном дефекте цепочки, окна валидности или именования. Когда видите такую константу в логах — читайте её как точный диагноз: она говорит именно что сломано и что чинить.