IIS Nedir? Windows Server'da Kurulum, HTTPS ve Güvenlik

IIS (Internet Information Services), Windows Server ile birlikte gelen web sunucusudur: tarayıcıdan gelen isteği karşılar ve doğru siteyi onun önüne koyar. Ayrı bir program indirmezsiniz; Windows’un içinde uykuda bekleyen bir roldür, siz açana kadar çalışmaz.

Bütün yazı boyunca aklınızda tek bir sahne tutun: çok katlı bir iş hanı ve kapısındaki görevli. Binaya bir ziyaretçi girer, elinde bir not vardır: “üçüncü kat, X şirketi.” Görevli notu okur, ziyaretçiyi doğru kata yönlendirir. IIS tam olarak bu görevlidir. Ziyaretçi tarayıcının isteğidir, notun üstündeki adres web sitesinin alan adıdır, katlar da aynı sunucuda barınan farklı sitelerdir. Bu tek sahneyi kurunca IIS’in geri kalanı, sitelerden sertifikalara kadar, aynı binanın odaları olur.

Bu rehber IIS’i sıfırdan kurmayı, ardından çoğu Türkçe kaynağın durduğu yerden devam etmeyi anlatır: iç sertifika otoritenizden sertifika bastırıp HTTPS bağlamayı, aynı IP’de birden çok güvenli site yayınlamayı (SNI) ve sunucuyu sıkılaştırmayı. IIS, BT Sistem Yönetimi hizmetimizin Windows sunucu tarafındaki temel yapı taşlarından biridir.

IIS Nedir, Ne İşe Yarar?

IIS, Windows üzerinde web sitesi ve web uygulaması barındırmanın yerleşik yoludur. Bir tarayıcı http://sunucu/sayfa istediğinde bu isteği alan, doğru dosyayı ya da uygulamayı bulan ve cevabı geri gönderen katman IIS’tir. En sık şu üç işi görür: statik siteleri yayınlamak, ASP.NET uygulamalarını çalıştırmak ve bir uygulamanın önünde HTTPS’i sonlandıran kapı olmak.

Peki neden ayrı bir web sunucusu gerekir, işletim sistemi bunu kendi yapamaz mı? Yapamaz, çünkü işi farklıdır. Windows dosyaları saklar ve süreçleri çalıştırır; ama gelen bir HTTP isteğini dinleyip, hangi siteye ait olduğunu çözüp, doğru uygulamaya teslim edecek bir görevli yerleşik değildir. İş hanınızın binası ayaktadır, odalar doludur, ama kapıda kimse yoksa gelen ziyaretçi lobide kaybolur. IIS o kapıya oturan görevlidir.

Bunu somut bir kırılma noktasıyla görmek daha kolay: elinizde bir iç izin portalı ya da bir .NET uygulaması var ve bunu on kişinin tarayıcıdan açmasını istiyorsunuz. Web sunucusu olmadan uygulamayı çalıştırsanız bile onu HTTP üzerinden sunacak hiçbir şey yoktur; kimse http:// yazıp açamaz. IIS bu boşluğu doldurur. Öte yandan her senaryo IIS istemez: dışarıya tek bir statik sayfa çıkaracaksanız ya da bütün yığınınız Linux tarafındaysa, tam bir IIS rolü fazla gelir. IIS’in yeri, Windows sunucuda .NET ya da AD ile bütünleşik bir servis barındırdığınız andır.

IIS Kurulumu: Web Server Rolünü Ekleme

Bu rehber, üzerine IIS kuracağınız Windows Server’ı zaten ayağa kaldırdığınızı varsayar. İşletim sistemi kurulumu, disk düzeni ve ilk yapılandırma ayrı bir konudur ve Windows Server kurulum rehberimizde ele alınmaktadır. Elinizde çalışan bir sunucu varsa IIS’i açmak tek satırlık bir iştir.

Yönetici yetkili bir PowerShell açın ve rolü yönetim araçlarıyla birlikte kurun:

Install-WindowsFeature -Name Web-Server, Web-Scripting-Tools -IncludeManagementTools

Web-Server rolün adı; Web-Scripting-Tools, ilerideki New-Website ve New-WebBinding komutlarının kullandığı WebAdministration modülünü getirir; -IncludeManagementTools ise IIS’i pencereden yöneten IIS Manager konsolunu ekler. Bu üçü olmadan sunucu web sayfası sunar ama onu ne konsoldan ne PowerShell’den rahat yönetirsiniz.

Pencereli yolu tercih ediyorsanız Server Manager’daki Add Roles and Features sihirbazını izleyin. Sıralı adımlar:

