Tema: tls
-
Monitorar a expiração de certificados TLS em todos os endpoints, não só no site principal
Um certificado expirado é uma indisponibilidade com hora exatamente previsível: sonde de fora a data notAfter de cada certificado realmente servido (web, API, e-mail, painéis internos, balanceadores de carga), alerte com antecedência suficiente para renovar manualmente e verifique também os intermediários, não só o certificado final.
-
Como verificar se uma conexão TLS realmente negociou X25519MLKEM768
Diferencie a capacidade pós-quântica instalada do grupo selecionado em uma conexão TLS real, usando detalhes do navegador, OpenSSL, curl e evidências do servidor.
-
Consistência entre hostname, FQDN e DNS reverso: por que as verificações de nome do Kerberos e do TLS falham quando divergem
Os tickets de serviço do Kerberos e a verificação de hostname do TLS exigem que o nome resolvido pelo cliente coincida com o nome que o serviço considera seu. Uma divergência entre o hostname configurado, o /etc/hosts, o DNS direto e o registro PTR gera erros de autenticação e de certificado que parecem não ter relação com nomes.
-
O handshake do TLS 1.3 em linhas gerais
O TLS 1.3 negocia as chaves em uma única ida e volta: o ClientHello já traz um key share, o ServerHello responde com o seu, e tudo o que vem depois, inclusive o certificado, é cifrado. A retomada usa chaves pré-compartilhadas de session tickets; os early data 0-RTT são opcionais e sujeitos a replay.
-
Erros de verificação TLS em diferentes ferramentas: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed na cadeia
Diferentes clientes TLS relatam a mesma falha de fundo, uma cadeia de certificados incompleta ou não confiável, cada um com suas palavras: 'certificate signed by unknown authority', 'CERTIFICATE_VERIFY_FAILED', 'unable to get local issuer certificate', 'self-signed certificate in certificate chain'. O artigo mostra como diagnosticar a cadeia real com openssl s_client antes de aplicar qualquer correção e por que -k ou verify=False nunca é uma delas.
-
Códigos de saída do curl: distinguir falha de DNS, falha de TLS e --fail
O curl devolve um código numérico distinto para cada classe de falha de transporte (resolução de nome, conexão, TLS, timeout) e um código separado, 22, que só aparece quando --fail ou --fail-with-body é usado para status HTTP de erro. Um agente que avalia o código de saída do curl em vez do texto consegue direcionar as novas tentativas corretamente, sem analisar a saída.
-
Assinaturas pós-quânticas e certificados TLS públicos: verificações separadas de prontidão
ML-DSA e SLH-DSA são algoritmos de assinatura padronizados, mas a emissão de certificados TLS públicos também depende de perfis de certificados, integração com o protocolo e aceitação pelas políticas de confiança.
-
Verificar a cadeia de certificados TLS servida e a sua validade na linha de comando com openssl
O comando openssl s_client com -servername e -showcerts mostra os certificados que o servidor realmente envia, e o manual esclarece que isso não é uma cadeia verificada; openssl x509 lê subject, issuer, SANs e a data notAfter de cada um, e openssl verify -untrusted reconstrói a cadeia contra um trust store. Verifique cada hostname, e IPv4 e IPv6 separadamente.
-
Como adicionar uma CA privada ao repositório de confiança do sistema na família RHEL e no Debian/Ubuntu
As famílias RHEL e Debian de Linux usam mecanismos distintos para adicionar um certificado de CA de confiança local: update-ca-trust com âncoras em /etc/pki/ca-trust, e update-ca-certificates com arquivos .crt em /usr/local/share/ca-certificates. Usar o diretório ou a extensão errada deixa a CA sem confiança, sem nenhum aviso.
-
Como encontrar listas fixas de grupos TLS que impedem as aplicações de adotar os padrões híbridos
Audite listas explícitas de grupos nas configurações de Go, Java, nginx e OpenSSL antes de presumir que uma atualização de biblioteca habilita a troca de chaves pós-quântica.
-
Alterar as políticas criptográficas do sistema no RHEL com update-crypto-policies
A política criptográfica do sistema no RHEL define os algoritmos e as versões de protocolo padrão oferecidos por OpenSSL, GnuTLS, NSS, libkrb5 e OpenSSH, e pode ser alterada com um único comando, sem editar a configuração de cada aplicação. Esta metodologia mostra como consultar, definir e testar uma política, e explica por que serviços já em execução precisam ser reiniciados para aplicá-la.
-
TLS no encaminhamento do rsyslog com o driver gtls e quando vale a pena adicionar o RELP
O driver de stream de rede gtls do rsyslog cifra a conexão de encaminhamento e pode autenticar ambos os lados com certificados X.509, configurado por meio de StreamDriverAuthMode. TLS sobre TCP simples ainda perde mensagens em trânsito numa desconexão abrupta; a confirmação do RELP na camada de aplicação fecha essa lacuna, ao custo de mais componentes.
-
Confiar em uma CA privada no macOS e no Windows e verificar se a mudança realmente surtiu efeito
No macOS, uma CA raiz passa a ser confiável em todo o sistema pelo keychain System, com `security add-trusted-cert`; no Windows, pelo repositório Local Machine Root, com Import-Certificate ou certutil -addstore. As duas alterações são silenciosas, a menos que sejam verificadas à parte, e ambas diferem de uma decisão de confiança por usuário ou por navegador.
-
HTTPS local para desenvolvimento: uma CA privada, repositórios de confiança e a exceção do localhost
Os navegadores já tratam localhost e endereços de loopback como potencialmente confiáveis, por isso o HTTPS local só é necessário para comportamentos específicos de TLS ou para nomes de desenvolvimento fora do loopback; nesses casos, crie uma CA privada por máquina com uma ferramenta como o mkcert, emita certificados finais para nomes de desenvolvimento, instale a raiz nos repositórios de confiança do sistema e de cada ferramenta, e nunca compartilhe a chave da CA.
-
Por que as aplicações ignoram o repositório de confiança do SO: Java cacerts, Python certifi, Node.js e curl
Adicionar uma CA ao repositório de confiança do sistema operacional não faz todas as aplicações passarem a confiar nela. Java, muitas instalações de Python, Node.js e builds do curl podem ter seu próprio bundle de CAs ou keystore, cada um com localização de arquivo e variável de ambiente próprias, então um erro de certificado pode persistir após a correção no nível do SO.
Legível por máquina: JSON