Post

Comparativo de Ferramentas para Certificados Autoassinados no Linux: OpenSSL, certutil, mkcert e Smallstep

Posted
By Gean Martins
26 min read
Comparativo de Ferramentas para Certificados Autoassinados no Linux: OpenSSL, certutil, mkcert e Smallstep

Sumário

1. Introdução

Certificados autoassinados (self-signed) são ativos digitais de segurança onde a chave pública é assinada pela própria chave privada do emissor, em vez de uma Autoridade Certificadora (CA) pública e confiável.

Eles são essenciais em ambientes onde a confiança pública não é necessária ou desejada, como:

  • Desenvolvimento local: Para habilitar HTTPS em localhost e evitar avisos de segurança no navegador.
  • Redes internas: Para criptografar o tráfego entre microsserviços ou servidores em uma rede privada.
  • Testes e prototipagem: Para simular um ambiente de produção com TLS/SSL.

A escolha da ferramenta correta para gerar e gerenciar esses certificados é crucial. Ela afeta a complexidade operacional, a interoperabilidade com outros sistemas e a segurança do ambiente. Este guia compara as quatro principais soluções no ecossistema Linux — OpenSSL, certutil (NSS Tools), mkcert e Smallstep (step-ca) — para ajudar administradores de sistemas, engenheiros DevOps e desenvolvedores a tomar a decisão mais informada.

1.1. Contexto Histórico: Por que tantas ferramentas?

A diversidade de ferramentas para gerenciamento de certificados no ecossistema Linux é um reflexo direto da evolução das necessidades de segurança e das diferentes filosofias de design ao longo do tempo. Cada ferramenta surgiu para resolver um problema específico em seu contexto histórico:

  • OpenSSL (1998): O “canivete suíço” da criptografia, herdado da cultura Unix. Sua força reside no controle granular e na onipresença, sendo a base para a maioria das operações criptográficas, mas sua complexidade reflete sua idade e seu propósito generalista.
  • certutil/NSS (Anos 90): Nascido no ecossistema da Netscape/Mozilla, foi projetado para um propósito específico: gerenciar certificados dentro de um banco de dados seguro para aplicações como navegadores (Firefox) e servidores de diretório, priorizando a gestão centralizada em detrimento da simplicidade de arquivos PEM.
  • mkcert (2017): Uma resposta direta à “dor” do desenvolvimento web moderno. Com a ascensão do HTTPS como padrão e a complexidade de configurar certificados locais confiáveis, o mkcert foi criado com uma única missão: tornar o processo trivial para desenvolvedores em seus ambientes locais.
  • Smallstep (2018): Representa a mentalidade DevOps e de microsserviços. Inspirado pelo sucesso do Let’s Encrypt para a internet pública, o Smallstep visa trazer a mesma automação (via protocolo ACME) para redes internas, tratando certificados como artefatos efêmeros e automatizados.

2. Apresentação das Ferramentas

2.1. OpenSSL

A. Descrição

O OpenSSL é uma biblioteca de software de código aberto que implementa os protocolos SSL e TLS, além de ser uma ferramenta de linha de comando para tarefas de criptografia e gerenciamento de PKI (Public Key Infrastructure). É o padrão de fato no Linux e em sistemas Unix-like, sendo a base para a maioria das operações TLS/SSL.

B. Filosofia de Design

Sua filosofia é ser uma ferramenta de baixo nível e propósito geral. O OpenSSL oferece controle granular sobre cada etapa do processo de criação de certificados e chaves. Ele não impõe um modelo de gerenciamento de CA, exigindo que o usuário tenha um conhecimento aprofundado dos conceitos de PKI, como distinguished names, extensões X.509 e Subject Alternative Names (SAN).

C. Caso de Uso Ideal

O OpenSSL é a melhor escolha quando:

  • É necessário controle total sobre os parâmetros criptográficos.
  • O processo precisa ser automatizado em scripts shell complexos.
  • É preciso criar uma CA raiz simples para assinar múltiplos certificados internos.
  • A ferramenta precisa estar disponível em qualquer sistema Linux sem instalação adicional.

Não é recomendado para iniciantes ou para desenvolvimento local rápido, devido à sua sintaxe complexa e à falta de integração automática com trust stores do sistema operacional.

D. Exemplo Prático Completo (OpenSSL)

