diff --git a/Defini%C3%A7%C3%A3o-do-Campo-Common-Name-%28CN%29-em-Certificados-Digitais.md b/Defini%C3%A7%C3%A3o-do-Campo-Common-Name-%28CN%29-em-Certificados-Digitais.md
new file mode 100644
index 0000000..ad6a3a3
--- /dev/null
+++ b/Defini%C3%A7%C3%A3o-do-Campo-Common-Name-%28CN%29-em-Certificados-Digitais.md
@@ -0,0 +1,160 @@
+# 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:
+
+```text
+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:
+
+```text
+router.localmws
+switch-core.internal
+10.0.4.1
+```
+
+Ou ainda:
+
+```text
+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:
+
+```text
+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:
+
+```text
+MWS Rede Local CA
+MAISWEBSITES Root CA
+Empresa XYZ Internal PKI
+```
+
+---
+
+## Boas Práticas
+
+### Limite de caracteres
+
+O campo CN possui limite aproximado de:
+
+```text
+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:
+
+```text
+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:
+
+```text
+DNS: prox2.localmws
+DNS: prox2
+IP: 10.0.4.241
+```
+
+---
+
+### Ambientes privados
+
+Em redes internas é permitido utilizar domínios não públicos como:
+
+```text
+.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.