PR_CONNECT_RESET_ERROR, PR_END_OF_FILE_ERROR и SEC_ERROR_UNKNOWN_ISSUER: ошибки Firefox и их аналоги в Chrome

У Firefox собственный сетевой и TLS-стек, поэтому на те же сбои он показывает не ERR_*, а коды PR_, SEC_, SSL_ и MOZILLA_PKIX_. Разбираем четыре самых частых: соответствия с Chrome, команды openssl и curl, и почему сайт открывается в Chrome, но не в Firefox на том же компьютере.

Ошибки Firefox с префиксами PR_, SEC_, SSL_ и MOZILLA_PKIX_ — коды библиотек NSPR и NSS, на которых построен сетевой и TLS-стек Firefox: PR_ — ошибки уровня TCP-сокета, SSL_ — ошибки TLS-протокола, SEC_ — ошибки проверки сертификатов, MOZILLA_PKIX_ — ошибки собственного валидатора цепочек Mozilla. Chrome для тех же ситуаций использует коды ERR_* и стек BoringSSL, а список доверенных корней у Firefox свой, не системный.

Почему у Firefox свои коды ошибок

Firefox не использует ни системный TLS (SChannel в Windows, Secure Transport в macOS), ни BoringSSL, как Chromium: шифрование, сертификаты и сокеты он ведёт через библиотеки NSS и NSPR, которые Mozilla поддерживает сама. У каждой свой диапазон кодов: по заголовочным файлам на сентябрь 2026 база NSPR (prerr.h) — −6000, SEC_ERROR_BASE — −8192, SSL_ERROR_BASE — −12288, база MOZILLA_PKIX — −16384. Отсюда числа −5961 (PR_CONNECT_RESET_ERROR), −5938 (PR_END_OF_FILE_ERROR), −8179 (SEC_ERROR_UNKNOWN_ISSUER), −12263 (SSL_ERROR_RX_RECORD_TOO_LONG) в about:networking и логах. Префикс указывает уровень: PR_ — TCP-соединение, к сертификатам отношения не имеет; SSL_ — несовместимость протокола; SEC_ и MOZILLA_PKIX_ — соединение есть, но сертификату Firefox не верит.

Таблица соответствий Firefox ↔ Chrome

Сводная таблица по заголовкам NSS/NSPR и net_error_list.h Chromium. Соответствия не всегда один к одному: Chrome сворачивает несколько ситуаций в ERR_SSL_PROTOCOL_ERROR, Firefox их различает.

Серверная диагностика одинакова для обоих браузеров, см. аналоги в Chrome: ERR_CONNECTION_RESET, ERR_CERT_AUTHORITY_INVALID и ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

PR_CONNECT_RESET_ERROR: кто прислал TCP RST

PR_CONNECT_RESET_ERROR означает, что TCP-соединение было установлено, а затем прервано пакетом RST («TCP connection reset by peer» в prerr.h). Сертификаты ни при чём: RST мог прислать сервер, файрвол, DPI оператора или программа на самом компьютере. Сброс сразу после ClientHello типичен для DPI по SNI и антивирусов с перехватом TLS, сброс после загрузки части страницы — для лимитов и падений на сервере.

Команда openssl s_client показывает, на какой фазе рвётся соединение. Четыре характерных вывода для четырёх ошибок из статьи:

$ openssl s_client -connect example.com:443 -servername example.com

# пример вывода 1: TCP RST во время рукопожатия
# (PR_CONNECT_RESET_ERROR в Firefox)
CONNECTED(00000003)
write:errno=104          # ECONNRESET; в macOS errno=54

# пример вывода 2: сервер закрыл соединение молча
# (PR_END_OF_FILE_ERROR)
CONNECTED(00000003)
error:0A000126:SSL routines::unexpected eof while reading

# пример вывода 3: цепочка не доходит до доверенного корня
# (SEC_ERROR_UNKNOWN_ISSUER)
verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
    Verify return code: 21 (unable to verify the first certificate)

# пример вывода 4: на 443 отвечает не TLS
# (SSL_ERROR_RX_RECORD_TOO_LONG)
CONNECTED(00000003)
error:0A00010B:SSL routines::wrong version number

Коды — для OpenSSL 3.x, в ветке 1.1 тексты отличаются, смысл тот же: errno 104 — RST, «unexpected eof» — сервер закрыл сокет штатно, verify error 20/21 — не найден издатель, «wrong version number» — ответ не похож на TLS-запись.

PR_END_OF_FILE_ERROR: сервер закрыл соединение во время рукопожатия

PR_END_OF_FILE_ERROR («Encountered end of file» в prerr.h) означает, что Firefox отправил ClientHello и вместо ответа получил FIN — закрытие соединения без единого байта TLS. Так ведёт себя сервер, не сумевший договориться о параметрах и не отправивший TLS-alert, либо посредник (прокси, VPN, антивирус), который не смог подключиться к сайту от вашего имени.

Самая частая серверная причина — несовпадение версий TLS и шифров: по данным Mozilla Hacks, с Firefox 74 (март 2020) TLS 1.0 и 1.1 отключены, security.tls.version.min стал равен 3 (TLS 1.2) вместо 1. Сервер только с TLS 1.0, который вместо alert просто закрывает сокет, даст не SSL_ERROR_UNSUPPORTED_VERSION, а PR_END_OF_FILE_ERROR.

Настройки TLS самого Firefox проверяются в about:config: подтвердите предупреждение, введите security.tls.version. Умолчания: security.tls.version.min = 3 (TLS 1.2), security.tls.version.max = 4 (TLS 1.3); жирная строка — значение менялось, стрелка справа возвращает умолчание. Там же network.proxy.type (5 — системный прокси) и network.trr.mode: по вики Mozilla 0 — DoH выключен, 2 — DoH с откатом на системный DNS, 3 — только DoH, 5 — выключен пользователем.

$ curl -v https://example.com/ -o /dev/null

# пример вывода: сервер закрыл соединение после ClientHello
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:443
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL ...

# Договаривается ли сервер по конкретной версии
$ openssl s_client -connect example.com:443 -tls1_2 </dev/null 2>&1 \
    | grep -E 'Protocol|Cipher'
# пример вывода при исправном сервере
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

SEC_ERROR_UNKNOWN_ISSUER: почему Firefox не верит сертификату

SEC_ERROR_UNKNOWN_ISSUER означает, что цепочка сертификатов сайта не заканчивается корнем из собственного хранилища доверия Firefox. Ключевое слово — «собственного»: корень, добавленный в систему антивирусом, администратором или установщиком сертификата Минцифры, Chrome увидит, а Firefox без отдельной настройки — нет. Различить причины просто: ошибка на одном сайте — сервер, на большинстве HTTPS-сайтов — компьютер.

Первый шаг — посмотреть, кто выдал сертификат: на странице ошибки «Дополнительно» → «Просмотреть сертификат» открывает about:certificate с полной цепочкой. Если издатель — антивирус или прокси, а не публичный УЦ, перехват на вашей стороне. Поддержка Mozilla прямо называет продукты с такой функцией: Avast/AVG, Bitdefender, Bullguard, ESET, Kaspersky.

Для корпоративных и антивирусных корней есть штатный механизм — security.enterprise_roots.enabled: Firefox подгружает корни из системного хранилища (в Windows — из HKLM\SOFTWARE\Microsoft\SystemCertificates и групповых политик, в macOS — из системной связки ключей). По документации Mozilla на сентябрь 2026 на Windows, macOS и Android импорт включён по умолчанию и управляется флажком «Разрешить Firefox автоматически доверять сторонним корневым сертификатам» или политикой ImportEnterpriseRoots; для Linux встроенного импорта нет. Корень только в системе при выключенном параметре — SEC_ERROR_UNKNOWN_ISSUER на каждом HTTPS-сайте.

Вручную корень добавляется через Настройки → Приватность и защита → Просмотр сертификатов → Импортировать, либо утилитой certutil из NSS (пакет libnss3-tools).

# Хранилище профиля — cert9.db (Linux; в macOS профили
# лежат в ~/Library/Application Support/Firefox/Profiles)
# Добавить корень при закрытом Firefox; -t "C,," — доверять для TLS
P=$HOME/.mozilla/firefox/xxxx.default-release
certutil -d sql:$P -A -n "Corp Root CA" -t "C,," -i corp-root.pem

# Список корней и удаление, когда корень больше не нужен
certutil -d sql:$P -L
certutil -d sql:$P -D -n "Corp Root CA"

Для самоподписанного сертификата Firefox показывает MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT; для тестового стенда или роутера допустимо исключение через «Дополнительно → Принять риск и продолжить». Корень НУЦ Минцифры в хранилище Mozilla не входит (bug 1758773 в Bugzilla на сентябрь 2026 — без решения о включении), поэтому такие сайты дают SEC_ERROR_UNKNOWN_ISSUER в Firefox, Chrome и Safari и открываются только в браузерах с предустановленным корнем.

SSL_ERROR_RX_RECORD_TOO_LONG: на порту 443 отвечает не TLS