1. Manage menüsünden Add Roles and Features’ı açın.
2. Installation Type ekranında Role-based or feature-based installation’ı seçin.
3. Server Selection’da hedef sunucuyu seçin.
4. Server Roles ekranında Web Server (IIS)‘i işaretleyin; açılan Add Features penceresini onaylayın.
5. Role Services ekranında varsayılanları bırakın, tek ekleme yapın: en altta, Management Tools altındaki IIS Management Scripts and Tools. Bu kutu, ilerideki New-Website ve New-WebBinding komutlarının kullandığı WebAdministration modülünü getirir; işaretlemezseniz o komutlar çalışmaz.
6. Confirmation ekranında Install’a basın.

Komut satırı hızlı ve tekrarlanabilir, pencere ise ilk kez kuranlar için adım adım görünür.

Doğrulama: IIS Çalışıyor mu?

Kurulumun ilk kez çalıştığını, ince ayarlara geçmeden önce doğrulayın. Bu bölümü atlarsanız, kurulumdaki sessiz bir hata haftalar sonra “site açılmıyor” olarak geri döner.

İstemci tarafı: Sunucunun tarayıcısında http://localhost adresini açın. IIS’in mavi varsayılan karşılama sayfasını görüyorsanız görevli işbaşındadır, gelen isteği karşılayıp cevap veriyor. Başka bir makineden test ediyorsanız localhost yerine sunucunun IP’sini ya da adını yazın.

Sunucu tarafı: Rolün gerçekten kurulu olduğunu PowerShell’den de teyit edebilirsiniz:

Get-WindowsFeature Web-Server

Kendi sunucumuzda bu komutun döndürdüğü çıktı şöyle:

Display Name              Name         Install State
------------              ----         -------------
[X] Web Server (IIS)      Web-Server   Installed

Install State sütununda Installed ve adın önünde [X] görüyorsanız rol kuruludur. IIS Manager’ı açtığınızda (arama kutusuna inetmgr yazarak) sol ağaçta sunucunuzu ve altında Sites klasörünü, içinde de Default Web Site’ı görürsünüz. Bu üçlü görünüyorsa temel çalışıyor demektir; buradan sonrası binaya oda eklemektir.

IIS’e Site Açma ve Binding Mantığı

IIS sunucusunu ayağa kaldırdık ve çalıştığını doğruladık. Şimdi sıra, bu sunucu üzerinde çalışacak internet sitelerini açmaya geldi. IIS’e bir site açmak, ona iki şey vermektir: dosyaların duracağı bir klasör ve bir binding. Binding, isteğin doğru siteye ulaşmasını sağlayan üç parçalı bir adrestir: IP adresi, port ve host adı (alan adı). Kapıdaki görevlinin ziyaretçinin notunda aradığı üç bilgi tam olarak budur: hangi girişten girdi (IP), hangi kapı numarası (port), kime geldi (host adı). Bu üçlü bir siteyle eşleşiyorsa istek o siteye gider; eşleşmiyorsa görevli ziyaretçiyi geri çevirir.

Peki neden binding gerekir, sunucunun zaten bir IP’si yok mu? Var, ama tek başına yetmez. Ham IP’yi (192.168.1.40) tarayıcıya yazdığınızda az önceki mavi karşılama sayfası açılır: IP yalnız sunucuyu gösterir, üzerindeki siteyi değil. Aynı sunucuda üç ayrı site barındırıyorsanız 192.168.1.40 üçü için de aynıdır ve tek başına hangisini istediğinizi söyleyemez. Eksik olan ayırt edici bilgi host adıdır. DNS’te üç isim de (portal..., intranet..., wiki...) aynı IP’ye bakar; tarayıcı istekle birlikte yazdığınız ismi de gönderir, binding de o ismi doğru siteyle eşler. Sonuç: tek IP, tek sunucu, onlarca site, her biri kendi adıyla ayrılır. Görevli tek kapıda durur ama her ziyaretçiyi notundaki isme göre doğru kata gönderir.

İsmin kökü de bunu söyler: binding İngilizcede “bağlamak” fiilinden gelir. Bir binding, bir adresi (IP, port ve isim) bir siteye bağlar: görevliye “şu isme gelen şu siteye gider” kuralını verir.

Binaya yeni bir şirket yerleştirmek gibi düşünün: bir yer (klasör) ve bir kapı adı (binding) verirsiniz. Komut satırında bu tek satırdır:

Import-Module WebAdministration
New-Website -Name 'Portal' -PhysicalPath 'C:\inetpub\portal' -HostHeader 'portal.ad.sercebilisim.com' -Port 80

