[ Taşıma güvenliği ]

SMTP TLS raporlarında süresi dolmuş veya güvenilmeyen sertifikalar

Sürenin sona ermesini güven zinciri arızasından ayırt edin, rapor edilen uç noktayı koruyun ve yenileme sonrasında gerçekten sunulan sertifikayı doğrulayın.

EmailAuth araştırma ekibi tarafından · 4 dakikalık okuma

[ Anahtar noktalar ]

  • Süresi dolmuş ve güvenilmeyen, farklı olası onarımlara sahip farklı kategorilerdir.
  • Etkilenen her dinleyicinin gerçekte sunduğu sertifikayı inceleyin.
  • Gözlemleri doğru STS veya DANE güven modeli altında karşılaştırın.
Bu sayfada

Sürenin sona ermesini güven zinciri arızasından ayırt edin, rapor edilen uç noktayı koruyun ve yenileme sonrasında gerçekten sunulan sertifikayı doğrulayın.

Sonuç kategorisini tam olarak okuyun

Referanslar: RFC 8460 §4.3.1, RFC 8460 §4.3.2.

sertifikanın süresi dolmuş, raporlayanın süresi dolmuş bir sertifikayı gözlemlediği anlamına gelir. güvenilmeyen sertifika, bilinmeyen sertifika yetkilileri, zincir hataları ve ad kısıtlamaları dahil olmak üzere çeşitli koşulları kapsar. Başarısızlık nedeni kodu tanıyı daraltabilir ancak evrensel bir ayrıştırıcı sözleşmesi değil, raportör tarafından sağlanan bir metindir. Güvenilmeyen sertifikaların her raporunu, kanıtı olmayan eksik ara rapor olarak etiketlemeyin. SMTP sertifika sorununun sts-webpki-geçersiz ile karıştırılmaması için politika bağlamı ile başlayın ve uç noktanın alındığı bildirildi. MTA-STS HTTPS politikası ana bilgisayarı.

Gönderene ulaşan sertifikayı kontrol edin

Yenilenen bir sertifikayı gösteren bir sertifika yöneticisi, her SMTP dinleyicisinin bu sertifikayı sunduğunu belirlemez. Gerçek yetkili uç nokta kontrolünden seri veya parmak izini, geçerlilik aralığını, zinciri ve test zaman damgasını kaydedin. Bu değerleri raporların içerdiği alıcı rotalar arasında karşılaştırın. Eski bir işlem, unutulmuş bir yedekleme ana bilgisayarı veya eksik yük dengeleyici dağıtımı, eski sertifikaların etkin kalmasına neden olabilir. Geçerlilik sınırları tutarsız göründüğünde saat doğruluğunu gözden geçirin, ancak yalnızca başarısız bir test geçişi yapmak için saatleri değiştirmeyin veya depolara güvenmeyin.

Yenileme çakışması sorununu yeniden oluşturma

Sentetik alıştırma, t=100 kadar geçerli olan eski bir sertifikayı ve t=90 t=200. t=110, eski sertifikayı sunmaya devam eden bir dinleyici, modelin geçerlilik penceresi kontrolünde başarısız olurken, yeni sertifikayı sunan bir dinleyici bunu geçer. Bu, gerçek bir sertifika oluşturmadan dağıtım ayrımını yeniden üretir. Zincir güvenini, ad eşleşmesini, iptal davranışını veya uygulamanın sınır kurallarını kanıtlamaz. Bunların gerçek bir TLS doğrulayıcısına ve kontrollü uç nokta kanıtlarına ihtiyacı var.

Güveni atlamadan araştırın

Referanslar: RFC 8461 §4.2, RFC 7672 §3.1.1.

Yaprağı yakalayın ve ara zinciri servis edin, ardından raportörün nedenini sürdürülen bir test ortamıyla karşılaştırın. Yerel bir makinenin güvendiği bir veren, etkilenen gönderen tarafından kabul edilmeyebilir. Eksik ara öğeler, beklenmeyen otomatik olarak imzalanan bir sertifika ve politikaya özgü kısıtlama farklı onarımlardır. Seçilen doğrulama modelini belgeleyin. SMTP DANE DANE-EE kullanımı Web PKI'dan farklı güven semantiğine sahiptir, bu nedenle kamu sertifika yetkililerine ilişkin STS tarzı bir sonuç her birine kolayca uygulanamaz. TLSA rapor.

Dağıtım ve raporlamadaki döngüyü kapatın

Referanslar: RFC 8460 §4.1.

Onaylanan yenilemeyi veya zincir düzeltmeyi etkilenen her dinleyiciye uygulayın, yeniden yükleme davranışını doğrulayın ve değişiklikten sonra sunulan sertifikanın kanıtını saklayın. Gözlem süreleri onarımdan sonra düşen raporları karşılaştırın ve toplama gecikmelerini hesaba katın. Sahiplik ve kullanıma sunma için yeterli hazırlık süresine sahip yenileme izlemeyi planlayın ve yeni sertifikanın gerçekten dağıtılıp dağıtılmadığını ayrı olarak izleyin. Sertifika hatalarını gizlemek için zorunlu aktarım ilkesini otomatik olarak düşürmeyin. Bu kılavuz yalnızca kontrollü laboratuvar testlerini kaydeder; üretim sertifikalarını yenilemez, üretim güven depolarını değiştirmez veya üretimin geri kazanıldığını göstermez.

Saklanan tarihsel kanıtlar ve güncel kontroller

