Exchange Server 2019'da SSL Wildcard Sertifika Yapılandırma

Exchange Server 2019 üzerinde Wildcard SSL Certificate yapılandırmak, özellikle Public DNS üzerinde barındırılan çok sayıda farklı isimle çalışan servislerin tek bir sertifika üzerinden güvenliğini sağlamak isteyenler için en esnek ve yönetilebilir yöntemlerden biridir. Özellikle Autodiscover, OWA, ECP, ActiveSync gibi servislerin tamamını tek bir Wildcard SSL Certificate ile kapsamak, hem kurulum hem de yönetim tarafında ciddi anlamda kolaylık sağlar. Ancak bu kolaylığın arka planında oldukça dikkat edilmesi gereken teknik detaylar da barındığını söylemek gerekiyor.

Wildcard SSL Certificate tanımlanırken yapılacak en ufak bir hata, Exchange Server üzerindeki Client erişimlerinde karmaşık hatalara sebep olabilir. Bu yüzden özellikle Internal URL ve External URL tanımlamaları, sertifikanın hangi Subject Alternative Name değerlerini kapsadığı, IIS üzerindeki Binding yapılandırmaları ve Receive Connector gibi bileşenlerin sertifikayı doğru şekilde tanıyıp kullanabilmesi gibi başlıklar titizlikle ele alınmalı. Birçok kişi sadece sertifikayı Import edip Assign to Services diyerek işi tamamladığını düşünse de, gerçek senaryo çoğunlukla bu kadar basit ilerlemez. Çünkü arka planda IIS binding'lerinde yer alan Host Name'lerin, Exchange üzerindeki URL tanımlarının ve DNS kayıtlarının tamamı bu yeni Wildcard sertifika ile uyumlu hale getirilmelidir.

Bu yapılandırmayı yaparken özellikle Internal Client'ların DNS üzerinden ilgili servis isimlerini çözümleyip çözümlenen ismin sertifikada karşılık bulup bulmadığı test edilmelidir. Çünkü Outlook veya mobil cihazlar gibi Client'lar, genellikle bu tür SSL uyuşmazlıklarını direkt olarak bağlantıyı keserek veya sertifika hatası vererek yansıtır. Sertifikanın çalıştığını varsaymak yerine, Autodiscover testleri, Outlook Connectivity testleri ve IIS üzerinden yapılan bağlantı kontrol testleriyle her bir erişim noktası ayrıca gözden geçirilmelidir.

Wildcard SSL Certificate kullanımı her ne kadar genel yapıda işleri konsolide etmek için tercih edilse de, beraberinde getirdiği bazı sınırlamaları da göz ardı etmemek gerekir. Özellikle sertifikanın SAN içeriğinde yer almayan spesifik isimler üzerinden erişim yapılması gerekiyorsa, bu senaryolar için ek Subject Alternative Name içeren Multi-SAN Certificate gibi farklı yapıların düşünülmesi gerekebilir. Ancak Public alan adı *.firatboyan.com şeklinde ise ve Exchange servisleri de bu isimler altında çalışacak şekilde planlanmışsa, Wildcard SSL Certificate bu noktada en mantıklı ve sade çözüm olarak öne çıkar.

Exchange Server 2019 mimarisinde, SSL sertifikasının sadece güvenlik için değil, aynı zamanda servislerin düzgün şekilde çalışması açısından da doğrudan etkisi bulunur. Bu yüzden yapılacak her değişikliğin, ActiveSync erişimlerinden tutun da, Outlook Anywhere (RPC Over HTTP) veya MAPI Over HTTP oturumlarına kadar birçok servis davranışını değiştirme potansiyeli vardır.

Sonuç kısmına gelindiğinde söylenecek tek şey, bu yapılandırmanın sıradan bir SSL kurulumundan çok daha fazlasını içerdiğidir. Exchange mimarisine hâkim olmadan yapılacak her adım, dış dünyaya açık olan bu platformun erişilebilirliğini doğrudan etkiler. Bu yüzden yapının tüm bileşenlerini anlamak ve her değişikliğin olası yansımalarını öngörmek, sorunsuz bir Wildcard SSL Certificate entegrasyonu için olmazsa olmazdır.

