Gerenciamento de certificado SSL: do caos em centenas de servidores a uma solução centralizada

O que pode estar por trás das palavras "maior escola online da Europa"? Por um lado, são mil aulas por hora, 10 mil professores, 100 mil alunos. E para mim, um engenheiro de infraestrutura, isso também inclui mais de 200 servidores, centenas de serviços (micro e não muito), nomes de domínio do 2º ao 6º nível. Em todos os lugares você precisa de SSL e, consequentemente, de um certificado.



Na maioria das vezes, usamos certificados Let's Encrypt. Suas vantagens são que são gratuitas e o recebimento é totalmente automatizado. Por outro lado, eles têm uma característica: validade curta - apenas três meses -. Portanto, eles precisam ser atualizados com frequência. Tentamos automatizá-lo de alguma forma, mas ainda havia muito trabalho manual e algo estava constantemente quebrando. Há um ano, criamos um método simples e confiável para atualizar essa pilha de certificados e, desde então, esquecemos esse problema.

De um certificado em um servidor a centenas em vários data centers


Era uma vez apenas um servidor. E nele vivia um certbot, que trabalhava sob a coroa. Então, um servidor parou de lidar com a carga, e outro servidor apareceu. E então mais e mais. Cada um deles tinha seus próprios certificados com seu próprio conjunto exclusivo de nomes e, em todo lugar, era necessário configurar sua atualização. Em algum lugar durante a extensão, eles copiaram os certificados existentes, mas esqueceram a atualização.

Para obter um certificado Let's Encrypt, você deve confirmar a propriedade do nome de domínio especificado no certificado. Isso geralmente é feito com uma solicitação HTTP reversa.


Aqui estão algumas dificuldades padrão que encontramos quando crescemos:

  • : . .
  • HTTP. , . . - LDAP. - . .

Em alguns lugares, os certificados autoassinados são usados ​​há algum tempo, e isso parecia uma boa solução nos locais em que a autenticação não é necessária - por exemplo, para testes internos. Para impedir que o navegador relate constantemente um "site suspeito", você só precisa adicionar nosso certificado raiz à lista de confiáveis, e o ponto principal está no chapéu. Mas dificuldades posteriores também surgiram aqui.



O problema é que, no BrowserStack, usado pelos testadores, é impossível adicionar um certificado à lista confiável de pelo menos iPad, Mac e iPhone. Portanto, os testadores tiveram que aturar avisos constantemente pop-up sobre sites perigosos.

Procure uma solução


Obviamente, antes de tudo, você precisa fazer o monitoramento para descobrir os certificados que terminam não quando já terminaram, mas um pouco antes. Ah bem. O monitoramento é que agora sabemos que os certificados terminarão em breve aqui e ali. E agora o que eu posso fazer?


Big Ear é um bot antigo que não estraga um certificado.

E vamos usar certificados curinga? Vamos! Vamos Criptografar já os emite. É verdade que você precisará configurar a confirmação da propriedade do domínio por meio do DNS. E nosso DNS vive na AWS Route53. E você precisa decompor os detalhes de acesso na AWS em todos os servidores. E com o advento de novos servidores, copie toda essa economia lá também.

Bem, nomes de terceiro nível são cobertos por curinga. E o que fazer com os nomes do 4º nível e superior? Temos muitas equipes envolvidas no desenvolvimento de vários serviços. Agora é habitual dividir o front-end e o back-end. E se o front-end obtiver um nome de terceiro nível como service.skyeng.ru , o back-end tentará fornecer o nome api.service.skyeng.ru . Hmm, talvez eles os proíbam de continuar fazendo isso? Boa ideia! E o que fazer com dezenas de existentes? Poderia ser com uma mão de ferro para levá-los todos em um nome de domínio? Substitua todos esses nomes de níveis diferentes por URLs como skyeng.ru/service. Tecnicamente, essa é uma opção, mas quanto tempo leva? E como as empresas podem justificar a necessidade de tais ações? Temos mais de 30 equipes de desenvolvimento, convencemos a todos - levará pelo menos seis meses. E estamos criando um único ponto de falha. Goste ou não, esta é uma decisão controversa.

Que outras idéias existem? .. Talvez um certificado possa ser feito onde incluímos tudo-tudo-tudo? E vamos instalá-lo em todos os servidores. Essa pode ser a solução para nossos problemas, mas o Let's Encrypt permite que você tenha apenas 100 nomes no certificado e já temos mais de um microsserviço.

O que fazer com os testadores? Eles não criaram nada, mas reclamam constantemente. Tudo besteira, exceto as abelhas. As abelhas também são lixo, mas existem muitas. Cada desenvolvedor ou testador recebe um servidor de teste - nós os chamamos de teste. Testes não são abelhas, mas já existem mais de cem deles. E para cada um, todos os projetos são implantados. Isso é tudo. E, para venda, você precisa de N certificados, então há a mesma quantidade para cada teste. Até agora, eles são autoassinados. Seria ótimo substituí-los por reais ...

Dois manuais e uma fonte de verdade


O cisne, o câncer e o lúcio não levarão o carrinho para lugar nenhum. Precisamos de um único centro de controle de servidor. No nosso caso, isso é Ansible. Certbot em todos os servidores é mau. Deixe todos os certificados serem armazenados em um só lugar. Se em algum lugar alguém precisar de um certificado, vá até esse local e pegue a versão mais recente da prateleira. E garantiremos que os certificados estejam sempre atualizados nesta loja.

Os detalhes de acesso da AWS também estão presentes em apenas um local. Consequentemente, perguntas desaparecem, como a configuração da AWS CLI em um novo servidor, que tem acesso ao Route53 e similares.

Todos os certificados necessários são descritos em um arquivo no Ansible no formato YAML:

    certificates:
      - common_name: skyeng.ru
        alt_names:
          - *.skyeng.ru
      - common_name: olympiad.skyeng.ru
        alt_names:
          - *.olympiad.skyeng.ru
          - api.content.olympiad.skyeng.ru
          - games.skyeng.ru
      - common_name: skyeng.tech
        alt_names:
          - *.skyeng.tech

      .  .  .

Um manual é lançado periodicamente, que passa por esta lista e faz seu trabalho duro - essencialmente a mesma coisa que o certbot:

  • cria uma conta com Let's Encrypt Certificate Authority
  • gera uma chave privada
  • gera um certificado (ainda não assinado) - a chamada solicitação de assinatura de certificado
  • envia uma solicitação de assinatura
  • recebe um desafio de DNS
  • coloca registros recebidos no DNS
  • envia uma solicitação de assinatura novamente
  • e, tendo finalmente recebido o certificado assinado, o coloca na loja.

O Playbook é realizado uma vez por dia. Se ele não pôde renovar nenhum certificado por qualquer motivo - seja problemas de rede ou alguns erros do lado do Let's Encrypt - isso não é um problema. Será atualizado na próxima vez.

Agora, quando o SSL é necessário em um host de serviço, você pode acessar este repositório e obter alguns arquivos a partir daí - a operação mais simples que o segundo manual desempenha ... Quais certificados são necessários neste host são descritos nos parâmetros desse host, em inventários / host_vars / servidor .yml :

    certificates:
      - common_name: skyeng.ru
        handler: reload nginx
      - common_name: crm.skyeng.ru

      .  .  .

Se os arquivos foram alterados, o Ansible puxa um gancho - é comum reiniciar o Nginx (no nosso caso, esta é a ação padrão). E da mesma maneira, você pode obter certificados de outras CAs que usam o protocolo ACME.

Total


  • Tivemos muitas configurações diferentes. Algo constantemente quebrava. Muitas vezes, eu precisava escalar servidores e descobrir o que havia caído novamente.
  • Agora temos dois manuais e tudo é gravado em um só lugar. Tudo funciona como um relógio. A vida se tornou mais chata.

Teste


Sim, e os testadores com seus testes? Cada desenvolvedor ou testador recebe um servidor de teste pessoal - teste. Atualmente, existem cerca de 200. Eles têm nomes no formato test-y123.skyeng.link , onde 123 é o número do teste. Criar e remover testes é automatizado. Um dos componentes da ação é a instalação de um certificado SSL nele. Um certificado SSL é gerado previamente, com nomes por modelo:

    ssl_cert_pattern:
      - *
      - *.auth
      - *.bill

      .  .  .

Apenas cerca de 30 nomes. Portanto, o certificado vem com nomes

    test-y123.skyeng.link
    *.test-y123.skyeng.link
    *.auth.test-y123.skyeng.link
    *.bill.test-y123.skyeng.link

etc.

Após a demissão do desenvolvedor ou testador, seu teste é excluído. O certificado permanece pronto para uso. É tudo o que está armazenado. Você sabe onde é decomposto em hosts; você mesmo sabe como.

PS


Repositório com código .

Também pode ser interessante ler sobre este tópico como o Stack Overflow mudou para HTTPS :

  • Centenas de domínios de diferentes níveis
  • Websockets
  • Muitas APIs HTTP (problemas de proxy)
  • Faça tudo e não diminua o desempenho

Se você tiver alguma dúvida, escreva nos comentários, terei prazer em responder.

All Articles