Rumo à automação da emissão de SSL

Muitas vezes temos que trabalhar com certificados SSL. Vamos relembrar o processo de criação e instalação de um certificado (no caso geral para a maioria).

• Encontre um provedor (um site onde possamos comprar SSL).
• Gerar RSE.
• Envie para o seu provedor.
• Verifique a propriedade do domínio.
• Obtenha um certificado.
• Converta o certificado no formato exigido (opcional). Por exemplo, de pem para PKCS #12.
• Instale o certificado no servidor web.

Relativamente rápido, não complicado e compreensível. Esta opção é bastante adequada se tivermos no máximo dez projetos. E se houver mais deles e eles tiverem pelo menos três ambientes? Desenvolvimento clássico - preparação - produção. Nesse caso, vale pensar em automatizar esse processo. Proponho aprofundar um pouco mais o problema e encontrar uma solução que minimize ainda mais o tempo gasto na criação e manutenção de certificados. O artigo conterá uma análise do problema e um pequeno guia para repetição.

Deixe-me fazer uma reserva com antecedência: a principal especialização da nossa empresa é .net e, consequentemente, IIS e outros produtos relacionados ao Windows. Portanto, o cliente ACME e todas as ações para ele também serão descritas do ponto de vista da utilização do Windows.

Para quem isso é relevante e alguns dados iniciais

Empresa K representada pelo autor. URL (por exemplo): empresa.tld

O Projeto X é um dos nossos projetos, durante o qual cheguei à conclusão de que ainda precisamos avançar para a máxima economia de tempo ao trabalhar com certificados. Este projeto possui quatro ambientes: dev, teste, staging e produção. O desenvolvimento e o teste estão do nosso lado, a preparação e a produção estão do lado do cliente.

Uma particularidade do projeto é que ele possui um grande número de módulos que estão disponíveis como subdomínios.

Ou seja, temos a seguinte imagem:

Dev
Test
Staging
Produção

projectX.dev.empresa.tld
projetoX.teste.empresa.tld
estadiamento.projectX.tld
projetoX.tld

módulo1.projectX.dev.company.tld
módulo1.projectX.test.company.tld
módulo1.staging.projectX.tld
módulo1.projectX.tld

módulo2.projectX.dev.company.tld
módulo2.projectX.test.company.tld
módulo2.staging.projectX.tld
módulo2.projectX.tld

...
...
...
...

móduloN.projectX.dev.company.tld
móduloN.projectX.test.company.tld
móduloN.staging.projectX.tld
móduloN.projectX.tld

Para produção, é usado um certificado curinga adquirido, não há dúvidas aqui. Mas cobre apenas o primeiro nível do subdomínio. Da mesma forma, se houver um certificado para *.projectX.tld, ele funcionará para staging.projectX.tld, mas não para module1.staging.projectX.tld. Mas de alguma forma não quero comprar um separado.

E isso se baseia apenas no exemplo de um projeto de uma empresa. E, claro, há mais de um projeto.

Os motivos comuns para todos resolverem esse problema são mais ou menos assim:

• Recentemente Google propôs reduzir o período máximo de validade dos certificados SSL. Com todas as consequências.
• Facilitar o processo de emissão e manutenção de SSL para as necessidades internas dos projetos e da empresa como um todo.
• Armazenamento centralizado de registros de certificados, que resolve parcialmente o problema de verificação de domínio usando DNS e posterior renovação automática, e também resolve a questão da confiança do cliente. Ainda assim, um CNAME no servidor de uma empresa parceira/executora é mais confiável do que em um recurso de terceiros.
• Bom, finalmente, neste caso a frase “é melhor ter do que não ter” cabe perfeitamente.

Selecionando um provedor SSL e etapas preparatórias

Entre as opções disponíveis para certificados SSL gratuitos, foram considerados cloudflare e letsencrypt. O DNS para este (e alguns outros projetos) é hospedado pela cloudflare, mas não sou fã de usar seus certificados. Portanto, foi decidido usar letsencrypt.
Para criar um certificado SSL curinga, você precisa confirmar a propriedade do domínio. Este procedimento envolve a criação de algum registro DNS (TXT ou CNAME) e sua posterior verificação ao emitir um certificado. Linux tem um utilitário - certbot, que permite automatizar parcialmente (ou completamente para alguns provedores de DNS) esse processo. Para Windows de encontrado e verificado Opções de cliente ACME que escolhi WinACME.