Burada -HostHeader bindingin host adı parçasıdır: bu site yalnızca portal.ad.sercebilisim.com adına gelen isteklere cevap verir, ham IP’ye ya da başka bir ada değil. Aynı sunucuda ikinci, üçüncü siteyi farklı host adlarıyla açabilirsiniz; görevli hepsini ayırır.

Aynı siteyi pencereden açmak çoğu yöneticinin ilk seçtiği yoldur. IIS Manager’da sol ağaçtaki Sites’a sağ tıklayıp Add Website’i seçersiniz; açılan tek pencerede üç şey doldurulur:

• Site name: sitenin IIS içindeki adı, ör. Portal.
• Physical path: içeriğin durduğu klasör, ör. C:\inetpub\portal. Bu klasör önceden var olmalı ve içinde sunulacak bir dosya bulunmalı: IIS varsayılan belge olarak index.html’i tanır, yani boş bir klasör gösterirseniz site ayağa kalkar ama gösterecek bir şeyi olmaz.
• Binding: tür (http ya da https), IP, port ve Host name (portal.ad.sercebilisim.com). Bu, yukarıdaki üç parçalı adresin penceredeki halidir.

Küçük ama önemli bir ayrıntı: IIS, siz karışmazsanız siteyle aynı adda bir application pool oluşturup siteyi ona bağlar. Yani site ile havuzu tek pencerede kurar, bir sonraki bölümün konusuna da giriş yapmış olursunuz.

Burada ilk kurulumda herkesi yakalayan bir ayrıntı var: bir binding’e portal.ad.sercebilisim.com host adını vermeniz, o ismi sunucunuza çözmez. Host adı yalnızca gelen isteği doğru siteyle eşleyen bir kuraldır; ismin sizin sunucunuzun IP’sine işaret etmesini DNS sağlar. Yani binding’i kursanız bile, DNS sunucunuzda o isim için bir A kaydı oluşturmanız gerekir (portal → 192.168.1.40); yoksa tarayıcı ismi bir IP’ye çeviremez ve siteye hiç ulaşamadan DNS_PROBE_FINISHED_NXDOMAIN verir. Makinenin kendi adı (web01) domaine katılırken otomatik kaydolur, ama portal gibi ek adları elle eklersiniz; iç DNS’te A kaydı oluşturmayı Active Directory DNS yapılandırması rehberimizde anlattık.

IIS Application Pool: İzolasyon ve Kimlik Tuzağı

Her IIS sitesi bir application pool (uygulama havuzu) içinde çalışır: siteyi ayakta tutan, işletim sisteminde ayrı bir w3wp.exe sürecidir. Havuzun değeri izolasyondur. Bir sitenin havuzu çökse, kilitlense ya da yeniden başlatılsa aynı sunucudaki diğer siteler bundan hiç etkilenmez. İş hanındaki her ofisin kendi personeli ve kendi sigortası olması gibidir: birinde kısa devre olup sigorta atsa, yan ofis bunu hiç fark etmeden çalışmaya devam eder. Bir sitenin ağır uygulaması diğerlerini yavaşlatıyorsa çözüm çoğu zaman onu kendi ayrı havuzuna almaktır.

İlk kez uğraşanı yanıltan şey ilişkinin yönüdür. Havuzu siteye takmazsınız; siteyi havuza bağlarsınız. Önce bir havuz oluşturur, sonra sitenin ayarlarından (Basic Settings → Application Pool) hangi havuzda koşacağını seçersiniz. Birden çok site aynı havuzu paylaşabilir ya da her biri kendi havuzunu alır.

Asıl tuzak kimlikte saklıdır. Her havuz bir kimlikle çalışır ve varsayılanı IIS AppPool\HavuzAdı biçiminde sanal bir hesaptır. Sitenizin dosyalarının durduğu klasör bu kimliğe okuma izni vermiyorsa yapılandırmada hiçbir hata görünmez, ama site 403 ya da 500 döner. “Her şeyi doğru kurdum, yine de açılmıyor” vakalarının çoğu tam burada ölür.

IIS bu tuzağı önceden bile gösterir. Siteyi Add Website ile açarken Test Settings’e basarsanız, kimlik doğrulanır (yeşil satır) ama yetkilendirme satırı sarı bir uyarıyla klasöre erişimin doğrulanamadığını söyler. Havuz kimliğine okuma iznini verdiğinizde bu uyarı kaybolur.