Aşağıdaki ulaşım gözlemleri 7 Kasım 2026'da kaydedildi ve bu inceleme için ağ testleri olarak yeniden çalıştırılmadı, incelendi. Yeni çevrimdışı model kontrolleri ayrı olarak kaydedilir.

Tutulan geri döngü yakalaması, geçerliliği testten önce sona eren güvenilir laboratuvar CA'sı tarafından imzalanmış bir sertifikayı içerir; doğrulama kodu 10 ile başarısız oluyor, sertifikanın süresi doldu. Kendinden imzalı ayrı bir yaprak, kendinden imzalı sertifika olan doğrulama kodu 18 ile başarısız oluyor. Geçerli denetim aynı beklenen ana bilgisayar adıyla başarılı olur. Zaman damgalı el sıkışma kanıtları ve kamu sertifikaları muhafaza edilerek, süre sonu ve güven hatalarının ayrı ayrı incelenmesine olanak sağlanır. Özel anahtarlar geçicidir ve kaldırılmıştır. Gerçek hizmet yenileme sunumu ve tüm dinleyicilerin dağıtım doğrulaması bu laboratuvarın dışında kalacaktır. Tarihi taşıma koşucusu, şifreleme ve geridöngü soketlerine sahip Python'a ihtiyaç duyar. Sonuçları, mevcut hizmet durumu veya üretimin birlikte çalışabilirliği değil, sınırlı laboratuvar kanıtlarıdır.

Birincil kaynak temeli

Alan tanımları ve raporlama sınırları, RFC 8460 , SMTP TLS Raporlaması, bölüm 3 ve 4. STS doğrulamasının tartışıldığı yerlerde, bkz. RFC 8461. Operasyonel tavsiyeler protokol gerekliliklerinden farklıdır.

[ Götürmek ]

Gözlemleri doğru STS veya DANE güven modeli altında karşılaştırın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Hizmet verilen her zinciri inceleyin

Yapılandırma değişikliği yapmadan önce adlandırılmış koşulu yeniden oluşturun.

Sonraki adımlar

  1. Gerçekte sunulan sertifikayı yakalayın.
  2. Geçerlilik pencerelerini ve ara zincirleri karşılaştırın.
  3. Etkilenen her işlemin yeni sertifikayı yeniden yüklediğini doğrulayın.

CISO / SecOps

Güven modellerini açık tutun

Güvenlik sonuçlarını doğrulanmış kanıtlarla orantılı tutun.

Sonraki adımlar

  1. Doğrulamayı devre dışı bırakmadan güven hatalarını araştırın.
  2. Web PKI'yı DANE-EE güveninden ayırın.
  3. Önceki ve sonraki uç nokta parmak izlerini koruyun.

Kurucu / Teknik Olmayan

Kendi yenileme ve dağıtım

Sonucun hizmet sürekliliğinden sorumlu kişi için yararlı olmasını sağlayın.

Sonraki adımlar

  1. Sertifika dağıtımını ve yenilemeyi takip edin.
  2. Fon vadesinin dolma süresi ve sorumlu bir müdahaleci.
  3. Yedek dinleyicileri yenileme sahipliğine dahil edin.

[ SSS ]

Sık sorulan sorular

Güvenilmeyen sertifikanın süresinin dolduğu anlamına mı geliyor?

Mutlaka değil. Çoklu güven ve zincir hatalarını kapsar.

RFC 8460 §4.3.1

Başarılı yenileme dağıtımın kanıtı mıdır?

Hayır. Bir dinleyici önceki sertifikayı sunmaya devam edebilir.

Son nokta kanıtları neleri içermelidir?

Sunulan sertifika kimliği, geçerlilik aralığı, zincir, rota ve zaman damgası.

Yerel fikstür testi ne yapıyor?

Yeni çevrimdışı fikstür modelleri geçerlilik aralıkları. Ayrı olarak, 7 Kasım'da tutulan geridöngü yakalama belgelerinin süresinin dolması ve güven hataları; Bu inceleme için hiçbir ağ testi yeniden çalıştırılmadı.

Sertifika doğrulaması atlanmalı mı?

Hayır. Bir bypass, uyumlu bir üretim bağlantısı gösteremez.

Farklı gönderenlerin farklı güven sonuçları olabilir mi?

Evet. Doğrulama bağlamı ve güven depoları farklılık gösterebilir.

RFC 8461 §4.2

DANE-EE ve genel CA doğrulaması aynı mıdır?

Hayır. Güven modelleri farklıdır.

RFC 7672 §3.1.1

Raporlarda bir onarım ne zaman görünmelidir?

İlgili onarım sonrası oturumlar toplanıp teslim edildikten sonra.

RFC 8460 §4.1

[ Kaynaklar ]

Kaynaklar

  1. RFC 7672

    Bölümler §3.1.1

  2. RFC 8460

    Bölümler §4.1 · §4.3.1 · §4.3.2

  3. RFC 8461

    Bölümler §4.2

[ Sözlük ]

Sözlük

Sunulan sertifika
Sertifika, başka bir yerde depolanan bir yenileme yapıtı yerine, gerçekte test edilen TLS dinleyicisi tarafından sağlanır.
Güven çapası
STS sertifikası doğrulaması için gönderen MTA doğrulama bağlamında güvenilen bir kök CA.

RFC 8461 §4.2

DANE-EE
TLSA kullanımı 3, STS'den farklı ad ve süre sonu semantiğiyle DNSSEC korumalı ilişkilendirme aracılığıyla son varlık sertifikasının kimliğini doğrular.

RFC 7672 §3.1.1

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası