\n Cloudflare Origin CA + Full (strict): HTTPS até o servidor de origem // Vilaça Solutions
VSVILAÇA SOLUTIONSTECH LAB // BR
LAB ONLINE
Security // PUBLISHED

Cloudflare Origin CA + Full (strict): HTTPS até o servidor de origem

Como configurar Cloudflare Origin CA com Full (strict) no Nginx e manter HTTPS válido entre visitante, Cloudflare e servidor de origem.

22 de setembro de 2026 · 10 min · Cloudflare / TLS / Nginx / HTTPS / Origin CA

Quando um domínio usa o proxy da Cloudflare, o HTTPS não termina em uma única conexão. Existem dois trechos independentes de TLS:

  1. Visitante → Cloudflare
  2. Cloudflare → servidor de origem

O certificado apresentado ao navegador pertence ao primeiro trecho. Já o segundo precisa de um certificado válido no servidor que executa Nginx, Apache ou outro proxy reverso.

Uma forma prática de proteger esse segundo trecho é usar um Cloudflare Origin CA Certificate e configurar o modo SSL/TLS como Full (strict).

O certificado Origin CA é destinado à comunicação entre a Cloudflare e a origem. Ele não substitui um certificado público comum quando o servidor é acessado diretamente por navegadores fora do proxy da Cloudflare.

Por que usar Full (strict)

A Cloudflare oferece diferentes modos de conexão com a origem. Para uma configuração de produção, o objetivo deve ser manter TLS nos dois trechos e validar o certificado apresentado pelo servidor de origem.

No modo Full (strict), a Cloudflare espera uma conexão HTTPS válida com a origem e valida o certificado apresentado.

Isso evita uma situação comum: o navegador mostra HTTPS, mas a conexão da Cloudflare até o servidor segue sem validação adequada.

O fluxo fica assim:

Navegador
   |
   | HTTPS
   v
Cloudflare
   |
   | HTTPS + validação do certificado da origem
   v
Nginx / servidor de origem

Antes de começar

Você precisa de:

  • um domínio gerenciado pela Cloudflare;
  • o registro DNS com proxy da Cloudflare habilitado quando aplicável;
  • acesso administrativo ao servidor de origem;
  • Nginx ou outro servidor web configurado;
  • porta 443 acessível pela Cloudflare.

Faça backup da configuração atual antes de substituir certificados.

1. Gerar o certificado Origin CA

No painel da Cloudflare, abra as configurações de SSL/TLS do domínio e procure a área de certificados de origem.

Crie um novo certificado para os hostnames que o servidor atenderá, por exemplo:

example.com
*.example.com

A Cloudflare fornecerá normalmente:

  • o certificado;
  • a chave privada.

A chave privada deve ser tratada como segredo. Armazene-a somente no servidor necessário e limite suas permissões.

Um layout simples no Linux pode ser:

/etc/nginx/ssl/origin.pem
/etc/nginx/ssl/origin.key

A chave privada deve ter acesso restrito:

sudo chown root:root /etc/nginx/ssl/origin.key
sudo chmod 600 /etc/nginx/ssl/origin.key

2. Configurar o Nginx

Em um server block HTTPS, a configuração mínima aponta para o certificado e a chave:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/ssl/origin.pem;
    ssl_certificate_key /etc/nginx/ssl/origin.key;

    root /var/www/html;
    index index.html;
}

Antes de recarregar o serviço, valide a sintaxe:

sudo nginx -t

Se o teste terminar sem erro:

sudo systemctl reload nginx

Evite reiniciar diretamente sem testar a configuração. Um erro de sintaxe ou caminho incorreto do certificado pode derrubar o serviço.

3. Ativar Full (strict)

No painel da Cloudflare, configure o modo SSL/TLS para:

Full (strict)

A partir desse momento, a Cloudflare passa a exigir uma origem HTTPS com certificado aceitável para esse modo.

Se a origem estiver mal configurada, a requisição pode retornar erro em vez de degradar silenciosamente para uma conexão menos segura.

4. Validar o lado público