Kariyerimin başında tam bu noktada takılmıştım, o yüzden buraya yazıyorum. Çalıştığım bir kurumda, bazı işler için dosya sunucusu olarak kullanılan eski bir sunucu kasası vardı. Kurumun mimarisi karmaşıktı ve öğrendiklerimi not etmek için o kasaya IIS kurup küçük, statik bir Angular doküman sitesi açtım: dışarı çıkmayan, VS Code’da düzenlediğim, backend istemeyen hızlı bir şeydi. İşin tuhafı, siteyi birkaç saatte açtım; ama neden açıldığının mantığı günlerce kafama oturmadı. Deneme yanılmayla, biraz da şansla çözmüş, nasıl çözdüğümü anlamlandırmadan bırakmıştım. Bu satırları yazdıran işte o eksik kalan soru: yukarıdaki iki nokta, bağlama yönü ve havuz kimliğinin klasör izni, kafama ancak sonradan oturdu. İlk seferde bunları kimse anlatmıyor.

Havuzu oluşturmak, siteyi ona bağlamak ve izni vermek üç satırdır:

New-WebAppPool -Name 'PortalPool'
Set-ItemProperty 'IIS:\Sites\Portal' -Name applicationPool -Value 'PortalPool'

icacls "C:\inetpub\portal" /grant "IIS AppPool\PortalPool:(OI)(CI)RX"

Üçüncü satır o görünmez bağı kurar: RX okuma ve çalıştırma iznidir, (OI)(CI) ise iznin klasörün altındaki tüm dosya ve klasörlere inmesini sağlar. Site açılmıyorsa önce buraya bakın.

Bu üç işi pencereden yapmak çoğu yöneticinin günlük yoludur, ve haklı bir tercih: komut ezberlemek gerekmez, ekran her adımda ne yapacağınızı söyler. IIS Manager’da aynı üç adım sırayla şöyle yürür:

1. Havuzu oluşturun: sol ağaçtaki Application Pools’a sağ tıklayıp Add Application Pool’u seçin. Site statik HTML ise, açılan pencerede No Managed Code’u seçin: süreç .NET runtime’ını hiç yüklemez, daha hafif ve daha az saldırı yüzeyi olur. (Bir .NET uygulaması barındıracaksanız v4.0.30319; pipeline modu varsayılan Integrated kalır.)
2. Siteyi havuza bağlayın: siteyi seçip sağdaki Actions panelinden Basic Settings’i açın, Application Pool alanından az önce oluşturduğunuz havuzu (PortalPool) seçin.
3. İzni verin: içerik klasörüne sağ tıklayıp Properties → Security → Edit → Add, kimliğe IIS AppPool\PortalPool yazıp Read & execute işaretleyin.

Son adımda ilk seferde herkesi yakalayan bir tuzak var. Add penceresi, domaine üye bir sunucuda kimliği varsayılan olarak domain’de arar; oysa IIS AppPool\... hesabı yereldir. Konumu (Locations) yerel bilgisayara almazsanız kimlik “bulunamadı” der ve izni bir türlü veremezsiniz. Bir kez yaşayınca unutulmuyor.

Bu üç adımın neden gerektiği aslında tek bir fikre bağlanır. Havuzu, iş hanındaki ofisin kendi personeli gibi düşünün: ilk adımda siteye bakacak personeli işe aldık (havuzu oluşturduk), ikinci adımda siteye “senin işlerini bundan sonra bu personel yürütecek” dedik (siteyi havuza bağladık), üçüncü adımda ise bu personele sitenin dosyalarının durduğu klasörün anahtarını verdik (okuma ve çalıştırma izni). Kritik olan sonuncusudur: bir ziyaretçi siteyi açmak istediğinde, o dosyaları okuyup tarayıcıya render edecek olan tam da bu personeldir. İzin yoksa personel klasörü açamaz, yazdığınız kod ziyaretçinin tarayıcısına hiç ulaşmaz. Yıllar önce kafama oturmayan bağ buydu: havuz bir “ayar kutusu” değil, sitenin işini fiilen yapan kimliğin kendisidir.

IIS’te Kimlik Doğrulama ve Yetkilendirme

Sunucuyu kurduk, siteyi yapılandırdık, içeriği sunar hale getirdik. Ama bir siteyi hizmete açmadan önce iki soruya daha cevap vermek gerekir: bu siteye kim erişebilir, ve erişen ne yapabilir? IIS bunu iki ayrı katmanda çözer: kimlik doğrulama (authentication) ve yetkilendirme (authorization).

Kimlik doğrulama, ziyaretçinin kim olduğunu belirler. Varsayılanı Anonymous’tur: siteyi herkes, kimlik sormadan açar. Dışarıya açık bir web sitesi için doğru olan budur. İç bir portal içinse çoğu zaman Windows Authentication açılır: kullanıcı zaten domaine giriş yaptığından siteye ayrıca şifre girmeden, kendi hesabıyla tanınır. Bu seçim IIS Manager’daki Authentication özelliğinden yönetilir.

