Definição do Campo Common Name (CN) em Certificados Digitais

Este documento descreve como definir corretamente o campo Common Name (CN) durante a emissão de certificados digitais em uma infraestrutura de Autoridade Certificadora (CA) privada.

A configuração adequada do CN contribui para a coerência da identidade digital dos serviços e facilita a administração operacional da infraestrutura PKI.

Objetivo

Definir o identificador principal do recurso protegido pelo certificado digital.

Uso do Common Name conforme o tipo de certificado

Certificados de Servidor Web

Para serviços HTTPS (como servidores Apache, Nginx, IIS, OpenMediaVault ou Proxmox), o campo CN deve conter o nome totalmente qualificado do host (FQDN).

Exemplo:

openmediavault.localmws
prox2.localmws
intranet.empresa.internal

Certificados para Dispositivos de Rede

Pode ser utilizado:

nome DNS interno do equipamento
endereço IP estático

Exemplo:

router.localmws
switch-core.internal
10.0.4.1

Ou ainda:

router
switch-core
10.0.4.1

Certificados para Usuários

Utilizados em:

autenticação por certificado
VPN
acesso a sistemas internos

O CN normalmente contém:

Nome completo
ou
Endereço de e-mail

Certificado da Autoridade Certificadora (CA)

O certificado da própria CA deve conter um nome institucional claro.

Exemplo:

MWS Rede Local CA
MAISWEBSITES Root CA
Empresa XYZ Internal PKI

Boas Práticas

Limite de caracteres

O campo CN possui limite aproximado de:

64 caracteres

Nomes muito longos podem ser truncados por ferramentas ou bibliotecas criptográficas, causando problemas de validação.

Uso obrigatório do Subject Alternative Name (SAN)

Em navegadores modernos e sistemas atuais, o campo CN é considerado legado para validação de hostname.

A identificação do servidor é realizada prioritariamente por meio da extensão:

Subject Alternative Name (SAN)

Portanto:

o hostname presente no CN deve também ser incluído no SAN
todas as variações de acesso devem ser listadas

Exemplo:

DNS: prox2.localmws
DNS: prox2
IP: 10.0.4.241

Ambientes privados

Em redes internas é permitido utilizar domínios não públicos como:

.local
.internal
.lan
.localmws

Entretanto, é essencial que o serviço de DNS interno resolva corretamente esses nomes.

Falhas de resolução DNS podem ser interpretadas como problemas de certificado.

Observação Importante

Embora o campo CN ainda seja utilizado por diversos sistemas e ferramentas, a prática moderna recomenda tratar o SAN como fonte primária de identidade do serviço.

Manter coerência entre CN e SAN contribui para:

melhor interoperabilidade
troubleshooting mais simples
clareza na documentação da PKI

Conclusão

O preenchimento adequado do Common Name deve refletir a identidade lógica do recurso protegido pelo certificado.

Mesmo em infraestruturas privadas, a adoção de padrões consistentes na definição de CN e SAN facilita a escalabilidade, a governança operacional e a integração entre diferentes plataformas.