Toda instalação de Proxmox começa com um certificado autoassinado, e todo administrador aprende a clicar em "avançar mesmo assim". Depois de algumas semanas, o clique é automático — e é exatamente aí que está o problema real, que não é estético.
Uma equipe treinada a ignorar aviso de certificado no hipervisor vai ignorar o aviso quando ele for legítimo. O dia em que alguém interceptar a conexão com a interface de gestão, o navegador vai avisar, e ninguém vai reparar. O certificado válido não serve só para ficar bonito: ele devolve significado ao alerta.
Por que o certificado padrão existe
O Proxmox gera uma autoridade certificadora interna na instalação e emite certificados para os nós a partir dela. Isso é necessário para o funcionamento do cluster: os nós conversam entre si por TLS e precisam confiar uns nos outros desde o primeiro minuto.
Esse certificado interno funciona bem para o tráfego entre nós. O que ele não faz é ser reconhecido pelo navegador do seu time — porque a autoridade que o emitiu não está na lista de confiança de ninguém.
Você tem, portanto, dois caminhos: obter um certificado de uma autoridade pública, ou distribuir a sua própria autoridade interna para as máquinas do time. Os dois são legítimos, e a escolha depende de o nó ter ou não um nome público.
Caminho 1: ACME com autoridade pública
O Proxmox tem cliente ACME embutido, na interface, sem precisar instalar nada. É o caminho mais direto para obter certificado gratuito com renovação automática.
O requisito que costuma travar é este: o nome do nó precisa existir no DNS público. pve01.local não serve. Você precisa de algo como pve01.suaempresa.com.br com registro público — mesmo que o endereço apontado seja privado, o que é permitido e comum.
Existem dois métodos de validação, e a escolha entre eles resolve ou não o caso de ambiente interno.
Validação HTTP-01
A autoridade acessa o seu nó pela porta 80 para confirmar que você o controla.
Funciona quando o nó é alcançável pela internet na porta 80 — cenário de provedor de cloud, mas não de hipervisor corporativo atrás de firewall. E expor a porta 80 do hipervisor à internet só para validar certificado é um preço alto: você está abrindo a superfície mais crítica do ambiente para resolver um problema que tem solução melhor.
Validação DNS-01
A autoridade verifica um registro TXT no seu domínio. O nó não precisa ser alcançável de fora — basta que o Proxmox consiga criar o registro no seu provedor de DNS.
É a opção certa para praticamente todo ambiente corporativo, e é a que recomendamos por padrão. O Proxmox suporta dezenas de provedores de DNS por meio de plugins, e a configuração é uma credencial de API do seu provedor.
Ela também resolve dois casos que o HTTP-01 não resolve: nó sem endereço público e certificado curinga, que cobre todos os nós do cluster com uma emissão só.
Caminho 2: autoridade interna própria
Se o ambiente é totalmente isolado, sem DNS público e sem intenção de ter, a alternativa é emitir certificados a partir de uma autoridade interna e distribuir o certificado raiz dessa autoridade para os navegadores e sistemas do time — por política de grupo, por gerenciamento de dispositivo ou manualmente.
Feito isso, o navegador confia e o aviso some, com o mesmo benefício de segurança.
O trabalho aqui é a gestão do ciclo de vida: lembrar de renovar antes de vencer, e ter processo para distribuir o raiz em máquina nova. É perfeitamente viável, e é a razão pela qual, quando existe DNS público, o caminho ACME costuma dar menos trabalho a longo prazo.
O passo a passo com ACME e DNS-01
- Garanta o nome no DNS público para cada nó, ou defina o domínio para o certificado curinga.
- Crie a conta ACME na configuração do datacenter, com um e-mail de contato válido — é para lá que vão os avisos de expiração se a renovação falhar.
- Cadastre o plugin de DNS do seu provedor, com a credencial de API. Crie uma credencial com o menor escopo possível: idealmente restrita a criar registros TXT no domínio de validação.
- Configure o domínio no nó, escolhendo o plugin de DNS.
- Solicite o certificado e acompanhe a tarefa.
- Repita para cada nó, ou use curinga.
- Confirme a renovação automática. O Proxmox renova antes do vencimento por tarefa agendada — e o ponto seguinte é o que garante que você saiba se isso parar de funcionar.
Monitore a expiração — sempre
Renovação automática é excelente até o dia em que a credencial de API do DNS expira, o provedor muda a API ou alguém revoga a chave. Aí a renovação falha em silêncio e, semanas depois, o certificado vence.
Coloque a data de expiração do certificado no seu monitoramento, com alerta a 21 dias. É uma verificação trivial de implementar e é a diferença entre corrigir com calma e descobrir pelo time reclamando na segunda-feira.
Vale checar também: alguns fluxos exigem reiniciar o serviço da interface para que o certificado novo seja apresentado. Confirme que o seu ambiente faz isso corretamente — teste a renovação forçada uma vez e observe.
Não esqueça do Proxmox Backup Server
O PBS tem o mesmo cliente ACME e o mesmo problema de certificado autoassinado. E ele costuma ser esquecido, porque ninguém acessa a interface dele com frequência.
Certificado válido no PBS importa por um motivo adicional ao estético: quando você adiciona o datastore ao cluster, a impressão digital do certificado é registrada. Trocar o certificado depois exige atualizar essa informação, e é uma fonte conhecida de backup que para de funcionar silenciosamente. Resolva o certificado antes de conectar, e verifique o backup depois de qualquer troca.
Onde o certificado válido não substitui proteção
Certificado cifra o tráfego e prova a identidade do servidor. Ele não controla quem acessa. A interface de gestão continua precisando de:
- Acesso restrito por rede, idealmente via VPN, nunca exposta à internet.
- Firewall liberando a porta apenas a partir da rede de administração.
- Autenticação de dois fatores nas contas administrativas.
- Usuários nominais, não root compartilhado.
Interface de gestão do hipervisor exposta na internet, mesmo com certificado válido e senha forte, é um risco que não se justifica.
Erros comuns
- Conviver com o aviso e treinar a equipe a ignorar alerta de segurança.
- Rodar script da internet para remover o aviso em vez de resolver o certificado.
- Expor a porta 80 do hipervisor à internet só para validar com HTTP-01.
- Usar nome
.localou interno e não entender por que o ACME falha. - Credencial de API do DNS com permissão ampla em vez do escopo mínimo.
- E-mail de contato da conta ACME inválido, sem receber o aviso de falha.
- Não monitorar a data de expiração, e descobrir o vencimento pelo time.
- Esquecer o Proxmox Backup Server e quebrar o backup ao trocar o certificado.
- Achar que certificado válido dispensa VPN, firewall e 2FA.
- Emitir um certificado por nó na mão quando um curinga resolveria.
O ganho real
Resolver o certificado leva uma tarde e entrega três coisas: o aviso do navegador volta a significar alguma coisa, o tráfego com a interface de gestão fica adequadamente protegido, e integrações que consomem a API param de precisar da opção que ignora verificação — que é, por sinal, outro hábito perigoso que se instala em ambientes com certificado autoassinado.
Onde a Solvefy/Cloud entra
Como parceiros oficiais Proxmox, configuramos ACME com validação por DNS em todos os nós e no Proxmox Backup Server, com certificado curinga quando faz sentido, credencial de API com escopo mínimo, renovação automática validada por teste forçado e alerta de expiração no monitoramento. E revisamos junto o entorno — VPN, firewall, 2FA e usuários nominais —, porque certificado é uma camada, não a proteção inteira.
Sua equipe ainda clica em "avançar mesmo assim" no hipervisor? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.