Yetkilendirme, o kimliğin neye erişebileceğini belirler ve iki düzeyde çalışır: Authorization Rules ile hangi kullanıcının hangi URL’e girebileceği, klasördeki NTFS izinleri ile de dosya düzeyinde erişim. Aslında bunu app pool bölümünde canlı gördünüz: Test Connection’daki sarı uyarı tam bir yetkilendirme sorunuydu. Kimlik doğruydu, ama o kimliğin klasöre erişim yetkisi doğrulanamıyordu. Kısacası kimlik doğrulama “kim” sorusuna, yetkilendirme “ne yapabilir” sorusuna cevap verir; bir siteyi güvenle açmak ikisini de doğru kurmayı gerektirir.

IIS’te HTTPS: İç CA’dan Sertifika Bağlama

Siteye kimin gireceğini ve ne yapabileceğini belirledik. Ama bu erişimin tamamı hâlâ şifresiz akıyor; şimdi onu HTTPS’e taşıyalım. IIS’te HTTPS açmak için siteye 443 portundan bir binding ve o bindinge bağlı bir TLS sertifikası eklersiniz. Çoğu Türkçe rehber burada “dışarıdan bir SSL satın alın” der ve durur. İç ağdaki bir sunucu içinse doğru kaynak farklıdır: kendi sertifika otoritenizden (Certificate Authority) bastırılan bir sertifika. Sertifikanın neden güven ürettiğini, iç CA ile public CA farkını sertifika otoritesi rehberimizde ayrıntılı anlattık; burada IIS tarafına odaklanıyoruz.

Ama her şeyden önce, sertifikayı çalışır ya da çalışmaz yapan tek kural şudur: bir web sitesi sertifikası, host adını Subject Alternative Name (SAN) alanında taşımak zorundadır. Modern tarayıcılar (Chrome, Edge; 2017’den beri) eski Common Name (CN) alanını sertifikanın adı olarak artık kabul etmez, host adını yalnızca SAN’da arar. CN’i doğru ama SAN’ı boş bir sertifika, kendi iç CA’nızdan gelmiş ve tarayıcı ona güveniyor olsa bile reddedilir. Aşağıdaki iki yolun tek gerçek farkı da budur: biri SAN yazabiliyor, öteki yazamıyor.

Sertifikayı GUI ile bastırmak (ve neden modern tarayıcıda patlar?)

En bariz yol IIS Manager’ın kendi sihirbazıdır: Server Certificates → Actions → Create Domain Certificate. Üç ekranda ilerlersiniz. İlk ekran (Distinguished Name Properties) Common Name’i (portal.ad.sercebilisim.com) ister ve yanında Organization, Organizational unit, City/locality, State/province, Country/region alanlarının hepsini zorunlu tutar; oysa CN dışındaki bu alanların işlevsel hiçbir etkisi yoktur. İkinci ekran (Online Certification Authority) Select ile iç CA’nızı (SerceBilisim-Lab-Root-CA) seçtirir. Üçüncüsü Finish.

Sihirbaz sertifikayı iç CA’nızdan bastırıp LocalMachine\My’a kurar ve iş bitmiş görünür. Ama sessiz bir eksiği vardır: bu sihirbaz size SAN’ı girecek bir alan sunmaz, yalnızca yazdığınız Common Name’i sertifikaya koyar. İşin tuhafı, işlevsiz beş alanı zorunlu tutan sihirbaz, işlevsel tek alanı atlar. Sonucu da ancak tarayıcıda görürsünüz: sertifikayı 443’e bağlayıp domaine üye bir makinede açtığınızda tarayıcı sayfayı NET::ERR_CERT_COMMON_NAME_INVALID ile geri çevirir.

Buradaki ince ama kritik ayrım şudur: bu bir güven hatası değil, bir isim hatasıdır. CA’ya güvenilmeseydi tarayıcı ERR_CERT_AUTHORITY_INVALID derdi; COMMON_NAME_INVALID demesi, “sertifikan geçerli bir otoriteden gelmiş ama sunduğun host adıyla eşleşmiyor” demektir. Yani iç CA kurgunuz doğru çalışıyor, eksik olan tek şey SAN. (Aynı sihirbazın iki görünmez ön koşulunu da bilin: Select gri kalıyorsa CA’yı Active Directory’de bulacak bir domain controller o an kapalıdır; ve enrollment’ı yapan kimliğin WebServer şablonunda Enroll izni yoksa istek CERTSRV_E_TEMPLATE_DENIED ile reddedilir, ki varsayılan şablon bu izni yalnız Domain/Enterprise Admins’e verir. İç CA’nın kurulumunu ve şablon iznini AD Sertifika Servisleri kurulum rehberimizde anlattık.)

Doğru yol: certreq ile SAN’lı sertifika

SAN’ı, sertifika istenirken içine koymak gerekir; certreq buna açıkça izin verir. Bir istek dosyasında (INF) SAN’ı tanımlar, isteği CA’ya gönderir, dönen sertifikayı kurarsınız. İşlemi web sunucusunda, enroll iznine sahip bir hesapla ve yükseltilmiş bir kabukta yaparsınız. Kritik satır [Extensions] altındaki dns=... tanımıdır; gerisi anahtarın makine deposunda üretilmesini (MachineKeySet) ve WebServer şablonunun kullanılmasını söyler:

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=portal.ad.sercebilisim.com, O=Serce Bilisim, L=Istanbul, S=Istanbul, C=TR"
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = TRUE
Exportable = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=portal.ad.sercebilisim.com&"

[RequestAttributes]
CertificateTemplate = WebServer

Bu dosyayı portal.inf olarak kaydedip üç komutu çalıştırırsınız:

certreq -new    C:\portal.inf C:\portal.req
certreq -submit -config "ca01.ad.sercebilisim.com\SerceBilisim-Lab-Root-CA" C:\portal.req C:\portal.cer
certreq -accept C:\portal.cer

GUI’nin takıldığı yeri certreq’in nasıl aştığı buradadır: certreq -submit, CA’ya sizin kullanıcı kimliğinizle bağlanır. GUI’nin makine deposu enrollment’ı ve certlm.msc ise makine hesabıyla (WEB01$) enroll etmeye çalışır; varsayılan WebServer şablonu Enroll’ü yalnız Domain/Enterprise Admins’e verdiği için o makine hesabı reddedilir. certreq’i enroll yetkili bir kullanıcıyla çalıştırınca bu duvar kalkar; MachineKeySet de anahtarı yine makine deposuna koyduğu için IIS sertifikayı sorunsuz kullanır.

İkinci komutun çıktısı sertifikanın imzalanıp döndüğünü, üçüncüsününki de asıl kanıtı, SAN’ın artık sertifikada olduğunu gösterir:

certreq -submit ...
RequestId: 6
Certificate retrieved(Issued) Issued

certreq -accept ...
Installed Certificate:
  Subject: CN=portal.ad.sercebilisim.com, O=Serce Bilisim, L=Istanbul, S=Istanbul, C=TR (DNS Name=portal.ad.sercebilisim.com)
  NotAfter: 10.08.2028 23:07
  Thumbprint: 47ff3a82cd0e048c2198dcc3ecc0b6c085122b17

Subject satırının sonundaki (DNS Name=portal.ad.sercebilisim.com) tam olarak GUI’nin atladığı SAN’dır: artık sertifikanın içinde.

Geriye sertifikayı 443 bindingine bağlamak kalır. Depoda aynı adı taşıyan iki sertifika olabileceği için önce ayırt edici bir friendly name verip (yenilemede eskisini yenisinden ayırmanın tek yolu FQDN + yıl kalıbıdır), bindingi o thumbprint’e yönlendirirsiniz:

(Get-Item Cert:\LocalMachine\My\47ff3a82cd0e048c2198dcc3ecc0b6c085122b17).FriendlyName = "portal.ad.sercebilisim.com SAN 2026"

Import-Module WebAdministration
New-WebBinding -Name 'Portal' -Protocol https -Port 443 -HostHeader 'portal.ad.sercebilisim.com' -SslFlags 1
Get-WebBinding -Name 'Portal' -Protocol https | ForEach-Object { $_.AddSslCertificate('47ff3a82cd0e048c2198dcc3ecc0b6c085122b17','My') }

Aynı işi pencereden de yaparsınız: sitenin Bindings penceresinde https, port 443, host adı ve SSL certificate olarak friendly name’iyle seçtiğiniz yeni sertifika.

Bittiğinde ödül gelir: domaine üye bir makinede https://portal.ad.sercebilisim.com’u açtığınızda tarayıcı siteyi hiçbir uyarı vermeden, adres çubuğunda kilit ve “Connection is secure” ile açar. İki koşul birden sağlandığı için: iç CA’nın kök sertifikası domaine üye makinelere zaten dağıtılmıştır (güven), ve sertifika artık host adını SAN’da taşır (isim). Farkı yaratan budur: uyarısız bir kilit, kullanıcıya “burası gerçekten o site” der.

Aynı IP’de Birden Çok HTTPS Site: SNI

Tek siteyi sertifikayla güvence altına aldık. Ama aynı sunucuda ikinci, üçüncü HTTPS siteyi de yayınlamak isterseniz tek IP yetmiyormuş gibi görünür. SNI (Server Name Indication), tek IP adresinde birden çok HTTPS sitesini kendi ayrı sertifikalarıyla yayınlamanızı sağlar. Sorun şudur: TLS el sıkışması, tarayıcı hangi siteyi istediğini söylemeden önce başlar, dolayısıyla sunucu klasik olarak “hangi sertifikayı sunacağım” sorusuna cevap veremez ve her sertifika ayrı bir IP ister. SNI bu kısıtı, host adını el sıkışmanın en başına ekleyerek çözer: ziyaretçi daha kapıdan girerken “X şirketine geldim” der, görevli de doğru şirketin tabelasını (sertifikasını) gösterir.

Pratikte iki HTTPS bindingi aynı IP ve 443 portunda, farklı host adlarıyla yan yana durur. Her bindingde SNI’ı açarsınız:

New-WebBinding -Name 'Portal'   -Protocol https -Port 443 -HostHeader 'portal.ad.sercebilisim.com'   -SslFlags 1
New-WebBinding -Name 'Intranet' -Protocol https -Port 443 -HostHeader 'intranet.ad.sercebilisim.com' -SslFlags 1

-SslFlags 1 tam olarak IIS Manager’daki Require Server Name Indication kutusunu işaretlemekle aynı şeydir. Bunu açtığınızda sunucu, gelen her isteğin host adına bakıp o ada ait sertifikayı sunar. Böylece tek bir sunucu, tek bir IP’yle, her biri kendi geçerli sertifikasını taşıyan onlarca siteyi barındırabilir.

SNI’ı açtığınızda IIS büyük olasılıkla bir uyarı gösterir: “No default SSL site has been created.” Bunun nedeni SNI’ın öteki yüzüdür: SNI’ı desteklemeyen çok eski bir istemci host adını göndermez, dolayısıyla hiçbir bindingin filtresine takılmaz ve sertifikasız kalır. Bu istemcilere de hizmet vermek isterseniz, aynı IP’de host adı boş ve Require SNI kapalı tek bir HTTPS binding (bir “default SSL site”) bırakırsınız: SNI göndermeyen herkes bu varsayılan sertifikayı alır. Pratikte SNI’ı desteklemeyen istemciler (Windows XP çağı) neredeyse tükendiği için, modern makinelerin bağlandığı iç bir portalda bu uyarı güvenle görmezden gelinebilir; ama yayına açık, çok geniş kitleli bir sitede default SSL site bırakmak makul bir emniyet payıdır.

IIS Güvenliği: Sıkılaştırma

IIS’i güvenli hale getirmek, kullanılmayan kapıları kapatmak ve görevlinin binanın iç planını yabancıya okumamasını sağlamaktır. Kurulumdan hemen sonra atılacak birkaç adım, saldırı yüzeyinin büyük kısmını kapatır:

