{"id":1631,"date":"2020-06-02T17:58:06","date_gmt":"2020-06-02T15:58:06","guid":{"rendered":"https:\/\/dev.buddydevs.com\/miguel\/ssl-fehler-30-mai-2020\/"},"modified":"2026-09-12T11:57:16","modified_gmt":"2026-09-12T11:57:16","slug":"erro-ssl-30-maio-2020","status":"publish","type":"post","link":"https:\/\/dev.buddydevs.com\/miguel\/pt-br\/ssl-fehler-30-mai-2020\/","title":{"rendered":"Erro SSL 30 de maio de 2020"},"content":{"rendered":"
No dia 30 de maio de 2020, vivenciamos uma situa\u00e7\u00e3o rara na infraestrutura p\u00fablica-chave da Internet: dois dos certificados principais expiraram, sendo cada um deles emitido pela outra autoridade de verifica\u00e7\u00e3o SSL.<\/p>\r\n\r\n\r\n\r\n
Te\u00f3ricamente, isso n\u00e3o \u00e9 nada incomum. Os certificados expiram constantemente (normalmente em um ano ou at\u00e9 mesmo em 90 dias, se voc\u00ea usar o Let\u2019s Encrypt), e os certificados das entidades de certifica\u00e7\u00e3o expiram ap\u00f3s alguns anos. Mas em 30 de maio, a entidade de certifica\u00e7\u00e3o que estava prestes a expirar abordou um problema fundamental que fez com que nossa API n\u00e3o estivesse dispon\u00edvel para alguns de nossos clientes.<\/p>\r\n\r\n\r\n\r\n
No dia 30 de maio, quando os certificados das autoridades de certifica\u00e7\u00e3o expiraram, recebemos pedidos de suporte informando que havia um problema com o certificado do nosso servi\u00e7o. Essa foi uma not\u00edcia inesperada, pois n\u00f3s verificamos cuidadosamente se nossos certificados estavam v\u00e1lidos e n\u00e3o estavam prestes a expirar em um prazo razo\u00e1vel. Uma verifica\u00e7\u00e3o r\u00e1pida no navegador tamb\u00e9m confirmou que tudo parecia estar normal e que a API estava respondendo corretamente.<\/p>\r\n\r\n\r\n\r\n
Ao analisar as estat\u00edsticas da nossa infraestrutura, percebemos que o n\u00famero de chamadas \u00e0 API diminuiu, mas isso estava longe de ser zero, como seria de esperar em caso de falha completa do SSL. Quando as coisas n\u00e3o funcionam completamente, \u00e9 frequentemente mais f\u00e1cil identificar o que n\u00e3o funciona do que em situa\u00e7\u00f5es em que algumas coisas funcionam e outras n\u00e3o.<\/p>\r\n\r\n\r\n\r\n
Uma an\u00e1lise abrangente revelou, finalmente, que tamb\u00e9m outros servi\u00e7os na Internet apresentaram problemas. Rapidamente descobrimos as causas: https:\/\/support.sectigo.com\/articles\/Knowledge\/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020<\/a><\/p>\r\n\r\n\r\n\r\n Esta foi uma situa\u00e7\u00e3o interessante. Existia um caminho v\u00e1lido para a Autoridade de Certifica\u00e7\u00e3o RSA do USERTrust, e tamb\u00e9m existia um caminho expirado. O navegador era capaz de encontrar a cadeia v\u00e1lida, mas a ferramenta n\u00e3o conseguiu encontr\u00e1-la. O teste da Quality SSL Labs mostrou que o sistema funcionava e que a configura\u00e7\u00e3o de certificado funcionava perfeitamente.<\/p>\r\n\r\n\r\n\r\n Nossa equipe iniciou a segunda altera\u00e7\u00e3o de nosso certificado p\u00fablico e tentou restaurar o servi\u00e7o para os clientes remanescentes, e pouco depois do seu lan\u00e7amento confirmou a eles que poderiam retomar o servi\u00e7o. O incidente havia finalmente terminado, e o servi\u00e7o foi restaurado para todos os clientes. Mas por que alguns de nossos clientes perderam o acesso em primeiro lugar, quando at\u00e9 mesmo o verificador de SSL afirma que o certificado \u00e9 v\u00e1lido?<\/p>\r\n\r\n\r\n\r\n O certificado era, de fato, v\u00e1lido, e toda a cadeia de certificados foi gerada de forma razoavelmente correta pela certificadora Comodo\/Sectigo (o armazenamento de certificados durante o fim de semana n\u00e3o \u00e9 uma pr\u00e1tica recomend\u00e1vel). O que n\u00e3o estava previsto era a forma como as bibliotecas de clientes lidar\u00e3o com essa situa\u00e7\u00e3o, principalmente o OpenSSL, que \u00e9 utilizado pela grande maioria do HTTPS no mundo. Ao analisar o incidente, descobrimos um interessante erro do OpenSSL de 2014 que diz:<\/p>\r\n\r\n\r\n\r\n
\r\n\r\n
\r\n