5

Sertifika Servisleri, Public Key teknolojilerini esas alan güvenlik sistemleri tarafından kullanılan, dijital sertifika üretmek ve sertifikaları yönetmek gibi hizmetleri sunan, kimlik denetimi ve erişim kontrolü sağlayan güvenlik suitinin önemli bir parçasıdır.

Organizasyonlarda; kişinin, cihazın yada servisin kimliğini bir private key ile denetlemek suretiyle güvenliği arttırır ve sertifika yönetiminde organizasyona akan veri trafiğinin korunması ve değiştirilememesi için etkin ve güvenli bir çözüm sağlar.

Sertifika servisleri tarafından desteklenen uygulamalara bakacak olursak ;

  • S/Mime (Secure / Multipurpose Internet Mail Extensions)
  • Kablosuz bağlantılarda güvenlik
  • VPN
  • IPSec
  • EFS
  • Smart Card ile oturum açma
  • SSL ve TLS
  • Dijital imza

Şeklinde geniş bir yelpazeye sahip olduğunu görebiliriz. Windows Server 2008 tarafındaki CA yeniliklerine bakarsak :

  • Router gibi network cihazlarına sertifika verebilecek olan Network Device Enrollment (mscep.dll dosyasını hatırlarsınız)
  • Sertifika durumunun daha hızlı kontrolünü sağlayan Online Responder Service şeklindedir.

Yazımızda, ilgileneceğimiz konuları sıralamak gerekirse,

CA seçimi ve kurulumu,

Key Archival için konfigürasyonlar

Sertifika şablonları ve yeni şablon oluşturma

Sertifikaların dağıtımı

IIS (7.5) üzerinde SSL sertifikası ile web sayfası yayınlanması

Güvenli E-mail transferi

şeklinde yazabiliriz. Test ortamında Windows Server 2008 R2 Enterpise, Windows 7 Ultimate, Windows Server 2003 R2 Enterprise(POP3/SMTP Server olarak) işletim sistemleri kullanılacaktır.

Yazı içinde geçecek olan bazı kısaltmaları açıklayayım.

IISàInternet Information Servis

CAàCertificate Authority

NW-CAàKuracağımız sertifika orotitesinin ismi.

Certsrvà IIS altında bulunan ve web üzerinde sertifika alabilmemizi sağlayan alt dizin.

Windows Server 2008 R2, DC ve CA olarak hizmet verecektir.

Windows 7, istemci olarak hizmet verecektir.

Windows Server 2003 R2, POP/SMTP Server olarak hizmet verecektir.

Active Directory Domain Servislerinin kurulumu, e-mail servislerinin kurulumu ve adımları bu yazıda yer almamaktadır.

Domain ismi : nwtraders.msft

DC : bs-dc.nwtraders.msft

E-mail Server : bs-smtp.nwtraders.msft şeklindedir.

CA kurulumu

Server Manager’dan rol ekleme sihirbazı yardımı ile CA yapısını kuralım.


Resim-1

Kurulum öncesinde domain servisleri ve DNS yapılandırıldığından roller arasında seçili görünmektedir. Anlaşılacağı üzere CA servisini Domain Controller üzerine kuruyorum.

İlerlediğimizde rol servislerini göreceğiz


Resim-2

İşaretli olan rol servisi bizim için çekirdek servistir. Sertifika dağıtımı, yönetimi için kullanılmaktadır.

Web Enrollment rol servisi; kullanıcıların sertifika talebi ve yenilemeleri için, revocation list’e erişim için ve smart card sertifikalarının dağıtımı için basitleştirilmiş bir web arayüzü sunmaktadır.

Online Responder; kompleks yapılar içinde , “revocation” kontrolünü daha rahat erişilebilir kılmaktadır.

Network Device Enrollment; Network cihazlarına sertifika alımını sağlamaktadır.

Enrollment Web Service; kullanıcıların ya da bilgisayarların, bilgisayarlar domain üyesi olmasa bile ya da domain network’ünde olmasa bile, sertifika almasını sağlamaktadır.

Enrollment Policy Web Service; bir üstteki rol servisi ile kooperatif çalışan bir servistir.