• Default Web Site’ı kaldırın. Kimsenin kullanmadığı bu varsayılan site, bilinen bir yol ve gereksiz bir kapıdır. Kendi siteniz ayaktaysa Remove-Website -Name 'Default Web Site' ile kaldırın.
• Her siteyi kendi application pool’unda ve en az yetkili kimlikle çalıştırın. Varsayılan ApplicationPoolIdentity çoğu iş için yeterlidir; havuzu asla gereksiz yere yüksek yetkili bir hesapla çalıştırmayın. Bir site ele geçirilse bile hasar o havuzun yetkisiyle sınırlı kalır.
• Eski protokolleri kapatın. SSL 3.0, TLS 1.0 ve 1.1 artık zafiyettir. Sunucuyu yalnızca TLS 1.2 ve 1.3 konuşacak şekilde bırakın. Eskiden bunun yolu tüm sunucuyu etkileyen registry (SCHANNEL) düzenlemesiydi; Windows Server 2022 ve sonrasında ise sitenin binding penceresindeki Disable Legacy TLS kutusunu işaretlemek yeter, değişiklik yalnız o siteye uygulanır. Bu kutunun sunucunun tamamını değil yalnız o binding’i kapattığını, geri kalan servislerin hangi sürümü konuştuğunu nasıl ölçeceğinizi ayrı bir yazıda gösterdik.
• HTTP’yi düz bırakmayın, HTTPS’e taşıyın. 80 portunu şifresiz açık tutmak, ilk isteğin cleartext gitmesine ve SSL-stripping saldırısına kapı aralar. İki seçenek vardır: 80’i tümüyle kapatıp yalnız 443 bırakmak (en sıkısı, ama http:// yazan kullanıcı bağlantı hatası alır) ya da 80’i 443’e yönlendirip HSTS (Strict-Transport-Security) başlığı eklemek. HSTS’te tarayıcı ilk HTTPS ziyaretinden sonra http://yi kendi içinde https://ye çevirir, yani 80’e bir daha hiç gitmez; pratik denge budur. IIS 10 (Server 2019 ve sonrası) HSTS’i site ayarlarından doğrudan destekler.
• Yalnız yetkili cihazların girmesini istiyorsanız karşılıklı TLS (mTLS) açın. Standart HTTPS tek yönlüdür: sunucu kendini istemciye kanıtlar ama istemciden sertifika istemez, dolayısıyla herkes bağlanabilir. Hassas bir iç serviste (yönetim paneli, iç API) yalnız geçerli istemci sertifikası sunan cihazları içeri almak isterseniz, IIS’te SSL Settings → Client certificates: Require ile mutual TLS’i açarsınız. Bu, parola katmanının önüne cihaz kimliği ekleyen fazladan bir kilittir.
• Sunucu sürümünü ifşa eden başlıkları gizleyin. IIS varsayılan olarak cevaplarına Server: Microsoft-IIS/10.0 gibi bir başlık koyar. Bu, saldırgana hangi sürümü hedefleyeceğini söyler; kaldırın.
• İstek filtrelemeyi (Request Filtering) kullanın. Barındırmadığınız dosya türlerine, gereksiz HTTP metodlarına ve aşırı uzun URL’lere gelen istekleri kapıda reddedin.

Bu liste bir başlangıçtır, bitiş değil. Kritik bir sunucuyu tam olarak sıkılaştırmak, CIS Benchmark gibi ölçülü bir standarda göre gitmek anlamına gelir; ama yukarıdaki yedi adım, varsayılan bir kurulumu makul bir tabana taşır.

IIS mi Apache mi?

Sunucuyu kurduk, siteyi yayınladık, HTTPS’e taşıdık ve sıkılaştırdık. Şimdi geriye dönüp bir soru sormanın tam zamanı: bu işi baştan IIS ile mi yapmalıydık, yoksa Apache ile mi? IIS ile Apache aynı işi yapar, ikisi de web sunucusudur; seçim çoğunlukla web sunucusuyla değil, işletim sistemiyle başlar. IIS Windows’a gömülüdür, .NET ve Active Directory ile aynı dili konuşur; Apache açık kaynaktır, Linux dünyasının varsayılanıdır ve PHP, Python, Node gibi yığınlarla doğal çalışır. Windows sunucuda bir .NET uygulaması ya da AD’ye bağlı bir iç servis barındırıyorsanız IIS sürtünmeyi azaltır. Yığınınız Linux tarafındaysa, Apache ya da nginx aynı rahatlığı orada verir; kendi lab’ımızda GLPI gibi servisleri Ubuntu Server üzerinde Apache ile çalıştırıyoruz.

İki sunucunun da konuştuğu protokol ise aynıdır ve seçimden bağımsızdır: istek satırı, başlıklar, durum kodları ve TLS el sıkışması her ikisinde de birebir aynı işler. Protokolün kendisini HTTP ve HTTPS nedir rehberinde anlatıyoruz.

Karar bir “hangisi daha iyi” yarışı değildir. Doğru soru şudur: sunucunuz zaten hangi işletim sistemini konuşuyor ve uygulamanız neyle yazıldı? Cevabı verdiğinizde web sunucusu kendiliğinden belli olur.

Sonuç

IIS’i kurmak tek satırdır; onu güvenli ve doğru kurmak, kapıdaki görevliyi işe almaktan sonra binanın kapılarını da düzenlemektir. Bu rehberde rolü açtık, kurulumu doğruladık, site ve binding mantığını kurduk, iç CA’dan sertifikayla HTTPS bağladık, SNI ile tek IP’de çok siteyi yan yana koyduk ve sunucuyu makul bir tabana sıkılaştırdık.

Buradan doğal iki yön var: sertifika tarafını derinleştirmek için sertifika otoritesi rehberine, Windows sunucu ailesinin bütününe bakmak için ise Windows Server rehberimize geçebilirsiniz. Web sunucunuzu kurarken sertifika, DNS ya da mimari tarafında takılırsanız, mevcut yapınızı birlikte çıkarıp yol haritasını netleştirebiliriz.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.