Windows Server 2022’de İki Katmanlı PKI Uygulaması – Bölüm 1

Bugünün dijital dünyasında, sertifikalar neredeyse her şey için zorunlu hale geldi. Web tabanlı uygulamaların yaygınlaşmasıyla birlikte sertifikalara olan ihtiyaç önemli ölçüde arttı. Ancak, web tarayıcıları daha katı hale geliyor ve kendi kendine imzalanan (self-signed) sertifikalara güvenmek giderek zorlaşıyor. Ayrıca, halka açık sertifika otoritelerinden (CA) alınan sertifikalar yerel alan adları için uygun değil. Peki, çözüm nedir? Kendi Genel Anahtar Altyapımızı (PKI) kurmamız gerekiyor. Bu süreci bir dizi makalede size adım adım göstereceğim…

Giriş

IKendi PKI altyapınızı uygulamaya kararlıysanız, bu blogun tek kaynağınız olmaması gerektiğini lütfen unutmayın. PKI altyapısı karmaşık ve kritik bir konudur; hatalar, alan (domain) ortamınıza geri döndürülemez zararlar verebilir. Bu yüzden bu makaleyi yalnızca bir test laboratuvarı rehberi olarak düşünün. Konuyu daha derinlemesine anlamak için ek kaynaklar kullanın çünkü burada yalnızca temel bilgileri ele alacağız. PKI ile ilgili herhangi bir konuda emin değilseniz, altyapınızı oluştururken alanında uzman kişilerden yardım almanızı öneririm.

PKI, sertifikalar oluşturmak ve yönetmek için oluşturulmuş roller ve politikalar çerçevesidir.

PKI’nin bazı yaygın kullanım alanları şunlardır:

• İç ağ kaynakları için kendi kendine imzalanan sertifikaların yerini almak
• İç hizmetler ve uygulamalar için sertifika sağlamak
• Dosya ve sistemleri şifrelemek
• E-posta iletişimlerini güvence altına almak
• RDP güvenliğini artırmak

PKI ve CA ne anlama gelir?

• PKI (Public Key Infrastructure): Sertifikalar sağlamak için kullanılan bir çözüm.
• CA (Certificate Authority): Sertifika hizmetleri sağlayan bir bileşen.

Neden kendi PKI’nize ihtiyacınız var?

Daha önce de bahsettiğimiz gibi, ticari Sertifika Otoriteleri (CA’lar) yerel ağlarda (non-routable internal networks) iç alan adları için sertifika vermez.

Neden şimdi bu konuda yazıyorum? Birçok ortamda kendi kendine imzalanan sertifikalarla yaşanan zorluklara şahit oldum; bu durum, iç hizmetlerde çok sayıda soruna yol açıyor. Özellikle web tabanlı iç uygulamalarda tarayıcıların dayattığı sertifika gereksinimleri nedeniyle işlerin yürümesi giderek zorlaşıyor.

Ne gerekiyor?

Active Directory Certificate Services (AD CS) rolüne ihtiyacımız var. Bu, Windows ortamında bir PKI ve Sertifika Otoritesi (CA) oluşturmamızı sağlayacak. Bu kurulum, Active Directory (AD) ile veya AD olmadan kullanılabilir.

AD CS, SSL, dijital imzalar, VPN erişimi, Mobil Cihaz Yönetimi (MDM), güvenli LDAP (LDAPs), akıllı kartlar ve daha fazlası için kullanılabilir.

Burada AD CS hakkında daha fazla ayrıntıya girmeyeceğim, çünkü bunun kısa bir rehber olması amaçlanmıştır.

Sertifika Otoritesi (CA) Dağıtım Seçenekleri

Belirtildiği gibi, bir sertifika yetkilisi bir etki alanında veya çalışma grubunda kurulabilir ve çevrimiçi veya çevrimdışı olabilir. Çevrimdışı dağıtım genellikle daha iyi bir güvenlik uygulaması olarak kabul edilir.

Üç ana CA dağıtım türü vardır: Tek Katmanlı, İki Katmanlı ve Üç Katmanlı.

Tek Katmanlı CA

Bu kurulumda, tüm sertifika verme işlemlerini gerçekleştiren tek bir kök ve sertifika veren CA vardır. Tek bir hata noktası veya büyük ağlarda bir darboğaz olması gibi önemli güvenlik riskleri oluşturduğundan test ortamları için en uygun olanıdır.

İki Katmanlı CA

Bu yapılandırma çevrimdışı bir Kök CA ve çevrimiçi bir Alt CA içerir. Alt CA sertifika verir ve tehlikeye girmesi durumunda iptal edilebilir ve değiştirilebilir. Bu kurulum gerektiğinde ölçeklendirilebilir. CDP ve AIA kayıtlarını güncellemek ve her şeyin doğru çalıştığından emin olmak için Kök CA periyodik olarak (50 haftada bir önerilir) çevrimiçi hale getirilmelidir. Bu aynı zamanda Microsoft tarafından önerilen bir en iyi uygulamadır.

Üç Katmanlı CA

En karmaşık yapı olup çevrimdışı bir Kök CA, bir Ara CA ve çevrimiçi bir Alt Sertifika Otoritesinden oluşur. Büyük kuruluşlarda en fazla esnekliği sağlar.

Bu kılavuzda, İki Katmanlı CA kurulumuna odaklanacağız. Üç Katmanlı CA oldukça karmaşıktır ve genellikle destek için özel bir ekip gerektirir.

Açıklanan Anahtar Terimler:

• Root CA: En üst düzey CA. Tek Katmanlı bir kurulumda her şeyi idare eder.
• Intermediate and Subordinate CA: Microsoft’un terminolojisinde bunlar aynıdır. Üç Katmanlı bir kurulumda, Ara CA, Kök ve Alt CA arasında yer alır. İki Katmanlı bir kurulumda sertifika verme işlemini Alt CA gerçekleştirir.
• CRL (Certificate Revocation List): Artık geçerli olmayan iptal edilmiş sertifikaların bir listesi.
• AIA (Authority Information Access): Provides URLs for certificate revocation.
• CDP (CRL Distribution Points): İstemcilerin bir sertifikanın geçerli olup olmadığını kontrol etmek için CRL’yi alabilecekleri URL’leri veya konumları sağlar.

Sertifika Türleri:

X.509 sertifika standardını kullanacağız. Windows ortamlarındaki yaygın biçimler şunlardır:

• .cer
• .p7b
• .pfx
• .sst

Ayrıca uzantıları değiştirebilir ve .crt kullanabilir veya .pfx’i .key ve .crt/.pem’e dönüştürebilirsiniz. .pfx sertifikalarını dönüştürme hakkında kısa bir kılavuz için bu bağlantıya göz atabilirsiniz.

Sertifikaları dışa aktarırken, her zaman çok güçlü parolalar kullanın – tercihen 16 karakterden daha güçlü.

Özel İşletme Numarası (PEN)

Sertifika Yetkilinizi (CA) yalnızca şirket içinde kullanmayı planlıyorsanız, mutlaka bir Özel Kurumsal Numaraya (PEN) ihtiyacınız yoktur. Bununla birlikte, bir PEN’e sahip olmak faydalı olabilir ve İnternet Atanmış Numaralar Kurumu (IANA) web sitesi aracılığıyla bir PEN edinme süreci hızlı ve ücretsizdir. Bunu birkaç kez yaptım ve oldukça basit bir süreç. PEN numarasını almak genellikle birkaç saat ile birkaç gün arasında sürüyor.

PEN’inizi buradan talep edebilirsiniz: IANA PEN Application.

Dağıtım yaparken, dosyalarınızda bir Nesne Tanımlayıcı (OID) numarası tanımlamanız gerekir. Bu, genel bir Microsoft OID’si (1.2.3.4.1455.67.89.5) veya benzersiz PEN numaranız olabilir. Bir PEN almak kolay olduğundan, üretime geçmeden önce bir tane almanızı öneririm. Test için Microsoft tarafından sağlanan OID’yi kullanacağız.

Bu çok kısa bir genel bakış – bunu bir üretim ortamında uygulamadan önce kapsamlı bir araştırma yaptığınızdan emin olun.

Ön Koşullar / Test Yapılandırması

PKI’yı üretimde dağıtmadan önce, etki alanınızda zaten bir Kök CA olmadığından emin olun. Bunu nasıl kontrol edeceğinizi buradan öğrenebilirsiniz.

Başlangıç için dört makine kullanacağız. Bu adımlara aşina olduğunuzu varsayarak sanal makinelerin, ağların ve etki alanlarının kurulumunun ayrıntılarını ele almayacağım. İşte test ortamının detayları:

Domain: pwoks.local

• Tüm makineler:
• 2 CPU
• 8GB RAM (RAM sınırlıysa minimum 4GB)
• 60GB disk alanı
• İşletim Sistemi:
• Sunucular: Windows Server 2022 Standard (Datacenter Versiyonu CA için ekstra özellikler sunmaz)
• İstemci: Windows 11 Pro/Enterprise 23H2
• IP Aralığı: 10.0.1.0/24 (Azure Internal Network)

Domain Controller:

• Host Adı: DC.pwoks.local
• IP: 10.0.1.4
• İS: Windows Server 2022 Standart
• Roller:
• DC’ye entegre DNS Sunucusu
• Etki Alanı Kullanıcıları OU: Winuser1
• Bilgisayarlar OU: Clients
• Sunucular OU: Servers

Root CA:

• Host: RootCA
• IP: 10.0.1.5
• Workgroup: Pwoks-CA
• Local Administrator: certadmin (Yönetici hesabı devre dışı)
• Klasör Yolu: C:\RootCA
• CA İsmi: Pwoks-RootCA-CA
• İS: Windows Server 2022 Standart

Bu makine etki alanının (pwoks.local) bir parçası olmayacak, BitLocker korumalı olacak ve yapılandırmadan sonra kapatılacaktır. Ağın geri kalanıyla Ethernet bağlantısı olmayacaktır. Hiçbir ek hizmet veya uygulama yüklenmemelidir. Çevrimiçi olması gerektiğinde, geçici olarak internet erişimi verebilirsiniz.

Subordinate CA:

• Host: SubCA.pwoks.local
• IP: 10.0.1.6
• CA İsmi: Pwoks-SubCA-CA
• Domain OU: Servers
• Kullanıcı: Etki alanı yöneticisi hesabı
• İS: Windows Server 2022 Standart

BitLocker disk şifrelemesinin aktif edilmesini şiddetle tavsiye ediyorum. Bu CA sunucusu sertifikalar yayınlayacak, CRL’leri yönetecek ve bir etki alanı üyesi olacaktır.

İstemci:

• Host: client.pwoks.local
• IP: 10.0.1.7
• İS: Windows 11 Pro / Enterprise
• Domain: pwoks.local’e katıldı

Sertifika Ön Koşulları:

• Root CA Sertifikası: 4096 bitlik SHA256, 10 yıl boyunca geçerli
• Subordinate Sertifikası: 5 yıl boyunca geçerli
• Verilen Sertifikalar: 1 yıl boyunca geçerli

Bu geçerlilik sürelerini ayarlayabilirsiniz, ancak özellikle tarayıcılar için güvenlik standartlarının daha katı hale geldiğini unutmayın. Uzun geçerlilik sürelerine sahip sertifikalara güvenilmeyebilir.

Dahili Bağlantılar:

Dağıtım sonunda bağlantılar SubCA.pwoks.local adresini gösterecektir:

• Web Instance: http://subca.pwoks.local
• Root CA CRL: http://pki.pwoks.local/CertData/
• Enterprise CA CRL: http://pki.pwoks.local/CertEnroll/
• Active Directory Web Kayıt Hizmeti: https://pki.pwoks.local/CertSrv/
• Sertifika Uygulama Beyanı (CPS): http://pki.pwoks.local/cps.html

HTTP bağlantılarının kullanıldığına dikkat edin. Yeni bir cihaz bağlandığında, dahili kök ve alt sertifikalarınıza güvenmeyebilir, bu nedenle güvenilmeyen olarak görünecektir. Bunun istisnası, Kurumsal CA’ya sertifika istekleri göndermek için kullanılan AD’dir.

Konfigürasyon

GUI kullanmaktan çok daha hızlı olduğu için tüm adımları PowerShell aracılığıyla gerçekleştireceğiz. Kök CA’yı yapılandırarak PKI altyapımızı hazırlamakla başlayalım.

Root CA

İlk olarak, C:\Windows dizininde bir CAPolicy.inf dosyası oluşturmamız gerekir. Bu dosya, oluşturulması sırasında CA’ya yapılandırma ayrıntıları ekleyecektir.

İşte dosyamın nasıl göründüğüne dair bir örnek (çoğunlukla Microsoft’un belgelerine dayanmaktadır):

1. Kök CA için Tanımlı Yenileme Bilgileri: Kök CA için yenileme bilgilerini ayarlıyoruz.
2. RSASSA-PSS Desteğinin İptal Edilmesi: RSASSA-PSS algoritmasını (AlternateSignatureAlgorithm) kullanarak sertifika verme desteğini kapattık.
3. CRL ömrünün ayarlanması: CRL ömrünü Kök CA’nın ömrüne eşit hale getirdik.
4. Delta CRL Devre Dışı Bırakıldı: Bu yapılandırmada gerekmeyeceği için Delta CRL seçeneğini devre dışı bıraktık.

Kök CA AD CS Rolünün Yüklenmesi

Artık Kök CA’yı hazırladığımıza ve CAPolicy.inf dosyasını yerleştirdiğimize göre, Active Directory Sertifika Hizmetleri (AD CS) Rolünü yüklemeye devam edebiliriz. Kurulum süreçlerine zaten aşina olduğunuz için, Sunucu Yöneticisi’ndeki her ekran görüntüsünü tek tek göstermeyeceğim. Yapacağımız şey şu:

1. Sunucu Yöneticisini Açın: Sunucu Yöneticisi’ne gidin ve Rol ve Özellik Ekle’yi seçin.
2. certadmin Kullanıcısıyla Giriş Yapın: certadmin kullanıcısı olarak oturum açtığınızdan (yerel Yönetici hesabı devre dışı bırakılmıştır) ve Kök CA makinesinde ağ bağlantısı olmadığından emin olun.
3. AD CS Rolünü Seçin: Roller listesinden Active Directory Sertifika Hizmetleri’ni seçin.

Bu, kuruluma başlamamızı sağlayacaktır.

Aşağıdaki yapılandırma ayrıntılarıyla bir Kök Sertifika Yetkilisi (CA) kurma işlemini gerçekleştireceğiz:

Sertifika Yetkilisi Kurulumu

• Yükleme Türü Standalone CA
• Yetki Türü: Root CA
• Kriptografik Sağlayıcı: RSA#Microsoft Software Key Storage Provider
• Anahtar Uzunluğu: 4096 bits
• İmza Hash Algoritması: SHA256
• CA Genel İsmi: Pwoks-RootCA-CA

Sunucu Yöneticisi’nde şimdi “Hedef sunucuda Active Directory Sertifika Hizmetlerini Yapılandırma” seçeneğini görmelisiniz. Sadece bir hatırlatma – ağ çevrimdışı ve certadmin hesabıyla çalışıyoruz.

AD CS’yi yapılandırma

Sertifikasyon Otoritesi(CA)

Standalone CA

Root CA

Yeni Özel Anahtar

RSA#Microsoft Software Key Storage Provider , 4096 Key length ve SHA256

Varsayılanı bırak

10 Yıl

Yapılandırma Başarılı

Kök CA Doğrulaması

Kök CA oluşturulduktan sonra, her şeyin doğru çalıştığını doğrulamamız gerekir. Arama çubuğuna certsrv.msc yazarak Sertifika Yetkilisi konsolunu açın. “Sertifika Yetkilisi” altında, yeni oluşturulan Test Etki Alanı Kök CA’sını görmelisiniz. Üzerine sağ tıklayın, Özellikler‘i seçin ve Genel sekmesinde Sertifikayı Görüntüle‘ye tıklayın. Sertifika görünürse, başarıyla oluşturduk demektir ve 10 yıl boyunca geçerli olacaktır.

CRL’yi Kök CA’da Yapılandırma

Ardından, Sertifika İptal Listemizin (CRL) 52 hafta boyunca geçerli olmasını sağlamak için kayıt defterinde birkaç ayarlama yapacağız. Ayrıca Alt CA’nın geçerliliğini 1 yıldan 5 yıla uzatacağız.

Ayrıca, etki alanı üyesi olmasa bile Kök CA’nın etki alanının yapısını bilmesi için DCConfig’i yapılandırmamız gerekir. İlgili tüm ayarları kayıt defterinde şurada bulabilirsiniz:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

