Certificado TLS expirado ou mal configurado TLS certificate expiry / misconfiguration
ID da causa in-cert · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando o certificado do servidor de login, de API ou de patch expira, ou falta o certificado intermediário, a conexão TLS dos clientes que se conectam a partir desse momento falha.
Por quê Certificado com validade vencida, servidor que envia a cadeia sem o certificado intermediário, ou data e hora erradas no dispositivo do jogador → Efeito O cliente falha na validação do certificado e encerra a conexão TLS → Na tela Não conecta ou fica em loading infinito no login ou no patch, ou só as funções em HTTPS, como a loja, falham. Quem já estava conectado em geral não é afetado
Logo após login ou manutenção, Ao fazer ações específicas
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Registrar erros de certificado com um código de erro separado das outras falhas de conexão e orientar o jogador, em erro de data orientar o jogador a ativar o ajuste automático de data e hora do dispositivo, se usar pinning de certificado incluir chaves reserva e alinhar o calendário de troca de certificados com a equipe de infraestrutura.
O que fazer (Equipe de infraestrutura)
Rede: quando o TLS termina no load balancer ou na CDN, alertar sobre o estado da renovação automática dos certificados gerenciados e os dias restantes (no ACM, DaysToExpiry), manter os registros DNS de validação. Servidores/SO: quando o TLS termina no servidor, automatizar a renovação e recarregar a configuração depois dela, configurar a cadeia incluindo o certificado intermediário, verificar periodicamente, de fora, a validade restante de cada endereço de login, API e patch, com alerta.
Números de referência
Os certificados da Let’s Encrypt valem 90 dias e a recomendação é renovar a cada 60 dias; o AWS Certificate Manager verifica certificados validados por DNS 45 dias antes de expirarem e renova automaticamente. Se a renovação automática falha em silêncio, as novas conexões são bloqueadas todas de uma vez, exatamente no horário da expiração.
No gráfico
Queda de conexões em massa · Logins bem-sucedidos, erros de handshake TLS
Onde olhar
Ver com openssl s_client -connect HOST:443 -showcerts a lista de certificados que o servidor realmente envia e conferir a data de expiração (notAfter) de cada um com openssl x509 -noout -enddate. Se o TLS termina no load balancer, número de erros de negociação TLS (no AWS ALB e NLB, ClientTLSNegotiationErrorCount) e de logins bem-sucedidos
Confirma se
A data de expiração já passou ou falta o certificado intermediário na lista enviada pelo servidor, e o início dos erros coincide com o horário de expiração ou de troca do certificado
Descarta se
Lista de certificados e datas de expiração normais, mas só alguns jogadores falham: verificar a data e hora do dispositivo deles ou a lista de certificados raiz de um SO antigo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Uma configuração sem o certificado intermediário pode parecer normal quando aberta no navegador do PC. O navegador lembra certificados intermediários recebidos de outros sites e preenche a lacuna, mas clientes sem essa memória, como apps Android, falham. A validade também está encurtando. A Let’s Encrypt pretende reduzir a validade padrão para 64 dias em 2027 e 45 dias em 2028; uma configuração fixa de renovação a cada 60 dias terá só quatro dias de folga com certificados de 64 dias e passará da expiração com os de 45 dias. O AWS Certificate Manager também não renova automaticamente certificados importados, e a renovação falha se o registro DNS de validação for apagado. O login bloqueado se parece com “Falha ou lentidão no DNS”, mas no problema de certificado a falha acontece no handshake TLS, depois de o endereço do servidor ser encontrado, e o início coincide com o horário de expiração ou de troca do certificado.
FAQLet's Encrypt Validade padrão do certificado de 90 dias, renovação recomendada a cada 60 dias
Decreasing Certificate Lifetimes to 45 DaysLet's Encrypt Reduz a validade padrão para 64 dias a partir de fevereiro de 2027 e 45 dias a partir de fevereiro de 2028; renovar em intervalo fixo de 60 dias deixa de bastar, e a recomendação passa a ser renovar por volta de dois terços da validade
Renewal for domains validated by DNSAWS 45 dias antes da expiração, verifica se o certificado está em uso em um serviço da AWS e se o registro CNAME de validação existe, e renova automaticamente; se não conseguir validar, avisa 30, 15, 7, 3 e 1 dia antes da expiração
Supported CloudWatch metricsAWS DaysToExpiry: dias restantes até a expiração do certificado, publicada duas vezes por dia até expirar
Security with network protocolsAndroid (Google) Se o servidor envia a cadeia sem o certificado intermediário, apps Android falham com SSLHandshakeException, mas o navegador do PC pode completá-la com intermediários guardados e não dar erro; verificar com openssl s_client a cadeia que o servidor envia
Network security configurationAndroid (Google) Com pinning de certificado, é preciso incluir chaves reserva para troca de chave ou de CA; sem isso, as conexões ficam bloqueadas até o app ser atualizado
openssl-s_clientOpenSSL -showcerts: mostra a lista de certificados enviada pelo servidor na ordem em que foi enviada (não é a cadeia validada)
openssl-x509OpenSSL -enddate: imprime a data de expiração do certificado (notAfter); -checkend: verifica se expira dentro do número de segundos informado
CloudWatch metrics for your Application Load BalancerAWS ClientTLSNegotiationErrorCount: número de conexões que não conseguiram estabelecer a sessão TLS, como quando o cliente falha na validação do certificado do servidor e encerra a conexão