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

Certificados autoassinados funcionam quando você controla ambas as pontas. Se, em vez disso, clientes arbitrários (navegadores, telefones, software de terceiros) precisarem se conectar à câmera sem serem instruídos a confiar em um certificado personalizado, o certificado precisa ser assinado por uma Autoridade Certificadora (CA) pública na qual esses clientes já confiam. O código TLS na câmera é idêntico ao caso autoassinado – load_cert_chain com um certificado e uma chave em formato DER – só muda como você obtém esse certificado.

O ponto mais importante de todos: você gera a chave privada você mesmo e ela nunca sai da sua máquina. A CA nunca a vê. O que você envia à CA é uma solicitação de assinatura de certificado (CSR) – um pequeno arquivo contendo sua chave pública e seu nome de domínio – e o que você recebe de volta é um certificado (sua chave pública e nome, assinado pela CA). A chave e o certificado são dois arquivos separados produzidos por duas etapas separadas; a CA só lida com a metade pública.

O fluxo geral, todo feito em uma máquina normal (nunca na câmera):

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

  2. Gere uma chave e uma CSR. Um comando OpenSSL produz a chave privada e a CSR correspondente. Use o mesmo tipo de chave que você usaria para um certificado autoassinado (veja Conceitos: confiança, chaves e formato de arquivo); 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 arquivo de chave que você eventualmente colocará na câmera. domain.csr é o arquivo que você entrega à CA; ele não contém segredos.

  3. Envie a CSR e prove que você controla o domínio. É aqui que as duas rotas comuns diferem:

    • Uma CA ACME automatizada como a Let’s Encrypt, operada por uma ferramenta como certbot ou acme.sh, faz as etapas 2 e 3 por você: gera a chave, constrói a CSR, responde ao desafio automaticamente (HTTP-01: servir um token pela porta 80 no domínio, ou DNS-01: publicar um registro TXT em seu DNS) e grava os arquivos finalizados.

    • Uma CA comercial (comprada diretamente ou por meio de um revendedor de domínio/hospedagem): você cola o texto de domain.csr em um formulário web e então prova o controle respondendo a um e-mail de validação, publicando um registro DNS ou colocando um arquivo em um servidor web desse domínio. Uma vez validado, você baixa os arquivos emitidos.

  4. Reúna os arquivos emitidos. Para dar sentido ao que você recebe, ajuda saber que os certificados formam uma cadeia de confiança: o certificado do seu domínio é assinado por uma CA intermediária, que por sua vez é assinada por uma CA raiz. Cada elo garante o que está abaixo dele. Você acaba com:

    • Sua chave privada (da etapa 2). A CA nunca a teve; ela permanece na sua máquina e é a chave que você eventualmente coloca na câmera.

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

    • Um ou mais certificados de CA intermediária (a “cadeia” ou “CA bundle”). Uma CA não assina sua folha diretamente com sua raiz – a chave da raiz é mantida offline e fortemente protegida – então ela assina com um intermediário, que por sua vez é assinado pela raiz. O intermediário é o elo que conecta sua folha até a raiz.

    O certificado raiz é a âncora de confiança: um certificado autoassinado pertencente à CA que fica no topo da cadeia. Você não o recebe e nunca o implanta, porque todo cliente já o possui – sistemas operacionais, navegadores, telefones e runtimes de linguagens vêm com um “armazenamento de confiança” embutido de certificados raiz. Um cliente confia na sua folha percorrendo a cadeia: ele já confia na raiz, a raiz garante o intermediário, e o intermediário garante a sua folha. (É exatamente o trabalho que seu único server.der / cafile faz no caso autoassinado – ali você é a sua própria raiz.)

    Um arquivo fullchain é simplesmente a folha e o(s) intermediário(s) concatenados em um único arquivo, a folha primeiro, deliberadamente sem a raiz (enviar a raiz é inútil – um cliente só confia nas raízes que já possui). Um servidor normal apresenta toda essa fullchain para que qualquer cliente possa percorrê-la. A câmera não pode: ela carrega e apresenta um certificado – a folha – e não pode também enviar o(s) certificado(s) intermediário(s) que a CA lhe deu.

    Nomes de arquivos que você realmente verá: uma ferramenta ACME como certbot grava privkey.pem (sua chave), cert.pem (apenas a folha), chain.pem (apenas o(s) intermediário(s)) e fullchain.pem (folha + intermediário(s)). Uma CA comercial geralmente lhe dá um .crt para a folha e um .ca-bundle para o(s) intermediário(s), sendo o .key aquele que você mesmo gerou.

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

Dica

Na prática, a câmera apresentando apenas a folha (e nunca os intermediários) se desenrola assim:

  • Clientes que já têm o intermediário da CA em cache – navegadores convencionais e bibliotecas HTTPS geralmente têm – completam a cadeia por conta própria e conectam normalmente.

  • Clientes que dependem do servidor para fornecer o intermediário falharão no handshake contra a câmera.

Se todo cliente possível precisa ter sucesso, não termine o TLS público diretamente na câmera. Coloque um gateway / proxy reverso na frente dela que sirva a cadeia completa para o mundo externo, e faça o proxy alcançar a câmera pelo fluxo autoassinado descrito acima.