Ağ bağlantısı ve ilk SMTP komutları zaten çalıştıktan sonra bir SMTP TLS hatası meydana gelebilir. Gönderen, bir protokol sürümü üzerinde anlaşamayabilir, bir sertifikayı reddedebilir veya el sıkışma sırasında bir kesinti yaşayabilir. Bunları, gönderenin doğrudan kanıt olarak değil, aktarım katmanı gözlemleri olarak ele alın. SPF veya DKIM kayıt yanlış.
Taşıma modunu tanımlayın
SMTP şununla STARTTLS, istemci önce SMTP kurar, yetenek bildirimini alır, STARTTLS talep eder ve ardından sunucunun hazırlık yanıtından sonra TLS anlaşmasını başlatır. Örtülü TLS bağlantı kurulduğunda TLS hemen başlatır ve genellikle desteklenen bir gönderim hizmeti için kullanılır. Bu beklentilerin bir araya gelmesi, yararlı bir posta alışverişi gerçekleşmeden bağlantının başarısız olmasına neden olabilir. RFC 3207 bölüm 4 ve 5.
Hedefi, bağlantı noktasını, modu, gönderme yazılımını, uzaktan SMTP karşılamasını ve reklamı yapılan özellikleri kaydedin. Başarısızlığın STARTTLS teklif edilmeden önce mi, STARTTLS komutundan sonra mı, sertifika işleme sırasında mı yoksa el sıkışma sonrasında mı meydana geldiğini koruyun. Özel anahtarları, parolaları veya oturum sırlarını tanılama paketine kopyalamaktan kaçının. Sertifika meta verileri ve düzeltilmiş protokol hataları genellikle belirsiz bir "güvenli bağlantı başarısız oldu"dan daha faydalıdır.
Sertifikaları gerçek politikaya göre değerlendirin
Süresi dolmuş bir sertifika, desteklenmeyen protokol, tamamlanmamış zincir veya kimlik uyumsuzluğu, farklı gönderme politikaları kapsamında farklı şekilde önem taşıyabilir. Sıradan fırsatçı SMTP TLS tarafından yönetilen bir bağlantıyla aynı güvence modeli değildir. MTA-STS veya kimliği doğrulanmış DANE. Gönderenin teslimatı neden ertelediğini yorumlamadan önce uygulanan politikaya bir ad verin. Her SMTP uygulamasının her sertifikayı aynı şekilde doğruladığını varsaymayın.
RFC 8461 MTA-STS politikasının keşfi, doğrulanması ve uygulama davranışını belirtir. RFC 7672 DNSSEC kimlik doğrulamasını kullanan DANE SMTP aktarım güvenliğini tanımlar TLSA bilgi. Bu mekanizmaların kendi gereksinimleri ve arıza yönetimi vardır. Bunların varlığı, yalnızca bir günlükte TLS hatası göründüğü için çıkarım yapılmadan, gerçek gönderen yapılandırmasından ve ilgili keşif kanıtlarından doğrulanmalıdır.
Varsayımsal bir kimlik başarısızlığının üstesinden gelin
Yetkili bir gönderim istemcisinin submit.example konumunda örtülü TLS için yapılandırıldığını, ancak sertifika hatasının old-submit.example öğesinin beklenen kimliğini gösterdiğini varsayalım. Öncelikle hizmetin belgelenen mevcut uç noktasını ve istemcinin bu uç noktaya ulaşıp ulaşmadığını doğrulayın. Yalnızca görünen sertifikanın geçmesini sağlamak için beklenen adı değiştirmeyin.
Hizmet sahibi submit.example doğru olduğunu onaylarsa ve sertifika ve zincir bu uç nokta için geçerli gereksinimleri karşılıyorsa, onaylı bir istemci yapılandırma düzeltmesi uyumsuzluğu çözebilir. Uç nokta doğru ancak sertifika yanlışsa bunun yerine servis sertifikasını onarın. Doğrulamayı her iki yolda da etkin tutun ve düzeltmeden sonra aynı hizmeti yeniden kontrol edin.
Bu, yürütülen bir el sıkışma, sertifika verme veya talep edilen TLS sürümü değil, varsayımsal bir karar ağacıdır. MX teslimatı için gönderim-istemci varsayımını içe aktarmak yerine gerçek MTA-STS veya DANE kimlik kurallarını kullanın. HTTPS ana sayfa sertifikası, SMTP uç noktasının sertifikasını veya ilkesini oluşturmaz.
Korumayı silmeden nedeni düzeltin
Hizmet sahibine sertifika yenileme ve zincir dağıtımını, posta platformu sahibine protokol uyumluluğunu ve ağ ekibine müdahale veya yol kesintilerini atayın. Bir sertifikayı değiştirmeden önce beklenen MX kimliğini ve geçerli politikayı kontrol edin. Her seferinde onaylanmış bir düzeltme yapın ve bir geri alma planını koruyun.
Sertifika uyarısını atlamayın, zorlamayı devre dışı bırakmayın veya yalnızca test geçişi yapmak için düz metinlere izin vermeyin. Gönderenin geri çekilip çekilemeyeceği protokole ve yönetim politikasına bağlıdır; katı politika, güvensiz bir şekilde teslim etmek yerine kasıtlı olarak erteleyebilir. Başarılı, güvenli olmayan bir yeniden deneme, TLS sorununun çözüldüğünü göstermez.
Yeniden başlatılan SMTP oturumunu doğrulayın
RFC 3207 başarılı STARTTLS sonrasında TLS öncesi SMTP bilgilerinin atılmasını gerektirir; müşteri göndermelidir EHLO İlk önce korumalı oturumun önceki listeden farklı olabilecek yeteneklerini keşfedeceksiniz. Gerçek olduğunu doğrulayın MTA bu geçişi tamamlar ve ardından yetkili mesajı aktarır. Devam eden kuyruk gecikmelerini ve nihai sonucu, el sıkışma başarısından ayrı olarak kaydedin. TLS taşıma atlama noktasını korur; tek başına görünen yazarın meşruiyetini, uçtan uca içerik gizliliğini veya gelen kutusu yerleşimini belirlemez.
TLS onarırken güvenlik gereksinimini koruyun
- Uç nokta, bağlantı noktası, STARTTLS veya örtülü modu ve tam olarak başarısız olan aşamayı yakalayın.
- Sertifikayı değiştirmeden önce etkin ilkeyi ve beklenen kimliği tanımlayın.
- Ad, geçerlilik, güven zinciri ve protokol hatalarını ayırın; sırları günlüklerden hariç tutun.
- Doğrulamayı devre dışı bırakmadan onaylanmış, nedene özel bir onarım uygulayın.
- Politika uyumlu TLS , STARTTLS sonrası durum sıfırlamayı ve mesaj sonucunu bağımsız olarak onaylayın.