SSL_ERROR_RX_RECORD_TOO_LONG («Received a malformed (too long or short) SSL record» в sslerr.h) почти всегда означает, что на ClientHello по порту 443 пришёл обычный HTTP-текст: NSS читает первые байты как заголовок TLS-записи, видит бессмысленную длину и останавливается. Это ошибка конфигурации сервера, а не браузера или сети.

Типовые сценарии: listen 443 без параметра ssl в nginx; адрес с портом, где ждут HTTP (https://example.com:8080); балансировщик проброшен на HTTP-порт бэкенда; порт 443 занят другим сервисом. Обратная ситуация — HTTP-запрос на TLS-порт — даёт в nginx код 497 «The plain HTTP request was sent to HTTPS port».

# Было: «listen 443;» без ssl — на 443 отвечает открытый HTTP
# Правильно: параметр ssl у listen и полная цепочка в fullchain.pem
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
}

sudo nginx -t && sudo systemctl reload nginx
curl -sI https://example.com/ | head -1
# пример вывода
HTTP/2 200

Снаружи это пример вывода 4 из блока openssl: «wrong version number» на первой же записи; curl завершается с кодом 35 и тем же текстом. Если http://example.com:443 возвращает HTML, порт отдаёт открытый HTTP.

В Chrome работает, в Firefox нет: что проверить в самом Firefox

Расхождение между браузерами на одном компьютере объясняется одним из пяти компонентов, которые у Firefox свои: хранилище корней, DoH, прокси, версии TLS и способ встраивания антивируса. Chrome берёт корни и прокси из системы, Firefox — из профиля, поэтому системные исправления на него могут не подействовать.

Порядок: издатель сертификата на странице ошибки → три ключа about:config (enterprise_roots, trr.mode, tls.version) → безопасный режим (about:support → Перезапустить без дополнений). Всё по умолчанию, а ошибка осталась — источник вне Firefox.

Как владельцу сайта понять, что проблема на сервере

Если причина на сервере, все четыре ошибки воспроизводятся из любой сети — их увидит каждый внешний клиент. Поэтому первый вопрос при жалобе пользователя — падает ли сайт при проверке снаружи, с адресов, не связанных с его компьютером.

Это делают две проверки. Проверка SSL-сертификата строит цепочку до доверенного корня и проверяет срок и соответствие имени — неполная цепочка или неизвестный издатель видны как ошибка проверки, а не как жалоба одного человека. HTTP-проверка с интервалом от 2 минут делает полный запрос из 20 точек в России, Беларуси, Казахстане и Испании: если рукопожатие обрывается или порт отвечает не TLS, проверка падает из всех локаций сразу; если сброс только из части регионов — во вкладке «По локациям» видно, откуда именно, и это вопрос к оператору, а не к серверу.

Частые вопросы

Почему Firefox ругается на сертификат, а Chrome открывает сайт без предупреждений?

Две причины. На сервере нет промежуточного сертификата: Chrome докачивает его по ссылке AIA, а Firefox берёт только уже виденные из кеша — openssl s_client покажет verify error 21. Либо корень добавлен в системное хранилище (антивирус, корпоративный УЦ, сертификат Минцифры), а Firefox без security.enterprise_roots.enabled его не читает.

Безопасно ли включать security.enterprise_roots.enabled?

Параметр распространяет на Firefox корни, которым уже доверяет система, — уровень безопасности становится равен уровню Chrome. Риск: при попадании в систему вредоносного корня Firefox перестаёт быть последним барьером. В корпоративной среде и рядом с антивирусом, перехватывающим HTTPS, включать разумно; на личном компьютере без таких программ он ничего не меняет.

Что делать с сайтами с сертификатом Минцифры в Firefox?

У пользователя два варианта: установить корень вручную (импорт в Firefox либо системное хранилище плюс enterprise_roots) или открывать такие сайты в браузере с предустановленным корнем. Владельцу сайта нужен сертификат публичного УЦ хотя бы на основном домене: иначе ошибку увидят Firefox, Chrome и Safari, а мониторинг сертификата будет постоянно показывать проблему цепочки.

Помогает ли отключение DNS через HTTPS (DoH)?

Только когда системный DNS и DoH-резолвер Firefox отдают разные адреса — для внутрикорпоративных имён или сайтов с региональной балансировкой: Firefox подключается не к тому серверу, что Chrome, и получает сброс или чужой сертификат. about:networking → DNS показывает адреса и признак TRR; поставьте network.trr.mode = 5 и повторите. На ошибки от неправильно настроенного сервера DoH не влияет.