Exchange Server üzerinde Virtual Directory URL'lerini tanımlarken, OWA, ECP, EWS, OAB, MAPI, Outlook Anywhere gibi servisler için mail.firatboyan.com adresini kullanmıştık. Autodiscover servisi için ise autodiscover.firatboyan.com tanımlaması yapmıştık. Wildcard sertifika kullanarak, hem bu servislerin bağlantılarını güvenli hale getiriyor hem de firatboyan.com ile ilişkili diğer tüm DNS kayıtlarını aynı sertifikaya dahil edebiliyoruz. Bu, yalnızca Exchange Server için değil, aynı zamanda Web siteniz ve diğer Sub-Domain'leriniz için de büyük bir kolaylık sağlar.

Wildcard Sertifika Örnek URL Kullanımları

✔ mail.firatboyan.com (OWA, ECP, EWS, OAB, MAPI, Outlook anywhere)
✔ owa.firatboyan.com (OWA)
✔ posta.firatboyan.com (OWA)
✔ autodiscover.firatboyan.com (Autodiscover)
✔ www.firatboyan.com (Web)
✔ ftp.firatboyan.com (Web)

Yapılandırma sürecinde temelde iki önemli adım var. İlk olarak SSL/TLS Wildcard sertifikamız için bir Certificate Request (CSR) oluşturacağız. Bu adımda, sertifika için gerekli bilgileri içeren bir dosya hazırlıyoruz. CSR oluşturulduktan sonra bu dosya DigiCert, Sectigo, GlobalSign veya GoDaddy gibi bir External Certificate Authority (CA) şirketine gönderilir ve ücreti karşılığında sertifikanın onaylanması sağlanır.

İkinci aşamada, Certificate Authority (CA) tarafından sağlanan SSL/TLS Wildcard sertifikasını Exchange Server’a yükleyip yapılandıracağız. Bu aşamada sertifikanın yalnızca IIS servisleri için değil, aynı zamanda SMTP bağlantıları için de uygun şekilde tanımlanması gerekiyor.

1- SSL/TLS Wildcard Sertifika İsteği (CSR-Certificate Signing Request) Oluşturma

1.1- SSL/TLS sertifikası yapılandırma için öncelikle bir sertifika isteği (CSR-Certificate Signing Request) oluşturmamız gerekmektedir. CSR oluşturmak için servers > certificates altında Select server kısmında CSR oluşturulacak Exchange Server Node'unu seçtikten sonra artı (+) simgesine tıklıyorum.

 

1.2- Karşıma çıkan pencerede Create a request from a certificate authority seçeneğini seçiyor, Next butonuna basarak devam ediyorum.



1.3- *Friendly name for this certificate alanında SSL sertifikam için bana anlamlı gelen bir görünen isim giriyor, Next butonuna basarak işlemime devam ediyorum.



1.4- Bu kısımda Request a wildcard certificate... seçeneğini işaretleyip, aşağıda açılan Text alanına *.firatboyan.com şeklinde Accepted Domain'de tanımlı olan E-mail adresleri için kullanılacak Domain adını yazıyorum.



1.5- Bu kısımda *Store certificate request on this server alanında sertifika isteğinin (CSR) tutulacağı sunucuyu seçmem gerekiyor. Sertifika isteği (CSR), hangi sunucuda oluşturulmuşsa, sertifika tanımlamasının da o sunucu üzerinde yapılması gerekmektedir. CSR oluşturmak için Browse... butonuna tıklıyorum.



1.6- Ortamımda bulunan EXCHSRV01 Host Name'li sunucuyu seçiyor, OK butonuna basıyorum.



1.7- SSL sertifika Request'ini üzerinde tutacağım sunucuyu seçtikten sonra Next botonuna basarak devam ediyorum.



1.8- Bu kısımda şirketiniz ile ilgili şirket adı, il, ilçe, ülke gibi bilgiler girmemiz gerekiyor. Bilgileri girdikten sonra Next butonuna basıp, işlemime devam ediyorum.



1.9- Sonraki adımda SSL sertifika Request'imi Exchange Server'ımın C$ altında oluşmuş olduğum paylaşım klasörünün UNC (Universal Naming Convention) Path bilgisini SSL sertifika Request'ime uzantısı .REQ olacak şekilde isim yazıyor, Finish botonuna basarak SSL/TLS sertifikası Request oluşturma işlemimi sonlandırıyorum.



1.10- Sertifika isteğimi başarılı bir şekilde oluşturdum. Status alanındaki durum bilgisi Pending request olarak görünüyor. Bu işlemle sadece Request oluşturma admını tamamlamış oldum. Request'i oluşturulan sertifikalar, oluşturulduğu Server'da Private Key bilgisi ile tutulur. Private Key, SSL sertifikalarının oluşturma talebinde kullanılan, sertifikanın doğruluğunu kontrol etmek için üretilen özel bir anahtardır.  



1.11- Exchange Management üzerinden de Pending request durumdaki sertifikamı,

komutuyla daha detaylı bir şekilde görüntüleyebilirim.



1.12- SSL sertifika Request'imi Exchange Server'ımın C$ altında oluşmuş olduğum paylaşım klasörünün UNC (Universal Naming Convention) Path üzerinde kaydetmiştim. .REQ uzantılı bu Text dosyasında Hash'lenmiş bir şekilde SSL sertifika Request'imin bilgileri yer alıyor. Bu .REQ uzantılı dosyayı GlobalSign, VeriSign, Digicert, Comodo vb. gibi Sertifika Otoritesine (Certificate Authority-CA) yollayıp, SSL sertifikanızı satın almanız gerekiyor.



1.13- Satın aldığımız SSL sertifikamız elimize ulaştıktan sonra yapılamsı gereken, Reuqest'in Complete edilmesi, yani sertifkanın tanımlanmasıdır.

2- Wildcard SSL Sertifika Tanımlama

2.1- SSL sertifika Request'imi (CSR) Complete etme yani sertifkanın tanımlanması işlemi için servers > certificates altında Pending request durumda bekleyen sertifka isteğine tıklayıp, sağ bölümde bulunan Complete Link'ine tıklıyorum.



2.2- Açılan pencere satın aldığım sertifikamı paylaşımlı bir klasör içine tutup, bu klasörün UNC (Universal Naming Convention) Path bilgisini *File to import from altındaki alana yazıyor, OK butonuna basıyorum.



2.3- Pending request durumda bekleyen sertifkamın Valid durumda olduğunu görebiliyorum. Sıra, sertifikam için ilgili servislerin ataması işlemine geldi. ilgili servislerin ataması işlemini yapmadan, sertifika kullanımı sağlanayacaktır. Bunun için üst bölümde bulunan kalem simgesine tıklıyorum.



2.4- Açılan pencerede services altında SMTP ve IIS servislerini seçip, Save butonuna basıyorum.



2.5- Save butonuna bastıktan sonra karşıma çıkan Warning penceresinde Overwrite the existing default SMTP certificate? sorusunu Yes butonuna basarak onayladıktan sonra kapatıyorum.

2.6- İlgili servislerin tanımladığımız sertifikaya atandığını, sertifikamızın durumunun da Valid yani geçerli olduğunu görebiliyorum.



2.7- Sertifikamızın geçerlilik durumunu ve detaylı bilgilerini

komutuyla görüntüleyebilirim.



2.8- Sıra, tanımlanan SSL/TLS sertifikasının Client Access Service (CAS), başka bir ifade ile Front End Transpot Service, tanımlamasını yapmaya geldi. Client'lar, Transport Service (Exchange Back End) hizmetlerine doğrudan bağlanmazlar. Https protokolü üzerinden gelen Client bağlantı istekleri ilk önce Client Access Service (CAS) tarafından karşılanır.