O exemplo a seguir cria uma chave privada RSA de 2048 bits e um certificado autoassinado com validade de 365 dias, utilizando o algoritmo de hash SHA-256 e incluindo um SAN para meuapp.local e 127.0.0.1.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# 1. Geração da Chave Privada (RSA 2048 bits)
# O uso de 'pass' é opcional, mas recomendado para chaves de CA.
openssl genrsa -out meuapp.key 2048

# 2. Criação do arquivo de configuração para o certificado (meuapp.cnf)
cat <<EOF > meuapp.cnf
[req]
default_bits = 2048
default_md = sha256
prompt = no
encrypt_key = no
distinguished_name = dn

[dn]
C = BR
ST = SP
L = Sao Paulo
O = Minha Organizacao
OU = TI
CN = meuapp.local

[v3_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = meuapp.local
DNS.2 = *.meuapp.local  ; Exemplo de wildcard
IP.1 = 127.0.0.1
EOF

# 3. Geração do Certificado Autoassinado (usando a chave e o arquivo de config)
openssl req -x509 -new -nodes -key meuapp.key -sha256 -days 365 \
-out meuapp.crt -config meuapp.cnf -extensions v3_ext

# 4. Verificação do Certificado
openssl x509 -in meuapp.crt -text -noout | grep -E 'Signature Algorithm|Public Key|X509v3 Subject Alternative Name'

E. Vantagens

  • Universalidade: Presente em praticamente todas as distribuições Linux.
  • Flexibilidade: Suporta uma vasta gama de algoritmos, formatos (PEM, DER, PKCS#12) e extensões X.509.
  • Padrão da Indústria: Amplamente documentado e aceito.

F. Desvantagens

  • Complexidade: Sintaxe de linha de comando verbosa e não intuitiva.
  • Risco de Erro: Fácil de omitir extensões cruciais (como SAN) ou usar parâmetros criptográficos desatualizados.
  • Gerenciamento de Confiança: Não gerencia automaticamente a confiança no sistema operacional ou navegadores. Para que um certificado OpenSSL seja confiável em todo o sistema (e não apenas no servidor que o utiliza), é necessário um passo manual adicional, como a importação da CA raiz para o trust store do sistema operacional (ex: usando update-ca-certificates no Debian/Ubuntu ou update-ca-trust no RHEL/CentOS/Fedora).

2.2. certutil (NSS Tools)

A. Descrição

O certutil é um utilitário de linha de comando que faz parte do pacote Network Security Services (NSS), um conjunto de bibliotecas criptográficas desenvolvido pela Mozilla. O NSS é usado por produtos como Firefox, Chrome (em algumas plataformas) e sistemas de gerenciamento de identidade corporativa (ex.: FreeIPA).

B. Filosofia de Design

A filosofia do certutil é o gerenciamento centralizado de certificados e chaves em um formato de banco de dados proprietário (NSS DB). Em vez de manipular arquivos PEM diretamente, o usuário interage com um token de segurança (o banco de dados) onde chaves e certificados são armazenados e protegidos. É uma abordagem mais orientada a PKI e a ambientes enterprise.

C. Caso de Uso Ideal

É a ferramenta ideal para:

  • Ambientes Corporativos que utilizam sistemas baseados em NSS (como FreeIPA) para gerenciar uma PKI interna.
  • Administração de perfis de navegadores (Firefox) ou outros aplicativos que dependem do NSS DB.
  • Cenários onde a auditoria e o gerenciamento de um trust store centralizado são requisitos de segurança.

Não é recomendado para operações simples de conversão de formato ou para desenvolvedores que buscam a simplicidade do PEM.

D. Exemplo Prático Completo (certutil)

O exemplo demonstra a criação de um novo banco de dados NSS e a geração de um certificado autoassinado dentro dele.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# 1. Instalação (se necessário, o pacote é geralmente 'nss-tools' ou 'libnss3-tools')
# sudo apt install libnss3-tools  # Debian/Ubuntu
# sudo yum install nss-tools     # RHEL/CentOS/Fedora

# 2. Criação do diretório e do Banco de Dados NSS (DB)
mkdir -p ~/.pki/nssdb
certutil -N -d sql:$HOME/.pki/nssdb --empty-password

# 3. Geração de uma nova chave e certificado autoassinado (dentro do DB)
# O certutil usa o conceito de "token" (o DB) para armazenar.
# -s "CN=meuapp.local" define o Common Name
# -k rsa define o tipo de chave
# -g 2048 define o tamanho da chave
# -v 365 define a validade em dias
certutil -S -n "MeuApp Self-Signed" -s "CN=meuapp.local" \
-t "C,C,C" -d sql:$HOME/.pki/nssdb -k rsa -g 2048 -v 365 \
--keyUsage digitalSignature,keyEncipherment \
--extKeyUsage serverAuth,clientAuth

# 4. Verificação do Certificado (listagem no DB)
certutil -L -d sql:$HOME/.pki/nssdb -n "MeuApp Self-Signed"

E. Vantagens

  • Gerenciamento de PKI: Forte foco em gerenciamento de certificados e chaves em um banco de dados seguro.
  • Integração Enterprise: Usado em soluções de PKI corporativa.
  • Segurança: Chaves privadas são armazenadas de forma mais segura no DB, com suporte a módulos de hardware (HSM).

F. Desvantagens

  • Curva de Aprendizado: Mais complexo e menos intuitivo que o OpenSSL para operações básicas.
  • Formato Proprietário: O formato NSS DB não é diretamente compatível com a maioria dos servidores web (que esperam PEM).
  • Dependência: Requer a instalação do pacote NSS Tools.

2.3. Smallstep (step-ca)

A. Descrição

O Smallstep é um conjunto de ferramentas de código aberto que inclui o step-ca, uma Autoridade Certificadora (CA) privada moderna e leve. Ele foi projetado para simplificar a criação e o gerenciamento de certificados TLS/SSL de curta duração em ambientes internos, utilizando o protocolo ACME (Automatic Certificate Management Environment), o mesmo usado pelo Let’s Encrypt.

B. Filosofia de Design

Sua filosofia é a automação e a segurança por padrão. O Smallstep visa trazer a facilidade de uso e a automação do Let’s Encrypt para a infraestrutura interna. Ele promove o uso de certificados de curta duração e a rotação automática, reduzindo a superfície de ataque e eliminando a necessidade de scripts complexos de OpenSSL.

C. Caso de Uso Ideal

O Smallstep é a melhor escolha quando:

  • É necessário estabelecer uma PKI interna robusta e automatizada para microsserviços.
  • A automação da renovação de certificados é um requisito crucial (DevOps/SRE).
  • A equipe busca uma alternativa moderna e mais segura ao gerenciamento manual de CA com OpenSSL.
D. Exemplo Prático Completo (step-ca)

O exemplo a seguir demonstra a emissão de um certificado para um serviço interno usando o cliente step após a CA (step-ca) ter sido configurada.

1
2
3
4
5
6
7
8
9
10
11

# 1. Instalação do cliente 'step' (assumindo que a CA já está rodando)
# curl -sL https://dl.smallstep.com/cli/install.sh | bash

# 2. Configuração do cliente para se conectar à CA interna
# step ca bootstrap --fingerprint <fingerprint_da_ca> --ca-url <url_da_ca>

# 3. Emissão de um certificado para um serviço interno (usando o protocolo ACME)
# O token é obtido via um processo de autenticação (ex: SSH, AWS, etc.)
step ca certificate meu-servico.corp meu-servico.crt meu-servico.key \
    --provisioner "meu-provisionador" \
    --token $(step ca token meu-servico.corp)
E. Vantagens
  • Automação ACME: Permite a renovação automática de certificados de curta duração, ideal para ambientes dinâmicos.
  • Segurança: Promove o princípio do least privilege e a rotação frequente de chaves.
  • Facilidade de Uso: Abstrai a complexidade do OpenSSL com uma CLI intuitiva.
F. Desvantagens
  • Requer Infraestrutura: Exige a configuração e manutenção de um servidor CA dedicado (step-ca).
  • Curva de Aprendizado: Embora mais simples que o OpenSSL, introduz novos conceitos (provisioners, tokens, ACME).
  • Dependência: Requer a instalação do binário step e a infraestrutura step-ca.

2.4. mkcert

A. Descrição

O mkcert é uma ferramenta moderna e multiplataforma (escrita em Go) projetada especificamente para criar certificados TLS/SSL localmente confiáveis. Ele não cria certificados autoassinados puros, mas sim certificados assinados por uma CA local que ele instala automaticamente no trust store do sistema operacional e dos navegadores.

Compatibilidade Multiplataforma: O mkcert funciona nativamente em Linux, macOS e Windows, tornando-o ideal para equipes que trabalham com diferentes sistemas operacionais. No Windows, funciona diretamente; no macOS, pode ser instalado via Homebrew; e no Linux, está disponível em vários gerenciadores de pacotes.

B. Filosofia de Design

Sua filosofia é a experiência do desenvolvedor. O mkcert visa eliminar a dor de cabeça de configurar HTTPS localmente, tornando o processo o mais simples possível. Ele abstrai a complexidade do PKI, focando apenas na geração de certificados que funcionam sem avisos de segurança.

C. Caso de Uso Ideal

O mkcert é a escolha inquestionável para:

  • Desenvolvimento Web Local: Onde o certificado precisa ser confiável pelo navegador (Chrome, Firefox, Safari) para testar cookies seguros, Service Workers e outras funcionalidades HTTPS.
  • Projetos de Teste: Onde a rapidez e a ausência de erros de segurança são prioritárias.

Não é recomendado para uso em produção, em redes internas que não sejam o ambiente local do desenvolvedor, ou em cenários que exijam controle granular sobre a CA.

D. Exemplo Prático Completo (mkcert)

O exemplo demonstra a instalação, a criação da CA local e a geração de um certificado confiável.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 1. Instalação (Exemplo via Homebrew no Linux, outras opções disponíveis)
# sudo apt install libnss3-tools # Necessário para o mkcert funcionar com Firefox
# brew install mkcert

# 2. Criação da CA Local (executado apenas uma vez)
# Isso instala a CA raiz no trust store do SO e navegadores.
mkcert -install

# 3. Geração do Certificado (para localhost e um nome de domínio local)
# O mkcert usa SHA-256 e chaves ECDSA por padrão (ou RSA se especificado).
# O certificado gerado é assinado pela CA local do mkcert.
mkcert meuapp.local 127.0.0.1 ::1

# Saída:
# Created a new certificate valid for the following names
# - "meuapp.local"
# - "127.0.0.1"
#
# The certificate is at ./meuapp.local+1.pem and the key at ./meuapp.local+1-key.pem

# 4. Verificação do Certificado (para confirmar o SAN e o emissor)
# O mkcert gera arquivos PEM padrão, compatíveis com OpenSSL.
openssl x509 -in meuapp.local+1.pem -text -noout | grep -E 'Signature Algorithm|Public Key|Issuer|Subject Alternative Name'

E. Vantagens

  • Simplicidade: Sintaxe de comando extremamente simples (mkcert <domínios>).
  • Confiança Automática: O certificado é automaticamente confiável pelo navegador/SO local.
  • Padrão: Gera arquivos PEM padrão, fáceis de usar com Nginx, Apache, etc.

F. Desvantagens

  • Escopo Limitado: Estritamente para desenvolvimento local; não deve ser usado em produção.
  • Dependência: Requer a instalação do binário mkcert e, para Firefox, do libnss3-tools.
  • Controle Reduzido: Abstrai a maioria dos detalhes criptográficos, limitando o controle do usuário.

3. Tabela Comparativa Direta

CaracterísticaOpenSSLcertutil (NSS Tools)mkcertSmallstep (step-ca)
Nível de ComplexidadeAvançadoIntermediário/AvançadoInicianteIntermediário
Tipo de CertificadoAutoassinado Puro / CA PrópriaAutoassinado Puro / CA PrópriaAssinado por CA Local (Confiável)Assinado por CA Privada (ACME)
Formatos de SaídaPEM, DER, PKCS#12 (Tudo)NSS DB (Primário), Exporta para PEM/DERPEM (Padrão)PEM (Padrão)
Suporte a SANSim, via arquivo de configuraçãoSim, via extensões no comandoSim, nativo e obrigatórioSim, nativo e obrigatório
Integração com NavegadoresNenhuma (Manual)Nativa (Firefox/Chrome via NSS DB)Automática (via CA local)Nenhuma (Manual, exceto se a CA for importada)
Integração com Servidores WebExcelente (PEM é o padrão)Ruim (Requer conversão para PEM)Excelente (Gera PEM padrão)Excelente (PEM é o padrão)
Gerenciamento de CAManual (via scripts)Robusto (via DB e comandos)Automático (CA local)Servidor CA Dedicado (ACME)
Casos de Uso IdeaisScripting, CA interna complexa, controle totalPKI Enterprise, sistemas baseados em NSSDesenvolvimento web local (HTTPS)PKI Interna Automatizada (DevOps/SRE)
Performance (Geração)Rápida (~100ms)Rápida (~150ms)Muito Rápida (~50ms)Lenta (~500ms+, via rede)
Renovação AutomáticaManual (via script)Manual (via script)Não aplicávelNativa (via ACME)

4. Cenários Práticos de Uso

Cenário 1: Desenvolvimento Web Local

  • Requisitos: HTTPS local, certificado confiável no navegador (sem avisos), renovação simples.
  • Ferramenta Recomendada: mkcert
  • Justificativa Técnica: O mkcert é a única ferramenta que instala automaticamente uma CA raiz local no trust store do sistema operacional e dos navegadores. Isso garante que os certificados gerados para localhost ou domínios .local sejam confiáveis, permitindo o teste de funcionalidades que exigem um contexto seguro (ex.: Service Workers, HSTS). A sintaxe é a mais simples, minimizando o tempo de configuração.
  • Exemplo Prático Resumido:
    1
2

    mkcert -install
mkcert meuprojeto.local 127.0.0.1

Cenário 2: Ambiente Corporativo / Enterprise

  • Requisitos: Integração com LDAP/Active Directory/FreeIPA, auditoria, automação, gerenciamento de CA centralizado.
  • Ferramenta Recomendada: certutil (NSS Tools) ou OpenSSL (com scripts robustos)
  • Justificativa Técnica: Em ambientes corporativos com uma PKI interna estabelecida, o certutil se destaca por sua origem no ecossistema Mozilla/Red Hat, sendo a ferramenta nativa para gerenciar certificados em sistemas como FreeIPA. Ele oferece um modelo de banco de dados mais robusto para gerenciamento de chaves e auditoria. O OpenSSL é uma alternativa viável se a PKI for baseada em arquivos PEM e exigir automação via scripts complexos.
  • Exemplo Prático Resumido (certutil):
    1
2

    # Criação de um certificado para um servidor interno no DB
certutil -S -n "Servidor LDAP" -s "CN=ldap.corp" -d /etc/pki/nssdb ...

Cenário 3: Infraestrutura de Serviços Internos

  • Requisitos: Múltiplos serviços, balanceadores de carga, renovação automatizada, formato PEM.
  • Ferramenta Recomendada: Smallstep (step-ca) ou OpenSSL
  • Justificativa Técnica: Para infraestruturas modernas e dinâmicas, o Smallstep é a escolha preferencial, pois automatiza a emissão e renovação de certificados de curta duração via protocolo ACME, reduzindo a complexidade operacional. O OpenSSL permanece uma alternativa sólida quando é necessário controle total sobre os parâmetros criptográficos ou em ambientes que já possuem scripts de automação baseados em PEM.
  • Exemplo Prático Resumido (OpenSSL):
    1
2
3
4

    # Geração de CSR para automação
openssl req -new -key servidor.key -out servidor.csr -config servidor.cnf
# Assinatura pela CA interna
openssl x509 -req -in servidor.csr -CA ca.crt -CAkey ca.key -out servidor.crt ...

Cenário 4: Requisitos Especiais (HSM, Tokens Criptográficos)

  • Requisitos: Uso de Hardware Security Modules (HSM) ou tokens criptográficos.
  • Ferramenta Recomendada: OpenSSL ou certutil
  • Justificativa Técnica: Ambas as ferramentas possuem suporte a módulos de segurança via padrões como PKCS#11. O OpenSSL é frequentemente usado com engines específicos do fabricante do HSM. O certutil é nativamente projetado para interagir com tokens de segurança (o NSS DB é um tipo de token), tornando-o uma escolha robusta para gerenciamento de chaves em hardware dedicado.
  • Exemplo Prático Resumido (Conceitual):
    1
2

    # OpenSSL com engine PKCS#11
openssl req -new -engine pkcs11 -keyform engine -key "label_da_chave" ...

5. Fluxo Decisório

O fluxo lógico a seguir pode auxiliar na escolha da ferramenta mais adequada para o seu contexto:

graph TD
    A[Certificado para desenvolvimento web local?] -->|Sim| B{Precisa ser confiável no navegador?};
    B -->|Sim| C[mkcert];
    B -->|Não| D[OpenSSL];
    A -->|Não| E{Ambiente corporativo com PKI baseada em NSS?};
    E -->|Sim| F[certutil / NSS Tools];
    E -->|Não| G{Infraestrutura interna dinâmica (microsserviços)?};
    G -->|Sim| H[Smallstep (step-ca)];
    G -->|Não| I{Precisa de controle granular ou automação simples?};
    I -->|Sim| J[OpenSSL];
    I -->|Não| K[OpenSSL (Uso Geral)];

Fluxo Lógico Textual:

  1. O certificado é para desenvolvimento local?
    • Sim → Precisa ser confiável no navegador?
      • Sim → mkcert (Simplicidade e confiança automática)
      • Não → OpenSSL (Se for apenas para criptografia básica)
    • Não → O ambiente é corporativo com PKI baseada em NSS (ex: FreeIPA)?
      • Sim → certutil / NSS Tools (Integração nativa com o ecossistema)
      • Não → A infraestrutura interna é dinâmica (microsserviços, DevOps)?
        • Sim → Smallstep (step-ca) (Automação ACME e segurança)
        • Não → Precisa de controle granular ou automação simples?
          • Sim → OpenSSL (Controle e flexibilidade)
          • Não → OpenSSL (Padrão para uso geral e infraestrutura)

6. Considerações de Segurança

Certificados autoassinados, por definição, não oferecem a garantia de identidade de uma CA pública. O risco principal é que qualquer pessoa pode criar um certificado para qualquer domínio, o que os torna vulneráveis a ataques Man-in-the-Middle (MITM) se usados incorretamente.

Boas Práticas Comuns

  • Armazenamento Seguro de Chaves: A chave privada (.key ou equivalente) NUNCA deve ser armazenada em repositórios públicos ou acessível por usuários não autorizados. Use permissões restritivas (chmod 600).
  • Validade Curta (Rotação): Use períodos de validade curtos (ex.: 90 dias) para forçar a rotação regular e limitar o tempo de exposição de uma chave comprometida.
  • Algoritmos Modernos: Sempre utilize SHA-256 ou superior e chaves RSA de 2048 bits ou ECDSA equivalente, conforme demonstrado nos exemplos.
  • Validade Máxima: Embora o OpenSSL permita longos períodos de validade, navegadores modernos (como o Chrome) impõem um limite máximo de 398 dias para certificados de CAs públicas. É uma boa prática seguir esse limite mesmo para certificados internos, para garantir a compatibilidade e forçar a rotação.

Alertas Específicos por Ferramenta

FerramentaAlerta de Segurança
OpenSSLA sintaxe complexa pode levar à omissão de extensões cruciais (como SAN), resultando em certificados que não funcionam corretamente ou são inseguros.
certutilO banco de dados NSS DB pode ser protegido por senha. Se for deixado sem senha (como no exemplo simplificado), a segurança do DB depende inteiramente das permissões do sistema de arquivos.
mkcertA CA raiz local do mkcert é uma chave de altíssimo valor. Se essa chave for comprometida, um atacante poderia gerar certificados confiáveis para qualquer site no seu sistema local.

6.3. Casos de Vulnerabilidade e Prevenção

Para ilustrar os riscos de forma prática, considere os seguintes cenários de vulnerabilidade e como preveni-los:

CenárioProblemaConsequência PotencialPrevenção e Mitigação
Certificado de Longa Duração em ProduçãoUma chave privada associada a um certificado com validade de vários anos é vazada de um servidor público.Um atacante pode se passar pelo servidor legítimo por um longo período (ataque Man-in-the-Middle), interceptando dados sensíveis.Use certificados de curta duração (ex: 90 dias) com renovação automática. Ferramentas como Let’s Encrypt ou Smallstep para ambientes internos são ideais para este fim.
CA Privada do mkcert ExpostaUm desenvolvedor acidentalmente envia a chave privada da CA raiz do mkcert (localizada em ~/.local/share/mkcert) para um repositório de código público.Qualquer pessoa com acesso à chave pode gerar certificados que são automaticamente confiáveis na máquina do desenvolvedor, abrindo portas para ataques de phishing e MITM locais.Nunca versione o diretório de dados do mkcert. Adicione ~/.local/share/mkcert ao seu arquivo .gitignore global. Ao desativar uma máquina, execute mkcert -uninstall para remover a CA dos trust stores.

7. Migração e Interoperabilidade

A interoperabilidade entre as ferramentas é crucial, sendo o formato PEM (Privacy-Enhanced Mail) o denominador comum.

Conversão NSS (certutil) para PEM (OpenSSL/mkcert)

Para usar um certificado armazenado no NSS DB em um servidor web (que geralmente espera PEM), você deve exportá-lo.

1
2
3
4
5
6
7
8
9
10

# 1. Exportar o certificado (sem a chave privada)
certutil -L -d sql:$HOME/.pki/nssdb -n "MeuApp Self-Signed" -a > meuapp_cert.pem

# 2. Exportar a chave privada (requer o comando pk12util)
# O pk12util exporta o par chave/certificado para o formato PKCS#12 (.p12 ou .pfx)
pk12util -o meuapp.p12 -n "MeuApp Self-Signed" -d sql:$HOME/.pki/nssdb

# 3. Converter o PKCS#12 para PEM (chave e certificado separados)
openssl pkcs12 -in meuapp.p12 -nocerts -out meuapp_key.pem
openssl pkcs12 -in meuapp.p12 -nokeys -out meuapp_cert_from_p12.pem

Conversão PEM (OpenSSL/mkcert) para NSS (certutil)

Para importar um certificado PEM para o trust store do NSS DB (ex.: para que o Firefox confie nele), use o certutil -A.

1
2
3
4

# Adicionar o certificado (CA ou Servidor) ao DB
# -t "C,," para CA (confiável para SSL/TLS)
# -t ",," para certificado de servidor (apenas para verificação)
certutil -A -n "CA do mkcert" -t "C,," -i /caminho/para/rootCA.pem -d sql:$HOME/.pki/nssdb

Uso de Certificados mkcert em Servidores Existentes

Como o mkcert gera arquivos PEM padrão (.pem para o certificado e -key.pem para a chave), eles são diretamente compatíveis com a maioria dos servidores web.

Exemplo Nginx:

1
2
3
4
5
6
7
8

server {
    listen 443 ssl;
    server_name meuapp.local;

    ssl_certificate /caminho/para/meuapp.local+1.pem;
    ssl_certificate_key /caminho/para/meuapp.local+1-key.pem;
    # ...
}

7.2. Fluxos de Migração Comuns

Migrando de OpenSSL para Smallstep:

Se você já possui uma CA interna gerenciada com OpenSSL, é possível migrá-la para o Smallstep para aproveitar a automação ACME sem invalidar os certificados existentes.

  1. Inicialize o step-ca com sua CA existente:
    1

    step ca init --root ca.pem --key ca.key
  2. Configure provisioners no step-ca para permitir que os clientes obtenham certificados.
  3. Migre gradualmente os serviços para usar o cliente step ou um cliente ACME para renovar seus certificados.

Migrando de mkcert (Desenvolvimento) para Produção:

O mkcert nunca deve ser usado em produção. O fluxo correto é uma transição de ferramentas:

  1. Desenvolvimento: Continue usando mkcert para simplicidade local.
  2. Staging/Pré-Produção: Utilize Let’s Encrypt com seu modo de teste (staging endpoint) para simular a obtenção de certificados públicos.
  3. Produção: Use Let’s Encrypt para serviços públicos ou Smallstep/OpenSSL para serviços internos.

8. Checklist Pré-Implantação

Antes de escolher e implementar uma solução, use este checklist para garantir que sua decisão está alinhada com os requisitos técnicos e operacionais do seu projeto.

[ ] 1. Contexto de Uso

  • O certificado será usado apenas em máquinas de desenvolvimento local?
  • A criptografia é para uma rede interna (microsserviços, APIs privadas)?
  • O serviço será exposto à internet pública?

[ ] 2. Requisitos de Segurança

  • É necessário suporte a Hardware Security Modules (HSM) ou tokens criptográficos?
  • A organização exige uma trilha de auditoria centralizada para emissão de certificados?
  • A capacidade de revogar certificados rapidamente (via CRL ou OCSP) é um requisito?

[ ] 3. Habilidades e Capacidade da Equipe

  • A equipe possui conhecimento profundo em PKI e na linha de comando do OpenSSL?
  • Existe familiaridade com o protocolo ACME e automação de certificados?
  • Há capacidade operacional para manter um servidor de CA interno (como o step-ca)?

[ ] 4. Ecossistema e Integrações

  • O certificado precisa ser confiável por padrão em navegadores web?
  • A solução precisa se integrar com load balancers (NGINX, HAProxy)?
  • A automação será feita em ambientes de contêineres (Kubernetes, Docker Swarm)?
  • A gestão será integrada a ferramentas de IaC (Terraform, Ansible)?

9. Ecossistema Ampliado: Ferramentas Complementares

Além das quatro ferramentas principais, o ecossistema de PKI inclui outras soluções notáveis:

  • CFSSL (Cloudflare): Uma ferramenta de PKI e toolkit TLS similar em escopo ao Smallstep, mas com uma forte orientação para API. É uma excelente opção para quem busca construir automação de certificados via REST API.
  • Lego: Um cliente ACME popular e robusto, escrito em Go. É uma alternativa excelente ao Certbot para automação da obtenção de certificados do Let’s Encrypt, especialmente em ambientes baseados em contêineres.
  • LibreSSL: Um fork do OpenSSL criado pelo projeto OpenBSD com o objetivo de modernizar a base de código e melhorar a segurança. Embora ofereça uma API mais limpa, o OpenSSL ainda é o padrão de fato na maioria das distribuições Linux.

10. FAQ: Problemas e Soluções

P: Por que meu certificado funciona no Firefox, mas o Chrome mostra um erro de privacidade?

R: Isso geralmente acontece porque o Firefox usa seu próprio trust store (o banco de dados NSS), enquanto o Chrome (na maioria dos sistemas operacionais) utiliza o trust store do sistema. Se você adicionou uma CA raiz manualmente, precisa garantir que ela foi importada em ambos os locais. Ferramentas como mkcert fazem isso automaticamente.

P: Como posso revogar um certificado autoassinado criado com OpenSSL ou mkcert?

R: Nativamente, nem OpenSSL (em uma configuração simples) nem mkcert oferecem um mecanismo de revogação fácil como listas de revogação de certificados (CRLs) ou OCSP. A revogação é um recurso de uma infraestrutura de CA mais robusta. Para isso, Smallstep (step-ca) é a ferramenta recomendada, pois possui suporte integrado para CRLs.

P: Como faço para um certificado de desenvolvimento local funcionar em um dispositivo móvel?

R: Você precisa exportar a CA raiz da sua ferramenta (por exemplo, a CA do mkcert, que pode ser encontrada com mkcert -CAROOT) e instalá-la manualmente no trust store do dispositivo móvel (iOS ou Android). Este processo geralmente envolve enviar o arquivo da CA por e-mail para o dispositivo e seguir as etapas de instalação do sistema operacional.

P: É possível automatizar a renovação de certificados com OpenSSL?

R: Sim, mas requer trabalho manual. A abordagem comum é criar um script shell que gera um novo par de chaves e um certificado e, em seguida, configurar um cron job para executar esse script periodicamente (por exemplo, a cada 60 dias). O script também deve incluir um comando para recarregar o serviço que utiliza o certificado (ex: sudo systemctl reload nginx).

11. Conclusão e Roadmap Evolutivo

A escolha da ferramenta para certificados autoassinados no Linux deve ser guiada pelo contexto de uso e pelo público-alvo.

ContextoFerramenta RecomendadaPorquê
Desenvolvimento Web LocalmkcertSimplicidade e confiança automática no navegador.
Infraestrutura/AutomaçãoSmallstep (step-ca)Automação ACME, segurança e renovação de curta duração.
Alternativa de InfraestruturaOpenSSLFlexibilidade, controle granular e formato PEM universal.
PKI Corporativa (NSS)certutilGerenciamento centralizado em DB e integração com sistemas Enterprise.

É fundamental reconhecer que, embora úteis, os certificados autoassinados e os certificados assinados por CA local (mkcert) não substituem os certificados de CAs públicas (como Let’s Encrypt) em ambientes de produção voltados para o público.

Roadmap Evolutivo de Maturidade em PKI

Para organizações que buscam evoluir sua gestão de certificados, um roadmap típico pode ser:

  1. Fase 1 (Inicial): Padronize o uso de mkcert para todo o desenvolvimento local, eliminando os avisos de segurança e simplificando o onboarding de novos desenvolvedores.
  2. Fase 2 (Crescimento): Adote scripts baseados em OpenSSL para gerar certificados para ambientes internos de staging e teste. Comece a monitorar a expiração dos certificados.
  3. Fase 3 (Maturação): Implemente uma CA interna com Smallstep (step-ca) para automatizar completamente a emissão e renovação de certificados para microsserviços e infraestrutura interna.
  4. Fase 4 (Enterprise): Integre a CA interna com sistemas de identidade (IAM), utilize HSMs para proteger as chaves raiz e adote uma gestão de certificados totalmente automatizada via pipelines de GitOps.
Security, DevOps
SSL TLS OpenSSL mkcert Smallstep
This post is licensed under CC BY 4.0 by the author.