Certificados TLS e extensões automáticas

Para quê?

O TLS criptografa o tráfego «kliyent↔servis», certifica a autenticidade do servidor (e quando o cliente é mTLS) e protege contra trocas. Os principais riscos são o atraso dos certificados, chaves fracas, cadeia de confiança errada, procedimentos manuais. O objetivo do artigo é descrever a arquitetura em que os certificados são sempre válidos e rotativos discretos para os usuários.

Conceitos básicos

CA/Assinante: autoridade de certificação (pública ou interna).
Chain (fullchain): certificado de folha + meio-termo + raiz (normalmente raiz em armazéns de clientes).
SAN é uma lista de domínios/IP para um único certificado (multi-SAN).
Wildcard: `.example. com '- conveniente para muitos palcos, requer validação DNS.
OCSP stapling: servidor aplica status de revogação recente; reduz os atrasos e a dependência de OCSP externo.
HPKP: obsoleto/não usar; em vez disso, logs CT e higiene chave.
CT (Certificate Transparency): logs públicos de emissão são importantes para controlar edições falsas.

Criptoprofílico e chaves

• ECDSA (P-256) - rápido e compacto; preferido para os clientes modernos.
• RSA-2048/3072 - ainda mais compatível; você pode manter o dual-cert (RSA + ECDSA).
• Geração de chaves: somente no lado alvo (não transferir privatizadores pela rede), proteger permissões ('06 00').
• HSM/KMS: Para áreas críticas (pagamento/PII), guarde as chaves no HSM/KMS e inclua a auditoria das transações.
• Prazos de vida: certificados curtos (90 dias/30 dias para o interior) encorajam rotações frequentes e reduzem o risco de comprometimento.

Modelos arquitetônicos de controle TLS

1. CA público por ACME (Let' s Encrypt/Buypass/etc.)

Validação: HTTP-01 (por meio do servidor Web/Ingress) ou DNS-01 (para domínios wildcard/extrassolares).
Benefícios: gratuito/automatizado, confiança ampla. Contras: Dependências externas.

2. CA corporativo interno

Ferramentas: HashiCorp Vault PKI, Smallstep (step-ca), Microsoft AD CS, CFSSL.
Políticas custômicas, mTLS, TTL curtos, edições para domínios internos. Contras: distribuição de raiz, gerenciamento de confiança.

3. Híbrido

CA público para usuários externos; O CA interno é para serviços de serviços (mTLS), canais interclasters e almirantes.

Pattern de extensão automática (renew)

Princípios gerais

Limite de extensão: começar a '≤ 30' dias antes do vencimento; para serviços críticos - a '≤ 45' dias.
Zero-downtime: lançamento de um novo certificado, substituição atômica, reload suave sem quebra de conexões.
Suporte duplo (blue/green): armazenar o cert atual e o seguinte; alternar por symlink ou segredo versionalizado.
Alerting: alertas de 45/30/14/7/3/1 dia; um alert separado quando o ACME-Challange falha.

Clientes ACME e sua aplicação

certbot / acme. sh/lego: agentes leves em VM/bare metal.
cert-gerente (Kubernetes): operadora que trabalha com Issuer/ClusterIssuer; automatiza o release/renew e grava no Secret.
step-ca/Vault Agente: lançamento automático/rotação com TTL curto, sidecar-pattern para atualização de chaves e cadeias.

Processos para Kubernetes

yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx

yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней

A substituição quente no NGINX-Ingress ocorre automaticamente quando «Secret» é atualizado. Adicione 'ssl-ecdh-curve: secp256r1' e inclua o OCSP stapling através de anotações/ConfigMap.

Processos VM/Bare-metal

bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"

Periodicamente 'certbot renew' através de systemd timer.
Para wildcard, use o DNS-01 (provedor-plugin) e o mesmo '-ducloy-hook'.

bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"

NGINX: Substituição atômica

Guarde 'fullchain. pem` и `privkey. pem 'sob caminhos estáveis (symlink para arquivos versionizados), em seguida' nginx -s reload '.

PKI interno e mTLS

bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256

Auto-lançamento por Vault Agente Injector (K8s) ou sidecar; o aplicativo repassa o cert do arquivo/FS-watcher.
TTL curtos: 24-720 horas, o que estimula rotação frequente e reduz o valor da chave roubada.
mTLS: Emita certificados de clientes para serviços/papéis específicos; na entrada - mutual TLS no ingress/sidecar-proxy.

Operação segura

Partilha de segredos: chaves privadas - apenas no hóspede/pol, acesso a menores privilégios.
Permissões de arquivo de '600' para a chave; o proprietário é o usuário do processo.
Período de Grace: instale 'renewBefore' o suficiente para considerar as falhas DNS/ACME/Provedor.
OCSP Stapling: incluir nas frentes; monitorar a resposta recente (normalmente 12-72 h).
HSTS: Ativar gradualmente (sem «pronoad» no início), certificando-se de que a entrega HTTPS de todo o conteúdo é correta.
Dual-cert (RSA + ECDSA): melhora a compatibilidade e o desempenho; aos clientes modernos, entreguem o ECDSA.

Monitoramento e SLO

• Dias anteriores (gauge) para cada domínio/segredo; SLO: «nenhum cert de <7 dias para expedy».
• Validade da cadeia (linting), adequação do SAN aos domínios/IP exigidos.
• Status OCSP stapling (resposta recente).
• Proporção de ACME-Challenges bem-sucedidos/inconclusivos.
• Leitensee apertos de mão TLS, versões de protocolo/código (auditório).

• Warn: 30 dias para expirar.
• Crime: 7 dias/fracasso 'renew'.
• Página: 72 horas/cadeia de não-sal na venda/falta do OCSP stapling.

Incidentes e reversões

Caducar o certificado temporariamente e bloquear manualmente, fixar o RCA (por isso, o RCA não funcionou, bloquear o DNS/limite de API).
Comprometimento da chave: transferência imediata/levantamento, rotação de segredos, auditoria de acesso, rotação de tokens do provedor DNS/ACME.
Cadeia errada: deplê de emergência correto 'fullchain', frentes de reload forçadas.
Lock-in ao provedor DNS: mantenha o caminho de validação de reserva (HTTP-01) ou DNS secundário.

Folha de cheque da implementação da venda automática

1. Selecione um modelo (CA público por ACME/PKI/híbrido interno).
2. Identifique a criptoprofil: ECDSA-P256, se necessário, dual-cert com RSA-2048.
3. Configure o agente automático (cert-gerente, certbot, acme. sh, Vault Agent).
4. Organize um substituto zero-downtime (symlink-pattern, hot-reload invress/NGINX/Envoy).
5. Inclua OCSP stapling e HSTS (por etapas).
6. Adicione o alertamento de prazos e estatais de challengs; prescrever o SLO.
7. Documente os processos de break-glass e de lançamento manual.
8. Faça um exercício «feel»: DNS-01 quebrado, ACME em queda, raiz vencida/intermediária.
9. Reveja a disponibilidade para as chaves privadas, roda os tokens do provedor DNS e as contas da ACME.

Características para iGaming/Fintech

PCI DSS/PII: Cipher Suites rigorosos, TLS 1 compulsório. 2+/1. 3, desligar a cifra fraca/compressão, sessão respumpition sem compromissos de segurança.
Segmentação de domínios: certificados individuais para subespécies de pagamento e almirantes; para provedores de conteúdo - cadeias isoladas.
Auditoria e logagem: verifique o lançamento/levantamento/rotação; assina artefatos CI/CD.
Multiregionalidade: Issuer-s locais para regiões para não depender de rejeitos cruzados-regionais.

Exemplos de configuração

NGINX (RSA+ECDSA, OCSP stapling)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;

ssl_certificate   /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate   /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000" always;

OpenSSL: CSR (ECDSA-P256)

bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"

CFSSL: perfil e emissão

json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}

bash cfssl gencert -profile=server ca. json csr. json      cfssljson -bare server

FAQ

Precisamos de wildcard?
Se os novos subterfúgios são frequentes, sim (DNS-01). Caso contrário, use o multi-SAN para domínios explícitos.

Qual escolha entre cert-management ou certbot?
Kubernetes → cert-manager. VM/microsserviços fora do K8s → certbot/lego/acme. sh. PKI interno → Vault/step-ca.

Podemos reduzir a TTL até 24 horas?
Para mTLS internos - sim, se a automação/sidecar garante rotação e aplicativos hot-reload.

Como é que o DNS-01 está seguro?
Acesso individual/mínimo à área, rotação de chaves, restrição de acesso API IP, auditoria.

Resultado

A gestão confiável do TLS é uma combinação de criptoprofilismo correto, edições automatizadas e extensões, rotações zero-downtime, observabilidade e procedimentos claros de incidente-respeons. Construa uma linha de montagem ACME/PXI, adicione um alerting rigoroso e treine cenários de emergência regularmente - e os certificados vencidos deixarão de ser uma fonte de pagers noturnos.