Rolleri seçerek kurulumu devam ettirelim. Web enrollment rol servisini seçtiğimizde IIS bileşeni de kurulacaktır. Network device enrollment rol servisini ve altındaki 2 role servisini seçtiğimizde, CA kurulumu ile aynı anda yapılamayacağını gösterir bir uyarı alırsınız. Bu rol servisini, kurulum tamamladıktan sonra kurabilirsiniz. Bu arada, son rol servisi için Enterprise Admins grubu üyesi bir kullanıcı kullanmanız gerekir. Altta görüleceği üzere ilgili rol servislerini seçtik ve kuruluma devam ediyoruz.


Resim-3

Eğer yetkili bir hesap ile giriş yapmadıysanız, aşağıdaki resimde aktif durumda olan Enterprise CA türü pasif olacaktır.


Resim-4

Enterprise CA türü, active directory yapısına ihtiyaç duyar ve AD servisini kullanır.

Standalone CA türünün , sertifika dağıtımı ve yönetimi için AD servisine ihtiyacı yoktur. Domain üyesi bir sunucuya da kurulabilir. Bu CA türünde, Auto-Enrollment’ın rahatlığından faydalanamayız.

Biz Enterprise CA kuracağız. Dolayısıyla auto-enrollment’dan yararlanabileceğiz.


Resim-5

Sırada tip seçimi gelmektedir. CA yapısının hiyerarşisi gereği, subordinate kurabilmek için Root CA’e ihtiyacımız var. Bunu, Root domain ve child domain gibi düşünebilirsiniz.

Ardından CA için private key konfigürasyonu gelmektedir. Varsayılan hali ile devam edebilirsiniz. Ben test ortamımda biraz değiştireceğim.


Resim-6

Eğer, w2k8 ve Vista ile gelen Suite-B şifreleme algoritmasını kullanmak isterseniz, Service Provider seçiminde,


Resim-7

ECDSA_P256 ile devam etmelisiniz (Eliptic Curve Digital Signature Algorithym) . Ben, varsayılan tedarikçiyi kullanıyorum. Anahtar uzunluğunu 4096 yapıyorum ve Hash algoritmasını SHA 512 olarak seçiyorum.

Bir sonraki menüde, CA ismi belirtilmekte. CA’in ismini NW-CA olarak belirliyorum. Sade bir menu olduğundan resmetme gereği duymadım.

İsim belirleme sonrasında, CA’in geçerlilik süresi gelmekte. Varsayılan değerinde yani 5 yıl şeklinde bırakıyorum.

Geçerlilik süresinden sonra CA veritabanının ve log’larının kaydedileceği yerler görünmekte. Test ortamımda değiştirmiyorum. Siz, şirket politikanız doğrultusunda, veritabanını ve log’ları farklı bir yere alabilirsiniz. (raid yapınıza uygun şekilde olabilir.).

Wizard’ın son aşamasında sihirbaz size, özeti sunmaktadır. Özete dikkat ederseniz, CA sunucusunun isminin, CA rolü kurulumu sonrasında değişmemesi gerektiği uyarısı önemlidir.

CA rolünün kurulumundan sonra, administrative tool altından CA konsolunu açabiliriz.


Resim-8

Sertifika konsolunda CA’in ismi altında, yapının yönetimi sırasında kullanacağımız alt Node’lar mevcuttur.

Revoked Certificates

Herhangi bir sebepten dolayı iptal edilen sertifikaların listesini bulabilirsiniz.

Issued Certificates

Onaylanmış ve dağıtılmış sertifikaların listesini bulabilirsiniz.

Pending Requests

Onaylanmak için bekleyen sertifikaların listesini bulabilirsiniz. Her sertifika otomatik olarak dağıtılamayabilir (Key Recovery Agent sertifikası için onay gerekmektedir. İlerleyen kısımlarda göreceğiz.)

Failed Requests

Başarısız taleplerin listesini bulabilirsiniz. Örneğin, kullanıcı bir sertifika talep ettiyse ve sertifikada istenen her niteliğe sahip değilse, bu talep başarısız olarak değerlendirilir.

Certificate Templates

Dağıtabileceğimiz sertifikaların listesidir. Listede olmayan bir belgeyi dağıtmak isterseniz, o sertifikayı bu kısma taşımanız gerekir ve bunu da yazının ilerleyen kısımlarında açıklayacağız.

NW-CA’nın özelliklerine bakacak olursak;


Resim-9

Çeşitli tab’ları ve alt menüleri görebiliriz. Resimde görülen View Certificate altında, NW-CA’nın otorite olma belgesini ve özelliklerini görebiliriz. Buton’a tıklarsak;


Resim-10

genel özellikler görülmektedir. Bu sertifika, NW-CA’nin bir otorite olduğunu gösterir. Details panelinde, sertifikaya ve otoriteye ait detaylı bilgiler edinilebilir.


Resim-11

Üstteki resimde, detaylar mevcuttur. Seçili olan öğe bize NW-CA hakkında fikir vermektedir. Sertifikanın seri numarası görünmektedir. En alt kısımda (resimde görülmüyor) sertifikanın thumbprint numarası görülmektedir.

NW-CA’nın özellikleri ile devam edelim. Policy Module kısmı, CA’in sertifika talepleri ile nasıl ilgileneceğini belirler.


Resim-12

Policy Module özelliklerinden görüleceği üzere NW-CA otoritesi, sertifika şablonunda bir yapılandırma varsa onu kullanacaktır, aksi taktirde otomatik olarak onaylayacaktır.

NW-CA özelliklerinde bir başka tab ise Recovery Agents tab’ıdır.


Resim-13

Dağıtılan sertifikaların Private Key’lerini arşivlenmek istersek, Recovery Agents panelinden ilgili gereksinimler yerine getirilmelidir. Buradaki gereksinim, NW-CA’ya bir adet Key Recovery belgesi göstermektir ama henüz hiç bir kullanıcıya Key Recovery belgesi verilmediğinden bunu yapamayız. Yazının sonuna geldiğinizde bunun da yapılmış olduğunu ve kullanıldığını göreceksiniz.

Key Recovery belgesini, Administrator için talep edelim ve Recovery Agents panelini yapılandıralım. Bu yapılandırmayı, sertifika dağıtımlarından önce yapmalısınız ki, olası bir disaster anında bütün sertifikaların privete key’lerini kurtarabilin.

Öncelikle, Administrator’a Key Recovery belgesini alalım. Bunun için web’den NW-CA’ya erişebiliriz. Daha önce web-enrollment rol servisini kurduğumuzdan, IIS bileşeni ve gerekli alt dizinler kurulmuştur. IIS yönetim konsolundan doğrulayalım.


Resim-14

IIS manager’dan görüldiğü gibi, Default Web Site altına, web’den bağlantı sırasında kullanacağımız certsrv alt dizini gelmiştir.

NW-CA’ya web’ten bağlanmak için, http://bs-dc/certsrv url’sini kullanabiliriz. Web arayüzü bize username ve password soracaktır. Biz Administrator kullanıcısına ait olacak bir sertifika almak istediğimizden onun bilgileri ile giriş yapıyoruz. Hangi kullanıcıya sertifika alacaksanız onun bilgilerini kullanmalısınız.


Resim-15

Web arayüzü üstteki gibidir. Amacımız Key Recovery sertifikası talep etmektir. Request …. ile devam ediyoruz.


Resim-16

Request seçeneği ile devam ettiğimizde, karşımıza üstteki gibi iki seçenek gelmektedir. Bizim istediğimiz belge User belgesi değildir. Dolayısıyla gelişmiş talep seçenekleri ile devam edeceğim.


Resim-17

Gelişmiş menüde üstteki gibi 2 seçenek görülmektedir. Biz NW-CA’ya talepte bulunacağız ve talebimizi anlık olarak gerçekleştirip sonucunu alacağız. İlk seçenek ile devam ediyorum.


Resim-18

Gelişmiş menüsünde alınabilecek sertifikalar arasında, Key Recovery belgesini göremiyoruz. Bunun sebebi, Key Recovery belgesinin henüz dağıtılabilecek belgeler arasında olmayışıdır. Bunun için NW-CA yönetim konsolundaki Certificate Templates klasörüne bakabiliriz.


Resim-19

Görüldüğü gibi, Key Recovery belgesi henüz kullanılabilir değildir. Certificate Template klasörüne sağ tıklayıp, belgeyi kullanılabilir hale getirelim. Bunun için sağ tıkladığımızda karşımıza gelen newàcertificate template to issue seçeneğini kullanacağız. Kaşımıza açılan pencereden Key Recovery belgesini seçersek, kullanılabilir hale gelecektir.


Resim-20

Son durumda, kullanılabilecek şablonlar arasına Key Recovery belgesi de geldi. Şimdi web arayüzünü tazeleyelim.


Resim-21

Web arayüzünü tazelediğimizde, siteden sertifika talebi için, sitenin SSL üzerinden hizmet vermesi gerektiği uyarısını alıyoruz ki bunu bir önceki denememde de almıştım. Ama artık Certificate Template drop down menüsünde Key Recovery belgesi de mevcuttur.Uyarıyı OK ile kapatıyorum. Sertifikayı MMC konsolundan da alabiliriz ya da site’ye ssl sertifikası alıp yine buradan devam edebiliriz. MMC konsolundan sertifika talebi oldukça zahmetsiz olduğundan, site’ye SSL sertifikası alıp yine buradan devam edeceğim. Yani IIS üzerindeki web sayfasının (Default web site) SSL ile yayınlanmasını sağlayacağım.

Site’ye SSL sertifikası almak için IIS yönetim konsoluna geçiyorum. NW-CA’ya http://bs-dc/certsrv ismi ile bağlanıyorduk. Yeni bir isim belirleyelim. Sertifika Otoritesine web üzerinden bağlanmak için kullanacağımız isim ca.nwtraders.msft olsun. Artık sertifika servislerimize browser’dan bağlanmak için bir FQDN’imiz de olmuş oldu. DNS’te ca isimli bir kayıt açmayı unutmayın.


Resim-22

IIS yönetim konsolundaki Server Certificates alt menüsünü kullanacağız.Bu menüye girdiğimizde, bs-dc sunucusunun sahip olduğu bir kaç sertifikayı görebilirsiniz.


Resim-23

Create Domain Certificate ile devam ediyorum.


Resim-24

Bilgileri doldururken, organizasyonunuza özel olarak yapıladırmanız uygundur. Önemli olan, common name kısmıdır. Web sitesine erişim için hangi ismi kullanacaksanız onu yazmalısınız. Sonraki panelde hangi otoriteden talep edecekseniz onu seçeceksiniz ve Finish ile sihirbazı bitireceksiniz. Formu doldurmak için hayali bilgiler kullandım.

IIS manager’da Server Certificates menüsüne tekrar baktığımızda, yeni aldığımız sertifikayı da görebiliriz.


Resim-25

Şimdi bu sertifikanın site tarafından kullanılmasını sağlayalım. Sitemiz Default Web Site olduğundan, o seviyeye inelim.


Resim-26

Sertifikanın site tarafından kullanılması için, Actions panelindeki Bindings menüsünü kullanacağız. Menüye yeni sertifikamızı eklersek işimiz tamamlanacak.


Resim-27

Menüde, Add butonundan, sertifikayı seçmeliyiz. Sertifika talebinde bulunurken, sertifika ismine (common name değil, friendly name) WEB_SRV yazmıştım onu seçiyorum ve close ile menüleri kapatıyorum. Son durumda Bindings menüsü aşağıdaki gibidir.


Resim-28

SSL ile erişimi şart koşmak isterseniz, IIS yönetim konsolundaki, Default Web Site seviyesinden SSL Settings ayarına ulaşabilirsiniz.


Resim-29

Burada kutucuğu işaretlerseniz, siteye erişimi mutlaka SSL ile yapacaktır. Eğer siteye bağlanan istemcide de sertifika olmasını isterseniz, alt kısımdaki dairelerden require dairesini işaretleyebilirsiniz. Siteye http üzerinden bağlanmak isterseniz, ssl ile bağlanmayı şart koştuğumuzdan


