Resumo

  • Em 9 de novembro de 2015, a Let’s Encrypt fixou a validade máxima em 90 dias e recomendou renovar a cada 60: reduzir a janela de uso de uma chave comprometida ou emissão incorreta e fazer da automação parte essencial do HTTPS.
  • Três dias depois, o anúncio da beta pública informou mais de 11 mil certificados emitidos na beta limitada e reconheceu que a experiência do cliente ainda precisava funcionar bem em plataformas variadas.

Análise

A data de vencimento de um certificado costuma ficar escondida no arquivo até virar um prazo de operação. notAfter é um campo do próprio certificado assinado. A RFC 5280 define o intervalo de validade entre notBefore e notAfter, inclusive. Depois da data final, aquele certificado já não cobre o momento atual; o serviço precisa receber outro.

Em 9 de novembro de 2015, Josh Aas, diretor executivo do Internet Security Research Group, explicou por que a Let’s Encrypt não ofereceria certificados com mais de 90 dias. O limite cumpria dois papéis. Uma chave privada roubada ou um certificado emitido por engano ficaria válido por menos tempo. E a renovação frequente incentivaria a automação, que Aas chamou de essencial para tornar o HTTPS fácil de usar.

A recomendação de renovar no dia 60 dá forma ao compromisso. A Let’s Encrypt não mandava esperar pela última data possível. Restava cerca de um mês até o limite, tempo para um administrador perceber uma falha e agir manualmente. Aas observou que o serviço era novo e que a automação ainda era novidade para muitos assinantes. O prazo deveria ser curto o bastante para tornar o software importante, mas amplo o bastante para permitir uma recuperação humana.

O calendário mostra a fase do serviço. Em 12 de novembro, Aas disse que a beta limitada começara em 12 de setembro e já havia emitido mais de 11 mil certificados. A beta pública estava prevista para 3 de dezembro. No mesmo aviso, a automação aparecia como pilar da estratégia; a experiência do cliente ainda precisava ser confiável em muitas plataformas. A emissão ganhava escala de beta, mas o uso consistente dos clientes ainda exigia trabalho.

O raciocínio da Let’s Encrypt era simples: não dava para esperar que administradores renovassem certificados manualmente para a Web inteira. Quando emissão e renovação fossem automáticas, uma validade menor não aumentaria o trabalho cotidiano de quem mantinha um site. O ganho de segurança e o modelo de operação faziam parte da mesma escolha: o relógio corria mais rápido; o cliente precisava acompanhar o prazo.

A alternativa manual continuava disponível, mas era uma rota de recuperação. O dia a dia passaria a depender do cliente, da tarefa agendada, da compatibilidade com cada plataforma e da instalação efetiva do novo certificado. O dia 60 era uma instrução no calendário. A automação tornaria possível cumpri-la repetidamente em muitos servidores.

O total da beta informa quantos certificados tinham sido emitidos até 12 de novembro. Não mostra quantas renovações deram certo ou falharam. Uma série datada de sucesso das renovações permitiria avaliar se o intervalo manual bastava; os dois anúncios não a publicam.

Fontes