Client Access Service (CAS), tüm Client bağlantı isteklerini kabul etmekten sorumludur ve gelen bu bağlantıları Exchange Mailbox Server'daki Transport Service (Exchange Back End) hizmetlerine yönlendirir. Bu nedenle gelen Client bağlantı istekleri ilk önce Client Access Service (CAS) tarafından karşılanğı için, SSL/TLS sertifikasının Transport Service (Exchange Back End) Binding'lerinde tanımlanması gerekmektedir.

Bunun için öncelikle IIS Manager'ı açıyor, Server Certificates altında sertifikamın oluştuğunu görüyorum.





2.9- Default Web Site (Front End Transport-CAS) üzerine tıklayıp, sağ bölümde Bindings... Link'ine tıklıyorum.



2.10- Https için oluşturulmuş olan Site Bindigs yapısı alaşağıdaki gibidir.

??



2.11- Her iki Site Binding'e tek tek tıklayıp açtıktan sonra SSL certificate menüsünden oluşturduğum SSL/TLS sertifikasını seçip, OK butonuna basıyorum.





2.12- Bu işlemlerden sonra CMD ya da PowerShell konsolunu Run as administrator olarak çalıştrırıp, konsolunu IISRESET komutu ile IIS servislerini Restart ediyorum.



2.13- Browser üzerinden daha önce tanımladığım Virtual Directory URL bilgisi ile ECP'ye (Exchange Control Panel) erişim sağlatığımda, sertifikamın başarılı bir şekilde tanımlandığını görebiliyorum.



Exchange Server 2019 üzerinde SSL iletişimini güvenli hale getirmek için Wildcard sertifika kullanımı, hem kurulum aşamasında hem de sonrasında dikkatle planlanması gereken bir yapı taşır. Subject Alternative Name (SAN) sertifikalara kıyasla daha sade bir yapı sunması, özellikle birden fazla Autodiscover, OWA, ECP gibi servislerin tek bir domain üzerinden çalıştığı ortamlarda yönetimi ciddi anlamda kolaylaştırır. Fakat bu sade yapı, beraberinde bazı ince ayarların atlanmaması gerektiğini de hatırlatır. IIS üzerindeki manuel sertifika mapping işlemleri, Receive Connector üzerinde doğru sertifikanın atanması ve Internal/External URL değerlerinin net şekilde belirlenmesi, tüm hizmetlerin düzgün çalışabilmesi için olmazsa olmazdır.

Konu sadece sertifikanın yüklenmesiyle bitmiyor. Outlook bağlantılarında güvenli oturum açmanın sağlanması, RPC over HTTP ya da MAPI over HTTP üzerinden erişimlerde uyarı alınmaması, hatta hibrit senaryolarda Azure ile sorunsuz bir iletişimin sağlanması gibi birçok başlık bu yapılandırmaya doğrudan bağlı. Özellikle Autodiscover URL'lerinin doğru şekilde tanımlanmaması, istemci tarafında sürekli sertifika uyarılarına sebep olabiliyor. Bu da kullanıcı deneyimini zedeliyor ve çoğu zaman gereksiz destek taleplerine yol açıyor.

Wildcard sertifika yapılandırmasının doğru şekilde tamamlanması, sadece güvenlik değil aynı zamanda istikrar ve sürdürülebilirlik açısından da ciddi fark yaratır. Anlatılan tüm adımlar titizlikle uygulandığında, ortaya çıkan yapı hem sade hem de uzun vadede daha az müdahale gerektiren bir mimariye dönüşür. Gereksiz karmaşadan uzak, temiz bir Exchange mimarisi oluşturmak isteyenler için bu yapılandırma, atlanmaması gereken detaylarla dolu bir fırsat gibi duruyor.

Faydalı olması dileğiyle...