DSConfigDN değerlerini kontrol etmek için Yapılandırma görünümünde ADSIedit’i kullanabilirsiniz. Alternatif olarak, DC sunucunuzda Active Directory Users and Computers , Gelişmiş Özellikler‘i aktif edin, etki alanınıza (pwoks.local) sağ tıklayın, Özellikler‘i seçin ve Attribute Editor altında distinguishedName alanını bulun. Bu, DSConfigDN satırı için gereken değerleri gösterecektir.

Şimdi, PowerShell’de yönetici olarak ve certutil.exe kullanarak aşağıdaki komutları çalıştıracağız:

Dikkat: Kök CA’nızı her 52 haftada bir açmayı unutmayın. Sürekliliği sağlamak için 50 haftada bir hatırlatıcı ayarlayın.

Kök CA’da Denetimi Etkinleştirme

Zorunlu olmamakla birlikte, daha iyi kontrol için denetimi etkinleştirmek iyi bir fikirdir.Local Security Policy > Local Policies > Audit Policy > Audit Object Access hem “success” hem de “failure” seçeneklerini seçin.

Sertifika Yetkilisi üzerindeki tüm olayların denetimini etkinleştirmek için aşağıdakileri çalıştırın:

Her şeyin seçili olduğundan emin olmak için certsrv.msc‘yi açtıktan sonra sunucunuza sağ tıklayarak Denetleme(Auditing) sekmesini kontrol ederek doğrulayabilirsiniz.

Kök CA’da CDP ve AIA’yı Yapılandırma

Ardından, Kök CA için CRL Dağıtım Noktası’nı (CDP) ve Yetkili Bilgi Erişimi’ni (AIA) yapılandıracağız. PowerShell bazen karakterleri kaybettiğinden, bu komutlar için Komut İstemi’ni kullanacağız. Öncelikle, tek satırda olduklarından emin olmak için kodları önce Not Defteri’ne kopyalayın.

Aşağıdaki komutları Komut İstemi’nde yönetici olarak çalıştırın:

CDP için:

AIA için:

Bu komutları çalıştırdıktan sonra, CA hizmetini yeniden başlatın:

Ardından CRL’yi yayınlayın:

CDP ve AIA ayarlarını doğrulamak için :

CDP ve AIA ayarlarını doğrulamak için :

Son olarak, certsrv.msc‘yi açın, sunucunuza sağ tıklayın, Properties > Extensions‘a gidin. CDP altında, “CRL’lere dahil et. İstemciler Delta CRL konumlarını bulmak için bunu kullanır” seçeneğinin seçili olduğundan emin olun.

AIA için “Verilen sertifikaların AIA uzantısına dahil et” seçeneğinin işaretli olduğundan emin olun.

Kök CA Sertifikasını ve CRL’yi Dışa Aktarma

Kök CA sertifikasını ve CRL’yi dışa aktarmaya hazırız. Bu bir test ortamı olmasına ve bir dosya paylaşımı kullanmama rağmen, bir üretim ortamında Kök CA’nın çevrimdışı olması ve ağa bağlı olmaması gerektiğini unutmayın.

Şuradaki içeriği :

C:\Windows\System32\CertSrv\CertEnroll

C:\RootCA klasörüne kopyalayın. Bu klasör RootCA-CA.crl ve RootCA_RootCA-CA.crt dosyalarını içermelidir. BitLocker kullanıyorsanız, bu aynı zamanda kurtarma anahtarını yedeklemek için de iyi bir zamandır.

RootCA klasörünü Alt CA’nıza aktarın. Ağ kullanıyorsanız, şimdi bağlantıyı kesin.

Son olarak, önlem olarak Kök CA’nızı yeniden başlatın. Bu noktada, Kök CA’nın ağ bağlantısı yoktur ve tüm PKI uygulaması tamamlanana kadar bu şekilde kalmalıdır.

Bölüm 1 burada tamamlanmaktadır. Bir sonraki bölümde, bir etki alanı üyesi olacak ve her zaman çevrimiçi olacak olan Alt CA’yı ayarlayacağız.

Tüm PKI uygulaması bitene kadar Kök CA’yı kapatmayın!