Você já deve ter ouvido em algum lugar que precisa colocar um certificado, ou habilitar o SSL em algum lugar, certo? A intenção é tornar esse assunto menos abstrato com a intenção de trazer clareza sobre como as coisas funcionam.
Você já dever ter vivenciado, como protagonista ou mero espectador de cenários onde tudo parou de funcionar, sem explicação alguma, e após algum tempo descobriram que eram os certificados que haviam expirado?
Pois bem… hoje você vai entender como e por que, mesmo que não aconteça nada, as coisas sim podem parar de funcionar!
SSL ou TLS?
Hoje em dia o nome SSL (Secure Sockets Layer) é empregado de forma errada, já que está deprecated. Mas ficou na boca do povo e quando falamos em SSL hoje em dia, na verdade queremos dizer TLS (Transport Layer Security).
Desde propagandas que falam de SSL, até papers antigos, o mercado ainda usa o termo SSL. E está tudo bem quanto a isso. Essa informação só está aqui para poder te ajudar a entender que ao falar de um, na verdade estamos falando de outro.
Como funcionam os certificados
Um certificado precisa de um emissor. Alguma entidade emite certificados. Quem na arquitetura dos certificados, quem emite um certificado é um CA (Certificate Authority) ou Autoridade Certificadora.
E você pode se questionar: – Orabolas, então eu preciso comprar uma CA ou instalar uma CA em minha infra, certo?
– Não!
Nenhum computador por default reconhece nenhuma CA. São nossos sistemas operacionais que trazem uma lista de CA’s em sua instalação, e os updates de segurança atualizam essas CA’s.
E aí você pode me questionar: – Então meu windows tem uma lista com todas as CA’s do mundo?
– Não
Na verdade, seu Windows ou seu Linux tem uma lista com os ROOT Certificate Authorities. São certificados-raiz. Esses sim são instalados nos sistemas operacionais e browsers. Todos os demais se comportam diferente.
Vamos à prática, para ficar menos complexo?
Digita https://www.globo.com/ no teu browser.
Clica no cadeado, que fica próximo ou na barra de endereços.
Clica em “Certificado”
Ótimo se você chegou até aqui.
Agora pressiona Windows+R e digita certmgr.msc
Se você caminhar para a mesma pasta que eu fui, verá algo bem parecido.
O que está acontecendo aqui?
Meu browser tentou acessar a globo.com e obteve o certificado.
Como ele não reconhece globo.com como um Root CA, ele foi buscar quem emitiu, e achou a RapidSSL.
Como ele não reconhece RapidSSL como um Root CA , ele foi buscar quem emitiu, e achou a DigiCert.
Como ele reconhece a DigiCert como Trusted Root CA, que está na lista de autoridades confiáveis, ele aceita o certificado como válido.
Não está claro pra mim em que momento do fluxo os certificados intermediários são de fato validados. Esse caminho que eu fiz é sobre a validação do Root CA. Não sei se antes de chegar no Root CA o browser já fez as validações intermediárias ou se só depois de garantir que o Root CA é reconhecido, o browser faz as validações da cadeia inteira.
A utilidade dessa informação: De qualquer forma esse detalhe é irrelevante para o contexto desse post, mas talvez possa ser útil para entender qual foi a estratégia utilizada em um cenário tão cotidiano, como os browsers. Saber o que ele faz primeiro pode nos dar a direção do que fazer primeiro em uma navegação em grafos complexos. Talvez essa informação possa ser útil para a nossa própria tomada de decisão.
Simples assim?
Isso se chama hierarquia das CA’s
Porque isso é importante?
Porque quando você cria um devcert no windows, o que a Microsoft está fazendo é colocando somente no seu computador, você como CA. Isso quer dizer que só vai funcionar para você mesmo, no teu browser. E esse certificado de desenvolvimento, não é válido para mais ninguém que não seja o teu sistema operacional.
Nem um container dentro do seu computador, é capaz de herdar essa configuração. Ele no máximo usar um certificado auto-assinado gerado no Windows, para hospedar a aplicação. De resto, é necessário configuração especial.
Falando em containers….
Um dos passos para instalar o docker é instalar o ca-certificates (Certificados das Autoridades Certificadoras). Instalação do Docker no Ubuntu.
Podemos ir além e entender o que há no pacote ca-certificates.
E como se não bastasse temos a instalação do ca-certificates nas imagens também, afinal, o container também pode precisar chamar endpoints com TLS, não é?
Aqui está nossa busca, encontrando incríveis 218,726 referências a ca-certificates em dockerfiles.
Expiração
Uma informação relevante é que updates das Root CA’s são necessários de tempos em tempos, inclusive nos últimos anos vimos 2 vezes os serviços do azure não conseguirem propagar seus certificados para o ca-certificates a tempo da release certa e com o descasamento, muitas aplicações não conseguiram usar o Azure Container Registry por um ou dois dias.
CA’s Corporativas
Não é incomum vermos parques inteiros de servidores e devices seguros que não se comunicam com a internet, mais raro, mas ainda existem aqueles que não sofrem atualização.
Nesses casos, você tem como, via política do Active Directory, propagar certificados raiz de um emissor local, por toda a sua rede, fazendo com que computadores da sua rede doméstica ou corporativa reconheçam um determinado Root CA como válido. Um Root CA novinho em folha, teu, que ninguém que está fora da tua rede reconhece.
Porque entender esses fundamentos é tão importante?
Porque algumas coisas param de funcionar, simplesmente pelo passar do tempo.
Com zero modificações, tudo estável, absolutamente ninguém sequer olhou para aquele ambiente, e simplesmente para de funcionar inesperadamente. Eu vi isso acontecer mais de uma dezena de vezes na época do WCF, quando desenvolvedores espertinhos achavam que usar certificado era uma boa solução para autenticar serviços. No entanto nunca documentaram nem colocaram em documento algum a motherfucker data de expiração da porcaria dos certificados.
Como os certificados expiram, é certo que em algum momento, um desktop, servidor ou container sem update, que acesse recursos com TLS pode parar de funcionar simplesmente por falta de atualização. Sem que haja nenhuma intervenção humana em lugar algum.
Porque se você publica aplicações na internet, precisa entender a lógica por trás dos certificados para não achar que pode emitir um certificado auto-assinado (self-signed certificate) e usar em uma API pública por exemplo.
Porque isso te ajuda a entender a lógica do Let’s Encrypt, que vai validar se você é o dono do domínio de fato, para assegurar se pode ou não gerar seu certificado.
Por exemplo, o gago.io é um domínio certificado pelo Let’s Encrypt, o ROOT CA é o DST Root CA X3 e na minha máquina o certificado desse Root CA vence dia 30/SETEMBRO/2021 (falta 1 mês). Isso quer dizer que nos próximos 30 dias, é necessário chegar via Windows Update uma atualização desse certificado.
Essa é a dinâmica dos certificados e sabendo disso, fica mais fácil não passar perrengue no dia-a-dia. As vezes as coisas simplesmente param de funcionar, e nós ficamos achando que tecnologia é exoterismo, ou não parte de uma lógica racional.
Não, nunca! Sempre há um bom motivo racional e previsível para as coisas darem errado. O que nos falta é visão do todo para entender quais são esses elementos. Eu to até vendo a quantidade de gente que vai esbarrar nesse post aqui e não vai ler por achar chato ou desinteressante. Mas faz parte, é eu o criei para que pudesse referenciar no futuro, em respostas técnicas sobre algum problema relacionado a certificados ou que pode ter certificado como core da questão.
Links úteis:
Microsoft Trusted Root Certificate: Program Requirements
Certification Authority Guidance
Release notes – Microsoft Trusted Root Certificate Program
PS:
Se você navegar nos links acima, verá que o Microsoft Trusted Root Certificate Program trabalha um modelo mais dinâmico de certificados, onde a obtenção e validação inicial pode ser feita tardiamente, por meio de servidores da própria Microsoft. Mas isso é irrelevante ao contexto que estamos trabalhando aqui no texto. A ideia é mostrar para desenvolvedores e arquitetos, fundamentos que ajudem a entender o ecossistema ao qual já fazem parte. Não poderia deixar de fazer essa nota de rodapé, mas também não é muito relevante abordar nesse nível de profundidade.
Muito bom.