Microsoft Exchange altyapılarında sertifikalar güvenli TLS tabanlı iletişimin temel taşıdır. Özellikle Edge Transport ve Mailbox sunucuları arasındaki bağlantılarda doğru atanmış bir transport sertifikası olmadan hiçbir şey çalışmaz.
Daha da önemlisi birden fazla Edge ve Mailbox sunucusunun bulunduğu DAG (Database Availability Group) ortamlarında sertifika yönetimi kritik hale gelir. Bu tür yapılarda herhangi bir sunucunun devre dışı kalması mail akışını durdurmamalıdır.
Bu makalemde 2 Edge Transport sunucusu (DMZ Network’de yer almaktadır) ve 3 Mailbox sunucusundan oluşan bir DAG yapısında yaşanan gerçek bir sorunu ele alıyor Edge sunucularının DAG üyelerinden birine mail gönderememesi problemini ve çözüm sürecini adım adım aktarıyorum.
Ortam Yapısı
- 2 × Edge Transport Server (EDGE01, EDGE02)
- 3 × Mailbox Server (MBX01, MBX02, MBX03) – DAG üyesi
Beklenen Davranış
- EDGE01 ve EDGE02, DAG içindeki herhangi bir Mailbox sunucusuna mail gönderebilmeli.
- MBX01 devre dışı kalsa bile mail akışı MBX02 veya MBX03 üzerinden devam etmeli.
Sorun
- MBX01 devre dışı bırakıldığında,
- EDGE sunucuları MBX02’ye mail gönderemedi bağlantı denemeleri TLS sırasında başarısız oldu.
- MBX03 üzerinden mail akışı kısmen çalışıyordu ancak EDGE01 ile yapılan bazı oturumlarda yine hatalar alındı.
Edge Üzerindeki Hata Mesajları
LED=451 4.4.395 Target host responded with error. ->
454 4.7.5 Outbound direct trust authentication failed for the certificateLED=451 4.4.397 Error communicating with target host. ->
421 4.2.1 Unable to connect -> SocketTimedout: Socket error code 10060İnceleme sırasında ortaya çıktı ki:
- MBX02 üzerinde geçerli sertifika bulunuyordu, ancak SMTP servisine atanmadığı için Default Transport Certificate değildi.
- MBX03 üzerinde geçerli sertifika mevcuttu fakat EDGE01 ile uyumsuz bir thumbprint kullanıyordu.
- Sonuç olarak:
- EDGE01 → MBX02 iletişimi tamamen başarısız oldu.
- EDGE02 → MBX03 iletişimi zaman zaman başarısız oldu.
Bu durum DAG yapılarında sertifika tutarlılığının ne kadar kritik olduğunu bir kez daha gösterdi.
Çözüm Süreci
1. Sertifika Kontrolü
Her bir Mailbox sunucusunda mevcut sertifikaları listeledim:
Get-ExchangeCertificate | FL FriendlyName,Subject,NotAfter,Thumbprint,Services
- MBX01 → Doğru sertifika atanmıştı.
- MBX02 → Geçerli sertifika vardı, fakat SMTP servisine bağlı değildi.
- MBX03 → Sertifika atanmıştı ama EDGE01 üzerinde kullanılanla aynı değildi.
2. Tutarlılık Sağlamak için Sertifika Ataması
MBX1 üzerinde kullanılan geçerli sertifika referans alınarak MBX02 ve MBX03 üzerinde de aynı sertifika SMTP servisine atanıp Default Transport Certificate yapıldı:
Enable-ExchangeCertificate -Thumbprint <CertificateThumbprint> -Services SMTP
Bu adım sonucunda:
- MBX01, MBX02 ve MBX03 aynı geçerli sertifikayı kullanmaya başladı.
- Edge sunucuları ile TLS kimlik doğrulaması uyumlu hale geldi.
3. Mail Akışı Testleri
Her bir Mailbox sunucusu için mail akışı test edildi:
Test-Mailflow -TargetMailboxServer MBX01
Test-Mailflow -TargetMailboxServer MBX02
Test-Mailflow -TargetMailboxServer MBX03
Sonuç: Tüm testler başarılı.
4. Edge Sunucularının Davranışını Doğrulamak
Her iki Edge sunucusunda bağlantı testleri yapıldı:
Test-Mailflow -TargetMailboxServer MBX02 -ClientAccessServer EDGE01
Test-Mailflow -TargetMailboxServer MBX03 -ClientAccessServer EDGE02
- EDGE01 → MBX01, MBX02, MBX03 → Başarılı
- EDGE02 → MBX01, MBX02, MBX03 → Başarılı
Artık herhangi bir Mailbox sunucusu devre dışı kalsa bile mail akışı sorunsuz devam ediyordu.
Sertifika Tutarlılığı Şarttır
DAG yapısında birden fazla Mailbox sunucusu varsa, tüm sunucularda aynı geçerli transport sertifikası kullanılmalı.
Varsayılan Atama Hayati Önem Taşır
Sertifika yüklemek yetmez; ilgili servislere atanmalı ve Default Transport Certificate olarak işaretlenmelidir.
Çoklu Edge Senaryolarında Daha Kritik
Birden fazla Edge sunucusu olduğunda, farklı sertifikalar Edge → Mailbox iletişimini kararsız hale getirebilir.
Düzenli İzleme ve Proaktif Yönetim
Yaklaşan sertifika süre sonlarını kontrol etmek için.
Get-ExchangeCertificate | Where-Object {$_.NotAfter -lt (Get-Date).AddDays(30)} | Select FriendlyName,Subject,NotAfterBu komut sayesinde sertifika bitişleri ve yanlış atamalar önceden fark edilebilir.
Bu olayda görüldüğü gibi 2 Edge Transport ve 3 Mailbox (DAG üyesi) içeren bir ortamda mail akışının durmasının nedeni, basit gibi görünen bir yapılandırma hatasıydı. Sertifikalar yüklenmişti ancak MBX02 ve MBX03 üzerinde doğru servislere atanmadığı için TLS oturumları başarısız oldu. Sorun tüm Mailbox sunucularında aynı geçerli sertifikanın SMTP servisine atanması ve varsayılan transport sertifikası yapılması ile kalıcı şekilde çözüldü.