E o registro do domínio foi criado, vamos prosseguir para a criação do certificado:

Interessa-nos a última conclusão, nomeadamente, as opções disponíveis para confirmação da propriedade do domínio para emissão de certificado wildcard:

1. Crie registros DNS manualmente (a atualização automática não é suportada)
2. Criando registros DNS usando o servidor acme-dns (você pode ler mais sobre aqui.
3. Criação de registros DNS usando seu próprio script (semelhante ao plugin cloudflare para certbot).

À primeira vista, o terceiro ponto é bastante adequado, mas e se o provedor DNS não suportar essa funcionalidade? Mas precisamos de um caso geral. E o caso geral são os registros CNAME, já que todos os apoiam. Portanto, paramos no ponto 2 e vamos configurar nosso servidor ACME-DNS.

Configurando o servidor ACME-DNS e o processo de emissão de certificados

Por exemplo, criei o domínio 2nd.pp.ua e irei utilizá-lo no futuro.

Requisito obrigatório Para que o servidor funcione corretamente é necessário criar registros NS e A para seu domínio. E o primeiro momento desagradável que encontrei é que o cloudflare (pelo menos no modo de uso gratuito) não permite criar simultaneamente um registro NS e A para o mesmo host. Não que isso seja um problema, mas no bind é possível. O suporte respondeu que seu painel não permite fazer isso. Não tem problema, vamos criar dois registros:

acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.

Nesta fase, nosso anfitrião deve resolver acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

e aqui acme.2nd.pp.ua isso não será resolvido, pois o servidor DNS que o atende ainda não está em execução.

Os registros foram criados, procedemos à configuração e lançamento do servidor ACME-DNS. Ele estará no meu servidor Ubuntu em docker contêiner, mas você pode executá-lo em qualquer lugar onde o golang esteja disponível. O Windows também é bastante adequado, mas ainda prefiro um servidor Linux.

Crie os diretórios e arquivos necessários:

$ mkdir config
$ mkdir data
$ touch config/config.cfg

Vamos usar o vim com seu editor de texto favorito e colar o exemplo em config.cfg configuração.

Para um funcionamento bem-sucedido, basta corrigir as seções geral e API:

[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua" 
nsadmin = "admin.2nd.pp.ua" 
records = 
    "acme.2nd.pp.ua. A 35.237.128.147",
    "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.",                                                                                                                                                                                                  ]
...
[api]
...
tls = "letsencrypt"
…

Além disso, se desejar, criaremos um arquivo docker-compose no diretório principal do serviço:

version: '3.7'
services:
  acmedns:
    image: joohoi/acme-dns:latest
    ports:
      - "443:443"
      - "53:53"
      - "53:53/udp"
      - "80:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

Preparar. Você pode executá-lo.

$ docker-compose up -d

Nesta fase, o anfitrião deve começar a resolver acme.2nd.pp.ua, e um 404 aparece em https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.

$ curl https://acme.2nd.pp.ua
404 page not found

Se isso não aparecer - docker logs -f <container_name> para ajudar, felizmente, os logs são bastante legíveis.

Podemos começar a criar o certificado. Abra o PowerShell como administrador e execute o winacme. Estamos interessados ​​nas eleições:

• M: Criar novo certificado (opções completas)
• 2: Entrada manual
• 2: [dns-01] Crie registros de verificação com acme-dns (https://github.com/joohoi/acme-dns)
• Quando questionado sobre um link para o servidor ACME-DNS, insira a URL do servidor criado (https) na resposta. URL do servidor acme-dns: https://acme.2nd.pp.ua

Na abertura, o cliente emite um registro que precisa ser adicionado ao servidor DNS existente (procedimento único):

[INFO] Creating new acme-dns registration for domain 1nd.pp.ua

Domain:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Type:                   CNAME
Content:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note:                   Some DNS control panels add the final dot automatically.
                           Only one is required.

Criamos o registro necessário e certificamo-nos de que foi criado corretamente:

$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.

Confirmamos que criamos a entrada necessária no winacme e continuamos o processo de criação do certificado:

Como usar o certbot como cliente é descrito aqui.

Isso conclui o processo de criação de um certificado; você pode instalá-lo no servidor web e usá-lo. Se, ao criar um certificado, você também criar uma tarefa no agendador, no futuro o processo de renovação do certificado ocorrerá automaticamente.

Fonte: habr.com