Do lado do visitante, confirme resposta e redirects:

curl -I https://example.com

Para ver mais detalhes da negociação:

curl -Iv https://example.com

O certificado observado pelo cliente será o certificado de borda apresentado pela Cloudflare, não necessariamente o Origin CA instalado no Nginx.

Essa distinção é importante ao diagnosticar problemas.

5. Validar o servidor de origem

Para verificar diretamente o certificado instalado no servidor, consulte a origem pelo IP usando SNI.

Exemplo:

openssl s_client -connect 203.0.113.10:443 -servername example.com

Para mostrar somente os campos mais úteis:

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

O -servername é relevante porque ambientes com virtual hosts podem servir certificados diferentes dependendo do hostname enviado via SNI.

Erros comuns

Certificado instalado no caminho errado

Se o Nginx não consegue abrir o arquivo:

cannot load certificate

verifique o caminho configurado, permissões e conteúdo do arquivo.

Certificado não cobre o hostname

O certificado deve incluir o hostname utilizado pela Cloudflare para alcançar a aplicação.

Verifique os nomes presentes no certificado:

openssl x509 -in /etc/nginx/ssl/origin.pem -noout -text

Procure a seção Subject Alternative Name.

Full em vez de Full (strict)

O modo Full estabelece HTTPS com a origem, mas o objetivo desta configuração é também validar o certificado. Confirme explicitamente que o painel está em Full (strict).

Acesso direto ao IP apresenta alerta

Isso pode ser esperado com Origin CA. O certificado é criado para hostnames e para uso no trecho Cloudflare → origem.

Não use a ausência de confiança de um navegador acessando diretamente a origem como único critério para concluir que o setup com Cloudflare está quebrado.

Loop de redirect

Loops normalmente aparecem quando aplicação, Nginx e Cloudflare discordam sobre qual protocolo está sendo usado.

Verifique:

  • redirects HTTP → HTTPS;
  • headers encaminhados pelo proxy;
  • configuração da aplicação;
  • regras de redirect na Cloudflare.

Use:

curl -IL https://example.com

para visualizar a sequência completa.

Teste rápido de troubleshooting

Uma sequência prática é:

# DNS público
dig +short example.com

# resposta HTTPS pública
curl -Iv https://example.com

# certificado da origem
openssl s_client -connect IP_DA_ORIGEM:443 -servername example.com

# configuração Nginx
sudo nginx -t

# logs
sudo journalctl -u nginx --since "15 minutes ago"

Essa ordem ajuda a separar problemas de DNS, borda Cloudflare, TLS da origem e configuração local do Nginx.

O Origin CA substitui Let’s Encrypt?

Depende da arquitetura.

Se todo o tráfego HTTPS chega à origem exclusivamente através da Cloudflare, Origin CA é uma opção simples para proteger esse trecho.

Se clientes precisam acessar diretamente o servidor, um certificado público reconhecido por navegadores — como os emitidos por Let’s Encrypt — costuma ser mais apropriado.

Camadas adicionais

Depois de confirmar que Full (strict) funciona corretamente, vale avaliar:

  • restringir a origem para aceitar tráfego somente dos endereços da Cloudflare;
  • usar Cloudflare Authenticated Origin Pulls;
  • manter TLS moderno no Nginx;
  • automatizar monitoramento de disponibilidade;
  • revisar redirects e headers HTTP;
  • proteger a porta SSH separadamente.

Não aplique restrições de firewall aos IPs da Cloudflare sem um plano de atualização das faixas e um método de acesso administrativo fora do tráfego web.

Resumo

Para uma origem atrás da Cloudflare:

1. gerar Origin CA
2. instalar certificado + chave no servidor
3. validar com nginx -t
4. habilitar Full (strict)
5. testar a URL pública
6. testar diretamente a origem com SNI
7. revisar logs e restrições de acesso

O ponto principal é lembrar que existem duas conexões TLS diferentes. Diagnosticar cada trecho separadamente torna problemas de HTTPS, certificados e redirects muito mais fáceis de localizar.