Тема: tls
-
Мониторинг истечения TLS-сертификатов на всех узлах, а не только на основном сайте
Истёкший сертификат — это отказ с абсолютно предсказуемым моментом наступления; опрашивайте дату notAfter каждого реально обслуживаемого сертификата (веб, API, почта, внутренние панели, балансировщики нагрузки) снаружи, настраивайте оповещение с запасом времени, достаточным для ручного продления, и проверяйте не только листовой сертификат, но и промежуточные.
-
Как проверить, действительно ли TLS-соединение согласовало X25519MLKEM768
Отличайте наличие постквантовой возможности в установленном ПО от группы, выбранной в реальном TLS-соединении, с помощью сведений браузера, OpenSSL, curl и данных на стороне сервера.
-
Hostname, FQDN and reverse DNS consistency: why Kerberos and TLS name checks break when they disagree
Kerberos service tickets and TLS hostname verification both depend on the name a client resolves for a server matching the name the service believes it has. A mismatch between the configured hostname, /etc/hosts, forward DNS and the PTR record produces authentication and certificate errors that look unrelated to naming.
-
The TLS 1.3 handshake in outline
TLS 1.3 negotiates keys in one round trip: the ClientHello already carries a key share, the ServerHello answers with its own, and everything after it, including the certificate, is encrypted. Resumption uses pre-shared keys from session tickets; 0-RTT early data is optional and replayable.
-
TLS verification errors across tools: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed in chain
Different TLS clients report the same underlying failure - an incomplete or untrusted certificate chain - in their own wording: 'certificate signed by unknown authority', 'CERTIFICATE_VERIFY_FAILED', 'unable to get local issuer certificate', 'self-signed certificate in certificate chain'. The article shows how to diagnose the actual chain with openssl s_client before reaching for any fix, and why -k or verify=False is never one.
-
curl's exit codes: telling a DNS failure from a TLS failure from --fail
curl returns a distinct numeric code for each class of transport failure (name resolution, connection, TLS, timeout) plus a separate code, 22, that only appears when --fail or --fail-with-body is requested for HTTP error statuses. An agent that greps curl's exit code instead of its text can route retries correctly without parsing output.
-
Постквантовые подписи и публичные сертификаты TLS: отдельные проверки готовности
ML-DSA и SLH-DSA — стандартизованные алгоритмы подписи, но выпуск публичных сертификатов TLS также зависит от профилей сертификатов, интеграции с протоколом и допуска в рамках политик доверия.
-
Checking a served TLS certificate chain and its expiry from the command line with openssl
openssl s_client with -servername and -showcerts prints the certificates a server actually sends, which the manual describes as not a verified chain; openssl x509 reads subject, issuer, SANs and the notAfter date of each one, and openssl verify -untrusted rebuilds the chain against a trust store. Check every hostname, and IPv4 and IPv6 separately.
-
Adding a private CA to the system trust store on RHEL-family and Debian/Ubuntu
RHEL-family and Debian-family Linux keep separate mechanisms for adding a locally trusted CA certificate: update-ca-trust with anchors under /etc/pki/ca-trust, and update-ca-certificates with .crt files under /usr/local/share/ca-certificates. Using the wrong directory or extension silently leaves the CA untrusted.
-
Поиск фиксированных списков групп TLS, мешающих переходу приложений на гибридные настройки по умолчанию
Проверьте явно заданные списки групп в Go, Java, nginx и конфигурации OpenSSL, прежде чем считать, что обновление библиотеки включает постквантовый обмен ключами.
-
Переключение общесистемных криптографических политик в RHEL с помощью update-crypto-policies
Общесистемная криптографическая политика RHEL задаёт алгоритмы и версии протоколов, предлагаемые по умолчанию OpenSSL, GnuTLS, NSS, libkrb5 и OpenSSH; её можно изменить одной командой вместо редактирования конфигурации каждого приложения. Методика охватывает просмотр, установку и проверку политики и объясняет, почему уже работающие службы нужно перезапустить для её применения.
-
TLS for rsyslog forwarding with the gtls driver, and when RELP is worth adding
rsyslog's gtls network stream driver encrypts and can mutually authenticate a forwarding connection with X.509 certificates, configured with StreamDriverAuthMode. Plain TLS over TCP still loses in-flight messages on an unclean disconnect; RELP's application-level acknowledgement is what closes that gap, at the cost of extra moving parts.
-
Trusting a private CA on macOS and Windows, and verifying it actually took effect
macOS trusts a root CA system-wide through the System keychain with `security add-trusted-cert`, and Windows through the Local Machine Root store with Import-Certificate or certutil -addstore. Both changes are silent unless verified separately, and both differ from a per-user or per-browser trust decision.
-
Local HTTPS for development: a private CA, trust stores and the localhost exception
Browsers already treat localhost and loopback addresses as potentially trustworthy, so local HTTPS is needed only for TLS-specific behaviour or non-loopback development names; for those, create a private CA per machine with a tool such as mkcert, issue leaf certificates for development names, install the root in the system and per-tool trust stores, and never share the CA key.
-
Why applications ignore the OS trust store: Java cacerts, Python certifi, Node.js and curl
Adding a CA to the operating system's trust store does not make every application trust it. Java, many Python installs, Node.js and curl builds can carry their own CA bundle or keystore, each with its own file location and override environment variable, so a certificate error can persist after the OS-level fix.
Машиночитаемо: JSON