14.4.4. Certificados assinados por CA (publicamente confiáveis)

Os certificados autoassinados funcionam quando controla ambas as extremidades. Se, em vez disso, clientes arbitrários (browsers, telemóveis, software de terceiros) tiverem de se ligar à câmara sem serem instruídos a confiar num certificado personalizado, o certificado tem de ser assinado por uma Autoridade de Certificação (CA) pública em que esses clientes já confiem. O código TLS na câmara é idêntico ao caso autoassinado – load_cert_chain com um certificado e uma chave em formato DER – apenas a forma como obtém esse certificado muda.

O ponto mais importante: gera a chave privada você mesmo e ela nunca sai da sua máquina. A CA nunca a vê. O que envia à CA é um pedido de assinatura de certificado (CSR) – um pequeno ficheiro com a sua chave pública e o nome do domínio – e o que recebe de volta é um certificado (a sua chave pública e nome, assinado pela CA). A chave e o certificado são dois ficheiros separados produzidos em dois passos distintos; a CA só manipula sempre a metade pública.

O fluxo geral, tudo feito numa máquina normal (nunca na câmara):

  1. Obtenha um nome de domínio. As CAs públicas certificam um nome DNS que controla (por exemplo, cam.example.com); não emitem para endereços IP simples nem para nomes apenas locais como mycam.

  2. Gere uma chave e um CSR. Um único comando OpenSSL produz a chave privada e o CSR correspondente. Use o mesmo tipo de chave que usaria para um certificado autoassinado (consulte Conceitos: confiança, chaves e formato de ficheiro); ECDSA P-256 é recomendado.

    ECDSA P-256 – recomendado:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    ECDSA P-384 – mais forte, maior/mais lento:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    RSA-2048 – compatibilidade máxima:

    openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    Mantenha domain.key em segredo – este é o ficheiro de chave que acabará por colocar na câmara. domain.csr é o ficheiro que entrega à CA; não contém segredos.

  3. Submeta o CSR e prove que controla o domínio. É aqui que os dois percursos comuns diferem:

    • Uma CA ACME automatizada como a Let’s Encrypt, utilizada por uma ferramenta como certbot ou acme.sh, realiza os passos 2 e 3 por si: gera a chave, constrói o CSR, responde ao desafio automaticamente (HTTP-01: serve um token pela porta 80 no domínio, ou DNS-01: publica um registo TXT no seu DNS) e escreve os ficheiros finais.

    • Uma CA comercial (adquirida diretamente ou através de um revendedor de domínios/alojamento): cola o texto de domain.csr num formulário web e prova o controlo respondendo a um email de validação, publicando um registo DNS ou colocando um ficheiro num servidor web para esse domínio. Após validação, descarrega os ficheiros emitidos.

  4. Recolha os ficheiros emitidos. Para compreender o que recebe, ajuda saber que os certificados formam uma cadeia de confiança: o certificado do seu domínio é assinado por uma CA intermédia, que por sua vez é assinada por uma CA raiz. Cada elo garante o que está abaixo. Fica com:

    • A sua chave privada (do passo 2). A CA nunca a teve; fica na sua máquina e é a chave que eventualmente coloca na câmara.

    • O certificado folha – também chamado de certificado entidade-final ou servidor. Este é o certificado para o seu domínio específico (cam.example.com): contém a sua chave pública e o seu nome, e é assinado pelo intermédio da CA. Este é o certificado que a câmara apresenta para se identificar.

    • Um ou mais certificados de CA intermédia (a «cadeia» ou «pacote CA»). Uma CA não assina a sua folha diretamente com a raiz – a chave da raiz é mantida offline e com proteção reforçada – por isso assina com um intermédio, que é ele próprio assinado pela raiz. O intermédio é o elo que liga a sua folha à raiz.

    O certificado raiz é a âncora de confiança: um certificado autoassinado pertencente à CA que se encontra no topo da cadeia. Não lhe é fornecido e nunca o implementa, porque todos os clientes já o têm – sistemas operativos, browsers, telemóveis e runtimes de linguagens são fornecidos com um «repositório de confiança» de certificados raiz incorporado. Um cliente confia na sua folha percorrendo a cadeia: já confia na raiz, a raiz garante o intermédio, e o intermédio garante a sua folha. (É exatamente a função que o seu único server.der / cafile desempenha no caso autoassinado – aí você é a sua própria raiz.)

    Um ficheiro fullchain é simplesmente a folha e o(s) intermédio(s) concatenados num único ficheiro, a folha primeiro, deliberadamente sem a raiz (enviar a raiz seria inútil – um cliente apenas confia nas raízes que já possui). Um servidor normal apresenta toda esta fullchain para que qualquer cliente a possa percorrer. A câmara não consegue: carrega e apresenta um certificado – a folha – e não pode enviar também o(s) certificado(s) intermédio(s) que a CA forneceu.

    Nomes de ficheiros que verá na prática: uma ferramenta ACME como certbot escreve privkey.pem (a sua chave), cert.pem (apenas a folha), chain.pem (apenas o(s) intermédio(s)) e fullchain.pem (folha + intermédio(s)). Uma CA comercial normalmente fornece um .crt para a folha e um .ca-bundle para o(s) intermédio(s), sendo o .key o que gerou você mesmo.

  5. Converta e copie. Converta a chave privada e o certificado folha para DER e copie-os para a câmara exatamente como em Certificados autoassinados. A câmara apresenta-os então como o seu certificado de servidor e os clientes normais aceitam a ligação automaticamente, porque já confiam na CA – não é necessária nenhuma configuração do lado do cliente.

Dica

Na prática, a câmara a apresentar apenas a folha (e nunca os intermédios) funciona assim:

  • Os clientes que já têm o intermédio da CA em cache – os browsers principais e as bibliotecas HTTPS geralmente têm – completam a cadeia eles próprios e ligam-se sem problemas.

  • Os clientes que dependem do servidor para fornecer o intermédio falharão o handshake com a câmara.

Se todos os clientes possíveis tiverem de ter sucesso, não termine o TLS público diretamente na câmara. Coloque um gateway / proxy reverso à sua frente que sirva a cadeia completa para o exterior, e faça o proxy comunicar com a câmara através do fluxo autoassinado descrito acima.