Resim-30

Uyarısını alacaksınız. Https ile bağlanıp sertifika talep menüsüne geçiyorum. Siteye bağlantı için kullanacağım url : Https://ca.nwtraders.msft/certsrv link’idir.


Resim-31

Artık Administrator’a Key Recovery belgesini alabiliriz. Key Recovery belgesini seçip alt kısımdan talep ederseniz, site size aşağıdaki mesajı verecektir.


Resim-32

Talebimiz beklemededir. Bu sertifikayı değilde farklı bir sertifikayı alıyor olsaydık (mesela user yada basic efs sertifikasi) talebimiz onaylanırdı ve sertifikamızı hemen kurabilirdik. Key Recovery belgesinin özellikleri gereği, CA yöneticisinin onaylaması gerekmektedir. NW-CA konsolundaki Pending klasöründen bekleyen belgeyi onaylayalım.


Resim-33

Onaylama sürecinden sonra Key Recovery Agent yapılandırmasının son adımını yapıp tamamlayabiliriz.


Resim-34

Görüldüğü gibi onaylanan sertifikalar arasına Key Recovery belgesi de geldi. NW-CA özelliklerinden, Recovery Agent menüsüne giderek, otoritemize key arşivlemede kullanacağı Key Recovery belgesini gösterebiliriz.


Resim-35

Recovery Agents menüsünde Add butonuna tıkladığımızda yöneticinin sahip olduğu belge görülmektedir ve belge özelliklerinde de belgenin amacının Key Recovery olduğu yazmaktadır. Belgeyi seçip Apply ile devam ederek, key arşivleme işlemini tamamlayalım. Artık, dağıtacağımız belgelerin Private Key’lerin arşivlenmesini isteyebiliriz. Key Recovery belgesini hangi bilgisayara kurarsanız ancak o bilgisayar üzerinde Recovery işlemi yapabilirsiniz, dikkat !!!!!!!!!

Sertifikaların kullanımı

Organizasyonumuza dağıtmak üzere, dosya şifrelemede, güvenli e-mail transferinde ve kimlik denetiminde kullanılacak bir sertifika şablonu hazırlayalım. Şablon hazırlamak için, NW-CA yönetim konsolundaki Certificate Templates klasörünü kullanabiliriz. Klasöre sağ tıklayıp Manage ile devam edersek, genel şablon listesini görebiliriz.


Resim-36

Genel şablon listesi üstteki gibidir. İstediğimiz nitelikte sertifika hazırlamak için, User belgesini kopyalayalım ve istediğimiz özellikleri ekleyelim. User belgesine sağ tıklayıp duplicate ile devam edeceğim.


Resim-37

Şablona isim olarak resimde görülen ismi verdim. Belgenin geçerlilik süresi 1 yıl, yenileme periyodu 6 hafta olarak görülüyor.

Request Handling menüsünden, sertifikanın private key’inin arşivlenmesi için


Resim-38

üstteki kutucuğu işaretliyorum. Buna dikkat etmek gerekir çünkü varsayılan ayarlar ile devam edersem, private key arşivlenmeyecektir. Suite-B kullanacaksak, cryptography menüsüne de uğramanız gerekecektir.


Resim-39

Subject Name menüsünde, belgeyi alacak olan kullanıcıların sahip olması gereken nitelikler görülmektedir. Kullanıcının , email adresi ve upn’i olmalıdır. Henüz email adresi dağıtmadığımızı hatırlatmakta fayda var. Belge bir bilgisayara verilecek olsaydı, DNS ismi olması gerekirdi!!!

Eğer istenirse, Issuance Requirements menüsünden, bu sertifikayı almak isteyenlerin taleplerinin yönetici tarafından onaylanmasını şart koşabiliriz ama biz otomatik olarak dağıtacağımızdan, belgeyi talep etme hakkı olanların almasını sağlayacağız . Belgeyi kimlerin talep edebileceği kısmını da Security menüsünde belirleyeceğiz.

Biz bu belgeye EFS’te kullanılması özelliğini de eklemek istiyoruz. Onun için Superseded Templates menüsüne Basic EFS şablonunu da eklemeyi unutmayalım.

Belgenin amacına bakmak için, Extensions menüsüne geçebiliriz.


Resim-40

Resimden görüldüğü üzere, belgemiz, kullanıcılara dosya şifreleme, güvenli e-mail transferi ve kimlik doğrulama imkanı sağlayacaktır. Son olarak, domain kullanıcılarının sertifikayı talep edip alabilmeleri için security menüsüne geçelim ve ilgili izinleri verelim.


Resim-41

Üstte görüldüğü gibi, domain users’a, belgeyi okuyup otomatik olarak kurabilmesi için gerekli izinleri veriyoruz. GPO yardımı ile de auto-enrollment’ı kullanıcı ve bilgisayar bazında ayarlayacağız . NW-CA tarafında sertifika hazırlığımızı tamamladık. OK ile şablonu oluşturalım.


Resim-42

Son olarak şablonu, kullanılabilir şablonlar arasına eklemeliyiz ki, kullanıcılar NW-CA’dan talep edebilsinler.

Otorite tarafında yapacaklarımız tamamlandı. Şimdi GPO tarafında auto-enrollment’ı yapılandıralım. Bunu yapıyoruz çünkü her kullanıcı, sertifika talebi konusunda bilgi sahibi olmayabilir ama her kullanıcı e-mail gönderir değil mi ? Domain bazında bir GPO ile auto-enrollment`i (sertifikaların otomatik olarak dağıtılmasını) sağlayabiliriz. Yada Default Domain Policy`den faydalanabiliriz. Ben test ortamımda Default Domain Policy`i kullanacağım.


Resim-43

Default domain policy’de ilgili group policy objesini, resimde görüldüğü gibi yapılandırıyorum. Siz, bilgisayarlara da otomatik sertifika dağıtmak isterseniz, aynı objeyi, computer configuration tarafında da yapılandırmalısınız.

Artık, bu group policy objesinden etkilenen kullanıcılar daha önce hazırladığımız sertifikayı alabilecekler. Ama e-mail adresleri olmadan talep ederlerse, talepleri NW-CA’da Failed Request olarak görülecektir. Kullanıcılarımızı oluşturalım ve e-mail adreslerini verelim. E-mail Server olarak windows Server 2003 R2 üzerinde bir POP/SMTP Server kullanıyorum. E-mail Server’daki hesaplar


Resim-44

Resimde görüldüğü gibidir.

Şimdi, Windows 7 istemcimizden bir kullanıcı ile giriş yapalım, sertifikasının gelip gelmediğini ve geldiyse sertifikasını inceleyelim.

W7 istemcim’den selda@nwtraders.msft hesabı ile giriş yapıp ve mmc konsolundan Lokal sertifika deposuna baktığımızda


Resim-45

Sertifikasının geldiğini görebiliriz. Benzer şekilde, istemcimizden domain kullanıcıları ile giriş yaptığımızda onların da sertifikaları otomatik olarak NW-CA’dan talep edilip yüklenecektir. Belgenin genel özelliklerine bakacak olursak,


Resim-46

Amacımıza yönelik olduğunu görebiliriz. Belge; dosya şifreleme, email güvenliği ve kimlik denetiminde kullanılacaktır. Artık, gönderdiğimiz e-mail’lerimizde, güvenliği sağlama ve kimlik denetimi adına, digital signature ve encryption kullanabiliriz. Kendi dijital imzamızla e-mail gönderelim ve ardından gönderdiğimiz e-mail’leri, sadece hedefin açabileceği şekilde şifreleyelim. E-mail client yazılımı olarak Outlook 2007 kullanacağız.

Outlook 2007 yazılımını açtıktan sonra, e-mail gönderirken, digital imzamızla imzalayacağız. Bunun için aşağıdaki resimden görüldüğü gibi


Resim-47

Add …. ile başlayan kutucuğu işaretliyoruz. Ardından dijital imzamızla e-mail’i gönderebiliriz. Benim e-mail alıcılarım mergun@nwtraders.msft ve baris@nwtraders.msft hesaplarına sahip kullanıcılardır. Gönderilmiş öğeler kutusundan, gönderdiğim e-mail’e bakacak olursak,


Resim-48

E-mail’in tarafımdan imzalandığını, ve güvenilen otoriteyi görebiliriz. Şimdi alıcılardan birinin mailbox’ına bakalım.

baris@nwtraders.msft hesabına baktığımızda,


Resim-49

selda@nwtraders.msft e-mail hesabından, dijital imzalı bir e-mail gelmiştir.Şu an logon olduğumuz baris@nwtraders.msft kullanıcısının lokal sertifika deposuna bakarsak, NW-CA’dan daha önce oluşturduğumuz belgeyi aldığını görebiliriz. Artık, nwtraders\selda kullanıcısının belgesinin public key’i de kendisinde mevcuttur. Nwtraders\selda kullanıcısına şifrelenmiş bir e-mail göndermek isterse, O’nun public key’ini kullanarak gönderebilir. Şifrelenmiş e-mail göndermek istersek, az önceki Add digital signiture … kutucuğunun hemen üzerindeki Encrypt Message content kutucuğunu işaretlememiz yeterlidir. (Öncesinde digital imazalı e-mail alış verişi yapmış olmamız gerektiğini unutmayalım)

Eğer baris@nwtraders.msft kullanıcısı, kendi lokal sertifika deposundaki sertifikasını silerse, yada herhangi bir sebepten dolayı sertifika kaybolursa (donanım sorunları, pc’nin formatlanmazı, düzensiz yedekleme stratejileri), e-mail’lerini açamaz. Silip açmaya çalışırsak aşağıdaki hatayı alırız.


Resim-50

Elimizde baris kullanıcısının sertifikasının private key’i yoksa, yapabileceğimiz birşey yoktur. Ama biz kullanıcıya sertifika dağıtmadan önce, Key Recovery yapabilmek için, dağıtılan sertifikaların private key’lerini arşivlemiştik.

Şimdi nwtraders\baris kullanıcısının private key’ini deşifre edelim ve kullanıcıya tekrar gönderelim. Bunun için certutil.exe komut satırı aracını kullanacağız.


Resim-51

Certutil.exe aracı ile sertifika detaylarını ve arşivlenmiş key’i bulalım. Üstte görüldüğü gibi istenileni elde ettik. Şimdi bunu bir dosyaya aktaralım ve kullanıcıya gönderilebilir hale getirelim. Kullanıcı bu işlemi kendisi yapamaz mı? Kullanıcı Key Recovery Agent belgesine sahip olmadığı için yapamaz. Bu işlemi kim yapar? Key Recovery belgesine sahip domain kullanıcıları ya da bizim ortamımızda Administrator kullanıcısı bu haklar ile donatılmıştır. Bulduğumuz Private Key’i dosyaya yazdırmak için,


Resim-52

Üstteki komutu kullanıyorum. İlk komut ile detayları edindik, ikinci komut ile bunları bir dosyaya (baris-cer.pfx, ismini istediğiniz gibi belirleyebilirsiniz) yazdırdık. Dosyanın varsayılan yeri C:\Users\Administrator klasöründedir. Çünkü Administrator ile işlem yaptık. Nwtraders\baris kullanıcısı, az önce kurtardığımız ve ismini baris-cer.pfx şeklinde yazdırdığımız belgesini, tekrar bilgisayarına kurarsa, e-mail’lerini tekrar görebilecektir.

Sertifikaların kullanım alanlarından bazılarına, sertifikalara ve sertifika otoritelerine genel bir bakış niteliğinde olan yazımızı bu uygulama ile bitirmiş oluyoruz. Sonraki yazılarımızda, sertifikalara ve otoritelere dair açıklamalara ve örneklere devam edilecektir.

Bu konuyla ilgili sorularınızı  alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

Technet Library, Microsoft Official Curriculum

Bu İçeriğe Tepkin Ne Oldu?
  • 4
    harika_
    Harika!!
  • 0
    be_enmedim
    Beğenmedim
  • 0
    _ok_iyi
    Çok iyi
  • 0
    sevdim_
    Sevdim!
  • 0
    bilemedim_
    Bilemedim!
  • 0
    olmad_
    Olmadı!
  • 0
    k_zd_m_
    Kızdım!

1981'de Isparta’da doğdum. Üniversiteye kadar yaşantım Isparta'da devam etti. Lisansımı ve Yüksek Lisansımı Yıldız Teknik Üniversitesinde tamamladım. Windows NT'nin zamanının geçip Windows 2000 Server ve Client tarafının yaygınlaşmaya başladığı dönemlerde Microsoft sertifikasyon eğitimleri ile amatörce ilgilendiğim Bilişim Teknolojileri alanında, profesyonelliğe doğru ilerleyişim başladı. Lisans eğitimimin son zamanlarında ve yüksek lisansım ilk yılında freelance olarak çalıştım. 2006'in ilk çeyreğinden itibaren Bilge Adam Bilgi Teknolojileri Akademisi’nde Microsoft Sertifikasyon eğitimleri vermeye bağladım. Ardından Ankara Kızılay şubesinde 2 yıl Sistem ve Ağ Uzmanlığı departmanında Bölüm Başkan Yardımcılığı yaptım. Bilge Adam Kurumsal’da MS Sistem ve Platform kısmında Danışmanlık ve Eğitim hizmetleri ile Bilge Adam macerama devam ettim. Son 1.5 yıl kurumum adına Savunma Teknolojileri Mühendisliği A.Ş. 'ye MS Sistem ve Platform, Vmware Infrastructure (ESXi, vSphere) , Endpoint Security & Content Gateways (Checkpoint & Websense) , Network Infrastructure (Cisco Systems - Routing & Switching) alanlarında danışmanlık hizmeti verdim. Şu an SYMTURK firmasında Enterprise Vault ve Altiris CMS ürünlerinde danışmanlık hizmetine devam ediyorum. Vakit ayırabildiğim ölçüde eşimle WoW oynuyorum.

Yazarın Profili

Bültenimize Katılın

Tıklayın, üyemiz olun ve yeni güncellemelerden haberdar olan ilk kişi siz olun.

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Yorumlar (5)

  1. DNS’te ca isimli bir kayıt açmayı unutmayın DİYE YAZMIŞSINIZ AMA BU kayıt A kaydımı veya hangi kayıt acaba

  2. Merhaba Harun Bey,

    ca isimli kayıt (A) kaydı.
    ca yerine başka bir isimde kullanabilirsiniz.
    ca kaydı sertifika otoritesinin ip adresini gösterecek olan normal bir isimdir.(bilindik name to ip mapping için)

    öerneğin;
    isterseniz sertifika.nwtraders.msft olacak şekilde “sertifika” isminde bir kayıt açabilirsiniz.

  3. Merhaba Baris bey,

    Benim sorunum Certicitation Authentication ben web serverimle baglanti kuramiyorum, web serverim CentOs, Wordpres…yardmici olabilirmisin.

    Tesekurler

  4. Bu makalede yayınlamış olduğunuz server2012 r için enterprise CA türü pasif geliyor, aktif etmek için ne yapmam gerekiyor.Bununla ilgili bişey bulamadım, yardımcı olabilirmisiniz , paylaştığınız makaleler çok verimli, yazdığım konuyla ilgili makale ve paylaşımda bulunabilirmisiniz.Bu tür paylaşımlarınız için ve herşey için teşekkür ederim.Kolaygelsin. Yanlışlıkla iletişim bölümünden yazdım hemen cevap geldi buradan teyit etmem istendi ilginize teşekkür ederim. Bununla ilgilide müsaitliğiniz var ise görüşmek isterim.Saygılarımla.

  5. Bu makalede yayınlamış olduğunuz server2012 r için enterprise CA türü pasif geliyor, aktif etmek için ne yapmam gerekiyor.Bununla ilgili bişey bulamadım, yardımcı olabilirmisiniz , paylaştığınız makaleler çok verimli, yazdığım konuyla ilgili makale ve paylaşımda bulunabilirmisiniz.Bu tür paylaşımlarınız için ve herşey için teşekkür ederim.Kolaygelsin.Saygılarımla.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir