Teams Direct Routing TLS Sertifika Hatası ve Çözümü (2026)

Özet (TL;DR): Şubat 2025'te Google'ın Chrome Kök Program Politikası'nda (Chrome Root Program Policy v1.6) yaptığı değişiklik yüzünden Microsoft, Teams Direct Routing SIP arayüzünün TLS sertifikalarını yeni bir kök sertifika otoritesine (CA) taşıdı — değişiklik Temmuz 2026 sonunda üretim ortamına alındı. SBC'nizin (Session Border Controller — Teams ile mevcut telefon hattınız arasındaki köprü cihazı) güven deposunda yedi yeni kök sertifika yoksa TLS el sıkışması (handshake) başarısız olur, görüşmeler aniden kopar ve SBC, Teams yönetim merkezinde "Inactive" görünür. Bu yazıda belirtilerden kök nedene, adım adım çözümden Türkiye'de yaygın AudioCodes/Ribbon SBC senaryolarına kadar tüm süreci; Microsoft'un resmi Direct Routing güncellemeleri ve SBC bağlantı sorunları giderme makalelerine dayanarak anlatıyoruz.

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı (2016'dan bu yana) · MS-100/MS-102/AZ-104 sertifikalı danışmanlar. Bu yazıdaki hata mesajları, tarihler ve sertifika listeleri Microsoft'un resmi Learn dokümantasyonundan ve Microsoft Q&A'daki gerçek bir vakadan alınmıştır; kaynak tarihleri metin içinde belirtilmiştir.

Şubelerinizdeki veya çağrı merkezinizdeki Teams telefonları aniden "aranan kişiye ulaşılamıyor" ya da tek yönlü ses vermeye başladıysa vakit kaybetmeyin — Xen Bilişim'den ücretsiz SBC sağlık kontrolü isteyin, sertifika zincirinizi birlikte 15 dakikada doğrulayalım.

Belirtiler: Direct Routing'te Çağrılar Neden Kesiliyor?

Sorun genelde aniden başlar: dün sorunsuz çalışan Teams Phone hattı, bugün gelen veya giden aramalarda "Bir sorun oluştu" hatası veriyor ya da hiç kurulamıyor. Microsoft Teams yönetim merkezinde Voice → Direct Routing sayfasına girdiğinizde SBC'nizin durumu şu üç halden birinde takılı kalır:

• Inactive — SBC, Microsoft'un SIP proxy'sine (sip.pstnhub.microsoft.com) bağlanamıyor veya bağlantı kurar kurmaz kesiliyor; en sık görülen durum.
• Aralıklı (intermittent) Inactive — bazı çağrılar geçiyor, bazıları TLS aşamasında düşüyor; genelde bölgesel sertifika dağıtımının kademeli ilerlemesiyle ilgilidir.
• Aktif ama tek yönlü ses / erken kopma — SIP sinyalleşmesi geçiyor ama medya (RTP) yolunda ara cihazlardan biri (güvenlik duvarı, vekil sunucu) eski sertifika zincirine takılıyor.

SBC üretici günlüklerinde (AudioCodes, Ribbon, Oracle) tipik olarak şuna benzer bir iz görürsünüz — bu, gerçek bir Microsoft Q&A vakasından (3 Şubat 2026, AudioCodes SBC) alınmıştır:

TLSSocketAPI(#569)::HandshakeCompleted - TLS handshake success
TLSSocketAPI(#569)::ResendWaitingMessage - Resending message succeeded after retrying 11 times
TLSSocketAPI(#569)::HandleDisconnectEvent(EVENT_RECEIVER_DISCONNECT)
TLSSocketAPI(#569)::DispatchQueueEvent(EVENT_RECEIVER_DISCONNECT) - Closing connection.

Dikkat edilmesi gereken nokta: TLS el sıkışması "success" (başarılı) görünse bile bağlantı hemen ardından kapanıyor. Bu, sertifikanın SBC tarafından teknik olarak kabul edildiği ama zincirin (chain) Microsoft'un beklediği yeni kök otoriteye tam olarak bağlanamadığı, ya da tam tersi — SBC'nin Microsoft'un yeni sunucu sertifikasına güvenmediği anlamına gelir.

Durum	Ne anlama gelir
SBC "200 OK" almıyor	Eski TLS sürümü ya da SBC sertifikası güvenilir bir CA'dan değil
"200 OK" geliyor ama SIP options gelmiyor	Firewall, Microsoft'un SIP proxy IP aralıklarına gelen bağlantıya izin vermiyor
SBC aralıklı Inactive oluyor	SBC, FQDN yerine sabit IP'ye bağlanıyor; bakım sırasında IP değişince kopuyor
TLS handshake sonrası anında kopma	SBC güven deposunda yeni kök CA'lar (DigiCert / Microsoft 2017 Root) eksik — 2026 sertifika değişikliğinin doğrudan belirtisi

Hızlı Tanı: Microsoft'un Resmi Kontrol Sırası

Panikle SBC'yi baştan yapılandırmadan önce, Microsoft'un Direct Routing Health Dashboard'ını (Teams yönetim merkezi içinde) kontrol edin — SBC'nizin sertifikasının süresi dolmuş mu, iptal edilmiş mi (revoked), yoksa güven zinciri mi eksik, burada ayrıştırılır. Sırasıyla:

1. Teams yönetim merkezi → Voice → Direct Routing → SBC'nizin durumuna ve son "son görüldü" (last seen) zaman damgasına bakın.
2. SBC üzerinde paket yakalama (packet capture) açıp sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com ve sip3.pstnhub.microsoft.com'a giden TLS Client Hello / Server Hello alışverişini izleyin.
3. SBC'nin güven deposunda (trust store) yüklü kök sertifikaları listeleyin — üretici arayüzünde genelde "Trusted Root Certificates" veya "CA Certificates" başlığı altındadır.
4. SBC sertifikanızın CN/SAN (Common Name / Subject Alternative Name) alanının, Direct Routing'e kayıtlı FQDN ile birebir eşleştiğini doğrulayın — joker (wildcard) sertifikalar yalnızca tek seviye alt alan adını karşılar.

Not: Microsoft, Şubat 2026'da sip.g1.pstnhub.microsoft.com:5061 adresinde yalnızca SIP OPTIONS testi için özel bir doğrulama uç noktası sağlamıştı; bu uç nokta artık kullanımdan kaldırılmıştır çünkü yeni CA'lı sertifikalar Temmuz 2026 sonunda zaten üretime alınmıştır. Test yerine doğrudan üretim SBC'nizin canlı bağlantısını health dashboard üzerinden izleyin.

Kök Neden: 2026 Sertifika Otoritesi (CA) Değişikliği

Bu sorunun kaynağı Microsoft'ta bir hata değil, tarayıcı ekosisteminde üst taraftan gelen bir zorunluluk. Şubat 2025'te Google, Chrome Root Program Policy v1.6 ile TLS sunucu sertifikalarında "Client Authentication" EKU'sunun (Extended Key Usage — sertifikanın hangi amaçla kullanılabileceğini belirten alan) kullanımdan kaldırılacağını duyurdu. Haziran 2026'dan itibaren tarayıcı güven depolarında kalabilmek için sertifikaların yalnızca "Server Authentication" EKU'su taşıması gerekiyor.

Bu yüzden Microsoft, Direct Routing ve Operator Connect'in SIP arayüzünde kullandığı TLS istemci/sunucu sertifikalarını yeni bir kök zincirine — DigiCert tabanlı köklere ve kendi Microsoft 2017 Root CA'larına — taşıdı. Resmi Microsoft Learn "What's New" sayfasına göre desteklenen yedi kök sertifika şu şekilde:

• DigiCert Global Root CA
• DigiCert Global Root G2
• DigiCert Global Root G3
• DigiCert TLS ECC P384 Root G5
• DigiCert TLS RSA 4096 Root G5
• Microsoft ECC Root Certificate Authority 2017
• Microsoft RSA Root Certificate Authority 2017

Zaman çizelgesi şöyle işledi: SBC tarafında güven deposu güncellemesi için son tarih Mart 2026 sonu olarak belirlendi; Microsoft sunucu tarafı değişikliklere Nisan 2026'dan itibaren başladı. Kademeli geçişi doğrulamak için 30 Haziran 2026, 09:00 UTC'de coğrafi bölgelere göre 2-4 gün süren bir doğrulama testi yapıldı. Test tamamlandıktan sonra yeni CA'lı sertifikalar Temmuz 2026 sonunda üretim ortamına tam olarak alındı. Kısacası: bu makaleyi okuduğunuz an itibarıyla değişiklik artık aktif ve kalıcı — güven deposu güncellenmemiş her SBC, er ya da geç TLS el sıkışmasında başarısız olacak.

Adım Adım Çözüm

Aşağıdaki adımları en kolaydan en zora doğru sırayla uygulayın; çoğu vakada 1-3. adımlar sorunu tek başına çözer.

1. Güven deposunu (trust store) güncelleyin. Yukarıdaki yedi kök sertifikanın tamamının SBC'nizin güvenilir kök CA listesinde olduğunu doğrulayın; eksik olanları üreticinizin (AudioCodes, Ribbon, Oracle SBC) resmi sertifika paketinden indirip yükleyin. Tek bir kök eksik olması bile zinciri kırar.
2. TLS sürümünü doğrulayın. SBC'de TLS 1.2 veya üzeri zorunlu olmalı; TLS 1.0/1.1 hâlâ etkinse devre dışı bırakın — Microsoft'un SIP proxy'si bu sürümlerle el sıkışmayı reddediyor.
3. SBC sertifikanızın kendisini kontrol edin. Kendinden imzalı (self-signed) bir sertifika kullanıyorsanız bu artık kabul edilmiyor; sertifikanın güvenilir bir CA'dan (Microsoft Trusted Root Program listesinde yer alan) alınmış olması ve CN/SAN alanının Direct Routing'e kayıtlı FQDN ile birebir eşleşmesi gerekir.
4. Record-Route ve Contact başlıklarını (header) inceleyin. SBC'nin gönderdiği SIP mesajlarında FQDN yerine yanlışlıkla IP adresi geçiyorsa, Microsoft'un SIP proxy'si SBC'yi tanıyamaz ve "200 OK" gelse bile SIP options iletilmez.
5. Ağ yolundaki ara cihazları kontrol edin. Güvenlik duvarınızın veya vekil sunucunuzun sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com ve sip3.pstnhub.microsoft.com (veya toplu çözümleme için sip-all.pstnhub.microsoft.com) adreslerine giden 5061 portu TLS trafiğini kesmediğinden emin olun; bazı eski güvenlik duvarı kuralları IP tabanlı yazıldığı için Microsoft'un IP aralığı değiştiğinde sessizce trafiği düşürür.
6. SBC'yi bakım penceresinde yeniden başlatın. Sertifikayı veya güven deposunu güncelledikten sonra, eski sertifikayla kurulmuş TLS oturumları hâlâ önbellekte kalabilir. Düşük trafikli bir saatte SBC'yi yeniden başlatarak (veya üreticinizin belgelediği yöntemle eski TLS bağlantılarını zorla kapatarak) yeni sertifikanın devreye girmesini sağlayın.

Uzaktan destek almadan önce ortamınızın hangi adımda takıldığını netleştirmek isterseniz Xen Bilişim'in Microsoft 365 uzmanlarıyla 15 dakikalık ücretsiz görüşme ayarlayabilir ya da doğrudan WhatsApp'tan yazabilirsiniz.

Senaryoya Özel Dallar: AudioCodes, Ribbon ve Operator Connect Kullanıcıları

Bu sorun herkesi aynı şekilde etkilemiyor — hangi bağlantı modelini kullandığınız çözüm yolunu değiştiriyor:

• AudioCodes Mediant SBC kullananlar: Güven deposu güncellemesi genelde SBC yönetim arayüzünde "Trusted Root Certificate Store" bölümünden yapılır; AudioCodes'un yayımladığı mTLS sertifika rehberini takip edin, üretici genelde sertifika paketini tek dosya olarak sunar.
• Ribbon (Sonus) SBC kullananlar: Sertifika yönetimi "Security → Certificates" altında; yeni kök CA'ları ayrı ayrı içe aktarmanız (import) gerekebilir, toplu paket desteği sürüme göre değişir.
• Operator Connect kullananlar: Bu makaledeki sorun sizi etkilemez — sertifika yönetimi tamamen operatörünüzün (Türk Telekom, Turkcell, Vodafone) altyapısında gerçekleşir, Microsoft'un resmi belgesi bu rehberin yalnızca Direct Routing dağıtımları için geçerli olduğunu açıkça belirtir.
• Microsoft Calling Plan kullananlar: Aynı şekilde etkilenmezsiniz; ancak hatırlatalım, Calling Plan Türkiye'de resmi olarak sunulmuyor, bu yüzden TR'deki kurumların neredeyse tamamı zaten Direct Routing ya da Operator Connect kullanıyor.

Yönetici Tarafı Kontroller

SBC tarafını düzelttikten sonra, sorunun tenant (kiracı) tarafında gizli bir nedeni olmadığından emin olun:

• SBC domain adının Microsoft 365'te tam olarak doğrulanmış olduğunu kontrol edin.
• SBC FQDN'sine en az bir Teams Phone (E3/E5 + Phone System veya Phone Standard eklentisi) lisanslı kullanıcı atanmış olmalı — atama yapılmadan domain aktivasyonu tamamlanmaz ve bu işlem 24 saate kadar sürebilir.
• Teams yönetim merkezinde SBC'nizin "son görüldü" zaman damgasını, sorunun başladığı saatle karşılaştırarak sertifika değişikliğiyle mi yoksa ayrı bir olayla mı (bakım, IP değişikliği) çakıştığını netleştirin.

Log Toplama ve Microsoft Destek Talebi Hazırlığı

Yukarıdaki adımlar sonuç vermezse Microsoft desteğine (veya Kayıtlı İş Ortağınıza) başvurmadan önce şunları hazırlayın — destek süresini gözle görülür şekilde kısaltır:

• SBC'nin sorun anındaki TLS/SIP günlükleri (yukarıdaki örnektekine benzer TLSSocketAPI veya eşdeğer üretici log satırları).
• SBC üzerinde yüklü güven deposu sertifikalarının tam listesi (thumbprint/parmak izi ile).
• Sorunun başladığı tarih/saat (UTC) ve etkilenen çağrı yönü (gelen/giden/her ikisi).
• SBC ile sip.pstnhub.microsoft.com arasındaki paket yakalama (varsa) — TLS Client Hello / Server Hello alışverişini gösteren kısım yeterli, ses içeriği paylaşmanıza gerek yok.

Önleyici Kontroller: Bir Daha Yaşamamak İçin

Bu, Microsoft'un son yıllarda yaptığı ilk kök sertifika değişikliği değil ve son da olmayacak. Kalıcı bir izleme disiplini kurmak için:

• Direct Routing Health Dashboard'ı haftalık kontrol listesine ekleyin; SBC durumu "Inactive"e geçtiği anda uyarı üreten bir izleme (Azure Monitor, SBC üreticisinin kendi alarm sistemi veya basit bir SIP OPTIONS ping betiği) kurun.
• SBC sertifikanızın son kullanma tarihini takvime işleyin; yenileme sırasında hem sertifikayı hem de eski TLS oturumlarının temizlendiğinden emin olun.
• Microsoft'un Direct Routing "What's New" sayfasını üç ayda bir gözden geçirin — bu tür alt yapı değişiklikleri genelde aylar önceden burada duyurulur.
• Güvenlik duvarı kurallarınızı FQDN yerine yalnızca sabit IP'lere göre yazmaktan kaçının; Microsoft'un SIP proxy IP aralıkları zaman zaman değişebiliyor.

Türkiye'de Direct Routing Neden Bu Kadar Yaygın?

Bu sorunun Türkiye'deki kurumları orantısız etkilemesinin somut bir nedeni var: Microsoft Calling Plans Türkiye'de resmi olarak sunulmuyor. Yani bir kurum Teams'i gerçek bir telefon santraline dönüştürmek istediğinde elinde pratikte iki seçenek kalıyor — operatörün doğrudan entegre olduğu Operator Connect (Türk Telekom, Turkcell, Vodafone) ya da mevcut SIP trunk'ınızı kendi SBC'niz üzerinden bağladığınız Direct Routing. Saha tecrübemize göre, özellikle daha önce klasik bir PBX'ten (Avaya, Cisco gibi) geçiş yapan orta-büyük ölçekli kurumlar, mevcut SIP trunk yatırımlarını korumak için Direct Routing'i tercih ediyor — bu da onları doğrudan bu tür sertifika değişikliklerinin etkisi altında bırakıyor.

İkinci bir TR-özel katman: SBC üzerinden geçen paket yakalama ve destek kaydı verilerini Microsoft'a veya üçüncü bir tedarikçiye iletirken KVKK'nın (6698 sayılı Kişisel Verilerin Korunması Kanunu) 12. maddesindeki "gerekli teknik tedbir" yükümlülüğünü unutmayın — TLS handshake günlükleri kişisel veri içermez ama görüşme içeriği veya arayan/aranan numara listeleri paylaşılacaksa, bunları yalnızca sorunun teşhisi için gerekli en az veriyle sınırlı tutmak ve mümkünse maskeleyerek göndermek kurumunuzu gereksiz bir uyumluluk riskinden korur.

Saha Vakası: 140 Kişilik Bir Lojistik Firmasında Sessiz Kesinti

Firma X — İstanbul merkezli, 140 kişilik bir lojistik ve gümrük müşavirliği firması — üç yıldır AudioCodes Mediant SBC ile Direct Routing üzerinden Teams Phone kullanıyordu. Ağustos 2026'nın ikinci haftasında, gümrük operasyon ekibinin dış hat aramalarının bir kısmı rastgele düşmeye başladı; sorun her aramada değil, günün belirli saatlerinde ortaya çıkıyordu, bu da ilk etapta operatör kaynaklı bir sorun gibi göründü.

Süre: teşhis + çözüm 1 iş günü. Karar noktaları: (1) SBC günlüklerinde TLS handshake sonrası ani kopmalar tespit edildi; (2) güven deposu listesi çıkarıldığında yedi yeni kök sertifikadan üçünün (DigiCert TLS ECC P384 Root G5 dahil) eksik olduğu görüldü — SBC üç yıl önce kurulduğunda bu kökler henüz yayımlanmamıştı; (3) sertifikalar üreticinin güncel paketinden yüklendi, düşük trafikli bir saatte SBC yeniden başlatıldı. Sonuç: kesintiler tamamen durdu, ek donanım veya lisans maliyeti oluşmadı.

Xen ekibinin rolü: uzaktan log analizi + güven deposu güncellemesi + bakım penceresi planlaması, toplam 3 saatlik uzaktan çalışma. Uyarı: bu vakada sorun "aralıklı" göründüğü için firma önce operatörüyle günlerce yazıştı — SBC tarafı ilk kontrol noktası olsaydı bu süre kısalabilirdi.

Sıkça Sorulan Sorular (SSS)

Bu sorun yalnızca Direct Routing kullananları mı etkiliyor?

Evet. Microsoft'un resmi belgesi bu rehberin yalnızca Direct Routing dağıtımları için geçerli olduğunu, Calling Plan veya Operator Connect dağıtımlarını kapsamadığını açıkça belirtiyor — çünkü bu iki modelde sertifika yönetimi tamamen Microsoft veya operatör tarafında gerçekleşiyor, sizin SBC'niz yok.

Değişiklik hâlâ devam ediyor mu, yoksa tamamlandı mı?

Yeni CA'lı sertifikalar Temmuz 2026 sonunda üretim ortamına tam olarak alındı ve doğrulama test uç noktası (sip.g1.pstnhub.microsoft.com:5061) kullanımdan kaldırıldı. Yani değişiklik artık tamamlanmış ve kalıcı durumda; güven deposu güncellenmemiş SBC'ler bugün hâlâ etkileniyor olabilir.

SBC'mi yeniden başlatmak sorunu tek başına çözer mi?

Genelde hayır. Güven deposunda eksik kök sertifika varsa, yeniden başlatma SBC'yi aynı eksik listeyle tekrar açar ve sorun devam eder. Yeniden başlatma yalnızca sertifikaları güncelledikten sonra eski TLS oturumlarını temizlemek için gereklidir, tek başına çözüm değildir.

Hangi kök sertifikaların yüklü olduğunu nasıl kontrol ederim?

SBC üreticinizin yönetim arayüzünde genelde "Trusted Root Certificate Store" veya "CA Certificates" adlı bir bölüm bulunur; buradan yüklü kökleri parmak izi (thumbprint) bazında listeleyip Microsoft'un yayımladığı yedi kök sertifika listesiyle karşılaştırabilirsiniz.

Sorunu kendimiz çözemezsek Microsoft desteğine mi, iş ortağımıza mı başvurmalıyız?

Her iki yol da geçerli: Microsoft destek kaydı açabilir (TLS/SIP günlüklerinizi eklemeniz istenecektir) veya Microsoft Kayıtlı İş Ortağınızdan (Xen Bilişim gibi) uzaktan teşhis desteği alabilirsiniz. İkincisi genelde daha hızlıdır çünkü ortamınıza ve SBC yapılandırmanıza zaten aşinadır.

Bu değişiklik Operator Connect'e geçersem tekrar yaşanır mı?

Operator Connect'te sertifika yönetimi tamamen operatörün altyapısında olduğu için bu spesifik sorunu bir daha yaşamazsınız; ancak Operator Connect kendi bağımlılıklarını (operatör SLA'sı, fiyatlandırma) getirir — SBC yönetimini tamamen dışarıda bırakmak isteyen kurumlar için değerlendirilebilecek bir alternatiftir.

Türkiye'de hangi SBC markaları Direct Routing için sertifikalı?

En yaygın kullanılanlar AudioCodes Mediant ailesi ve Ribbon (eski adıyla Sonus) SBC'lerdir; her ikisi de Microsoft'un sertifikalı SBC listesinde yer alır ve bu makaledeki güven deposu güncellemesi adımları her iki üretici için de (arayüz farklılıkları dışında) aynı mantıkla işler.

Sonuç: Sessiz Bir Alt Yapı Değişikliği, Gürültülü Bir Kesinti

2026 sertifika otoritesi değişikliği, Microsoft'un tarafında aylar önceden duyurulmuş, teknik olarak gerekçelendirilmiş bir adımdı — ama SBC'sinin güven deposunu takip etmeyen kurumlar için tamamen habersiz, "aniden çağrılar kesiliyor" şeklinde bir kriz olarak yaşandı. İyi haber: kök neden tek ve net — eksik kök sertifikalar — ve çözümü de tek bir bakım penceresinde tamamlanabiliyor.

Asıl kalıcı değer, bu sorunu tekrar tekrar yaşamamaktan geçiyor: Direct Routing Health Dashboard'ı düzenli izlemek, sertifika yenileme takvimini otomasyona bağlamak ve Microsoft'un "What's New" duyurularını üç ayda bir taramak, bir sonraki kök sertifika rotasyonunda sizi hazır yakalar. Türkiye'deki kurumlar için buna bir de KVKK uyumlu log paylaşımı disiplini eklenmeli.

Kurumunuzda Direct Routing SBC yönetimi, sertifika izleme veya Teams Phone kurulumu için destek arıyorsanız, Microsoft 365 & Teams hizmetlerimize ya da güvenli bağlantı ve sertifika yönetimi çözümlerimize göz atabilir, ilgili kurulum rehberimizi (Microsoft Teams Phone nasıl kurulur?) inceleyebilir ya da benzer bir "sensor/agent inaktif" senaryosu için (Defender for Endpoint sensor inactive çözümü) yazımıza bakabilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Teams Phone ve Direct Routing altyapısını uçtan uca — kurulumdan sertifika izlemeye, olay müdahalesinden önleyici bakıma kadar — yönetiyoruz. İletişim sayfamızdan bize ulaşın.