[ Segurança de transporte ]

Publique e gire registros TLSA sem interromper a entrega SMTP

Planeje a substituição de TLSA de parâmetros fixos com pré-publicação, sobreposição com reconhecimento de cache, verificação de frota e um limite de recuperação antes de remover associações antigas.

Pela equipe de pesquisa EmailAuth · 8 minutos de leitura

[Pontos-chave]

  • Identifique se a alteração substitui uma chave, um certificado, uma âncora de confiança ou parâmetros TLSA.
  • Para substituição de parâmetros fixos, pré-publique associações antigas e novas em pelo menos dois TTLs antes da implantação.
  • Retire as associações antigas somente depois que o serviço ativo e as dependências de reversão forem compreendidos.
Nesta página

[ Remover ]

Coordene os operadores DNS e SMTP em torno de uma sobreposição verificada e, em seguida, implante e desative em etapas, sem confundir um certificado salvo com uma reversão segura.

[Por função]

O que isso significa para você

Escolha sua função para ver as próximas etapas práticas.

Administrador de TI/Correio

Verifique cada estágio de rollover

Um trabalho de implantação bem-sucedido não prova que todas as instâncias SMTP apresentam a chave pretendida.

Próximas etapas

  1. Capture a linha de base segura e a tupla TLSA completa.
  2. Pré-publique o conjunto expandido e registre o tempo.
  3. Verifique cada instância ativa antes de retirar os dados antigos.

CISO/SecOps

Mantenha as evidências públicas separadas da custódia das chaves

O plano DNS precisa de associações, não de chaves privadas.

Próximas etapas

  1. Revise explicitamente as alterações de uso e de parâmetros.
  2. Mantenha os registros atualmente correspondentes para cada combinação publicada.
  3. Trate a validação DNSSEC como uma porta independente.

Fundador / Não técnico

Coordenar a dependência de manutenção

Os caches DNS e a implantação escalonada do servidor podem sobreviver a uma janela de manutenção.

Próximas etapas

  1. Atribua proprietários de publicação e SMTP .
  2. Aprovar um plano de sobreposição e recuperação justificado.
  3. Exija evidências antes da etapa final de aposentadoria.

[ Perguntas frequentes ]

Perguntas frequentes

Cada renovação de certificado altera um registro 3 1 1?

Não. Essa associação seleciona a chave pública, portanto a renovação usando a mesma chave pode preservá-la. Verifique a chave real em vez de assumir que a automação a reutiliza.

RFC 7672

Com que antecedência devem ser publicadas novas associações de parâmetros fixos?

RFC 7671 especifica o aumento do conjunto antigo em pelo menos dois TTLs, ou mais, antes de implantar a nova cadeia. Preservar a associação atual durante a sobreposição.

RFC 7671

A redução do TTL pode reduzir imediatamente os dados antigos em cache?

Não. As cópias já armazenadas em cache no TTL anterior precisam de sua própria consideração de tempo. Registre a publicação real e o histórico do cache.

RFC 1035

Posso publicar apenas dados futuros sob uma combinação de parâmetros?

A orientação do editor exige uma associação atualmente correspondente para cada combinação de uso/seletor/tipo de correspondência publicada. Os registros futuros ou desativados não podem ser os únicos para essa combinação.

RFC 7671

Quando as associações obsoletas podem ser removidas?

Depois que a nova cadeia for implantada e verificada e a associação antiga não descrever mais uma dependência ativa. Revise os requisitos de backup e reversão antes da remoção.

RFC 7671

Restaurar o certificado antigo é sempre uma reversão segura?

Não. Alguns clientes podem ter um novo conjunto de TLSA armazenado em cache após a descontinuação. Avalie os dados publicados atuais e o histórico do cache antes de reverter o servidor.

RFC 7671

Posso aplicar a mesma sequência ao alterar o uso ou o seletor?

Não presuma isso. As transições de parâmetros exigem a orientação RFC 7671 correspondente e a revisão de compatibilidade, separada da substituição de chave de parâmetro fixo.

RFC 7671

Nenhuma falha TLS-RPT prova que o rollover foi bem-sucedido?

Não. Os relatórios são opcionais, agregados e tardios. Retenha evidências diretas autorizadas de DNS seguro e SMTP para a frota real.

RFC 8460

[ Fontes ]

Fontes

  1. RFC 1035

    Seções §3.2.1 Formato · §3.3.13 Formato SOA RDATA

  2. RFC 8460

    Seções §3. Política de relatórios · §4.1 Prazo do relatório · §4.3 Tipos de resultados · §5.2 Compressão · §5.3 Transporte de e-mail · §5.4 Transporte HTTPS · §5.5 Nova tentativa de entrega · §5.6 Variações de metadados · §7. Considerações de segurança

  3. RFC 7672

    Seções §2.1 Considerações DNS · §2.2 Descoberta TLS · §2.2.1 Resolução MX · §2.2.3 Pesquisa de registro TLSA · §3.1 Usos de certificado TLSA · §3.2 Correspondência de certificado · §4. Gerenciamento de chaves de servidor

  4. RFC 7671

    Seções §6. Sincronização de provedor de serviços e editor TLSA · §7. Domínio Base TLSA e CNAMEs · §8. Requisitos do editor TLSA · §8.1 Substituição de chave com parâmetros TLSA fixos · §8.3 Mudança para novos parâmetros TLSA

  5. RFC 6698

    Seções §2.1 Formato de transferência TLSA RDATA · §3. Nomes de domínio para associações de certificados TLSA

[ Glossário ]

Glossário

Pré-publicação
Publicar associações para uma chave futura preservando as associações atuais antes de mudar o serviço.

RFC 7671

Sobreposição de associação
Um conjunto TLSA que suporta o material de chave atual e de transição necessário.

RFC 7671

Parâmetros fixos
Uso de certificado inalterado, seletor e combinações de tipo correspondente durante uma substituição de chave.

RFC 7671

Limite de reversão
O ponto em que os dados somente novos publicados e armazenados em cache podem tornar inseguro o retorno à chave do servidor antigo sem coordenação adicional.

Proveniência da empresa

Por que as principais instituições financeiras e governos retiraram seus painéis de segurança de e-mail.

As plataformas tradicionais de autenticação de e-mail vendem um painel e pedem que seus engenheiros façam o trabalho. Em ambientes de alto risco, a supervisão manual significa aplicação atrasada, desvios de configuração e domínios ocultos não monitorados.

EmailAuth é a plataforma de origem de e-mail agente. Nossos agentes impõem p=reject, mantenha remetentes terceiros alinhados e mova seus domínios para full RFC 9989 conformidade, o novo padrão DMARC , com auditabilidade humana no circuito.

Governos Grandes empresas Instituições financeiras de nível 1

SaaS · Locação dedicada · Air gap no local · Criptografia BYOK

Base de conhecimento