MMC Aracılığıyla Kod İmzalama Sertifikası için CSR Nasıl Oluşturulur

Microsoft Management Console (MMC) içindeki Certificates snap-in’i, ekstra bir yazılıma gerek kalmadan Windows makinesinde bir PKCS #10 sertifika talebi oluşturabilir. Bu kılavuz, bir kod imzalama sertifikası için sihirbaz ekranlarını adım adım ele alır ve daha eski kılavuzların çoğunun atladığı kısımla başlar: kod imzalama özel anahtarlarına ilişkin kurallar 1 Haziran 2023’te değişti ve bir MMC talebinin kullanılabilir olup olmadığını bu kurallar belirler.

Sihirbazı açmadan önce bu gereksinimi okuyun. Kılavuzun geri kalanı, siparişinizin hangi yolu izleyeceğini zaten bildiğinizi varsayar.

Kod imzalama anahtarları donanım üzerinde oluşturulmalıdır

CA/Browser Forum Code Signing Baseline Requirements kapsamında, 1 Haziran 2023 itibarıyla yürürlüğe giren kurala göre, herkese açık olarak güvenilen her kod imzalama sertifikasının özel anahtarı, en az FIPS 140-2 Level 2, Common Criteria EAL 4+ veya eşdeğer bir standarda göre sertifikalandırılmış bir donanım kripto modülünde oluşturulmalı, saklanmalı ve kullanılmalıdır. Bu kural hem standart sertifikaları (Organization Validation ve Individual Validation) hem de Extended Validation’ı kapsar. EV kod imzalama zaten bu şekilde çalışıyordu; 2023 değişikliği aynı kuralı standart ürünlere de genişletti.

Gereksinimler ayrıca anahtarın kendisini de belirler. RSA anahtarları en az 3072 bit olmalı, ECDSA anahtarları NIST P-256, P-384 veya P-521 eğrilerini kullanmalı ve kod imzalama sertifikaları için SHA-1 kullanımına izin verilmez.

Bir o kadar önemli olan husus, Sertifika Otoritesinin, gereksinimlerin listelediği yöntemlerden birini kullanarak anahtarın gerçekten donanımda olduğunu kanıtlaması gerektiğidir. Pratikte karşılaşacağınız yöntemler şunlardır:

• CA, o cihaz üzerinde kendisinin oluşturduğu bir anahtar çiftini zaten barındıran bir donanım tokeni size gönderir.
• Talebi, üreticinin bir sertifikasıyla karşı imzalarsınız; key attestation (anahtar tasdiki) bunu ifade eder: anahtarın, uyumlu bir cihaz içinde dışa aktarılamaz bir şekilde oluşturulduğunun kanıtıdır.
• CA’nın belirlediği bir kripto kütüphanesi ve donanım modülü kombinasyonunu kullanırsınız.
• Bir BT denetimi, bir bulut anahtar koruma hizmetinden alınan bir rapor veya uyumlu bir imzalama hizmeti aracılığıyla imzaladığınız bir sözleşme sunarsınız.

Bunların hiçbiri, MMC’nin Microsoft Software Key Storage Provider‘a karşı oluşturduğu bir talep tarafından karşılanmaz. Bu sağlayıcı, anahtarı Windows yazılım deposunda oluşturur; bu nedenle sihirbazın geri kalanı nasıl doldurulursa doldurulsun, ortaya çıkan talep herkese açık olarak güvenilen bir kod imzalama sertifikası için reddedilecektir. Sertifika Otoriteleri, bu ürünler için tarayıcı tabanlı anahtar oluşturma ve indirilebilir .pfx teslimatını da aynı zamanda sonlandırdı.

Amacınız herkese açık olarak güvenilen bir sertifika elde etmekse, izlenecek yol siparişi verdiğiniz anda belirlenir. Ya CA, anahtarı bir token üzerinde oluşturup size posta yoluyla gönderir; bu durumda oluşturmanız gereken bir CSR yoktur, ya da anahtarı zaten sahip olduğunuz donanım üzerinde oluşturur ve talep ile birlikte bir tasdik (attestation) sunarsınız. Kod imzalama sertifikası teslimat yöntemleri kılavuzu bu ikisini karşılaştırır ve cihaza özel adımlar burada yer alır:

• YubiKey 5 FIPS: CSR oluşturma ve tasdik
• Luna Network Attached HSM v7.x: CSR ve tasdik kılavuzu

MMC’nin hâlâ uygun olduğu durumlar

Sihirbaz eskimiş değil. Anahtarın nerede oluşacağını belirleyen şey, içinde seçtiğiniz sağlayıcıdır ve bu sihirbazın hâlâ doğru araç olduğu üç durum vardır.

Bir donanım sağlayıcısı tarafından desteklenen bir talep. Sihirbazdaki Cryptographic Service Provider listesi, yalnızca Microsoft’un yazılım tabanlı sağlayıcılarını değil, makineye kurulu her sağlayıcıyı gösterir. Bir token’ın sürücüsü veya akıllı kart minidriver’ı kurulduğunda, sağlayıcısı da bu listede görünür. Fark, anahtar çiftinin nerede oluştuğudur: bir yazılım sağlayıcısı bunu bilgisayarınızda oluştururken, akıllı kart veya token sağlayıcısı gibi donanım tabanlı bir sağlayıcı, cihaza çifti oluşturmasını söyler ve cihaz özel anahtarı elinde tutup erişimini kontrol eder. Bir donanım sağlayıcısı seçtiğinizde MMC, hiçbir zaman yazılımda var olmamış bir anahtar için bir talep oluşturur.

Buna güvenmeden önce iki uyarı var. MMC yalnızca bir PKCS #10 talebi üretir, başka hiçbir şey üretmez; bu nedenle çoğu Sertifika Otoritesinin talep ile birlikte istediği anahtar tasdik dosyasını oluşturmaz. Bu dosya, cihazın kendi aracından gelir. Ayrıca hangi doğrulama yöntemini kabul edeceğine CA karar verir ve birçoğu bu iş için kendi yardımcı programını şart koşar. Herhangi bir şey oluşturmadan önce CA’nızın hangi yolu desteklediğini sorun, çünkü yanlış araçla oluşturduğunuz bir anahtar sonradan taşınamaz.

Bir iç veya kurumsal CA. Baseline Requirements, herkese açık olarak güvenilen sertifikaları düzenler. Kendi Active Directory Certificate Services CA’nız tarafından iç imzalama için verilen bir sertifika bu kapsamın dışındadır; bu nedenle anahtarın nasıl saklanacağına kendi politikanız karar verir ve bir yazılım sağlayıcısı burada meşru bir seçenektir. Elde edeceğiniz sonucu unutmayın: bu şekilde imzalanan kod, yalnızca zaten kendi iç köküne güvenen makinelerde güvenilir kabul edilir; diğer her yerde Windows yayıncıyı yine bilinmeyen olarak değerlendirmeye devam eder.

Test imzalama ve hazırlık. Bir test sertifikası için yazılım tabanlı bir talep sorun teşkil etmez; ayrıca donanımınıza karşı gerçek talebi oluşturduğunuzda tekrar kullanacağınız kesin subject değerlerini çalışırken de uygundur.

Adım 1: Certificates snap-in’ini açın

Windows tuşu + R‘ye basın, mmc yazın ve Enter‘a basın. Görev çubuğundaki arama kutusuna da mmc yazıp oradan açabilirsiniz. Kullanıcı Hesabı Denetimi istemini kabul edin. Boş bir Console1 penceresi açılır.

File‘a, ardından Add/Remove Snap-in‘e tıklayın. Available snap-ins listesinde Certificates‘i seçin ve Add‘e tıklayın.

Windows şimdi snap-in’in hangi sertifika deposunu yöneteceğini sorar: My user account, Service account veya Computer account. Bu seçim, bir kod imzalama sertifikası için bir web sunucusu sertifikasına göre daha önemlidir, çünkü anahtarın nerede yaşayacağını ve imzalama aracınızın hangi depoya bakacağını belirler:

• My user account, anahtarı oturum açmış kullanıcının kişisel deposuna yerleştirir. Bu, bir geliştiricinin etkileşimli olarak imzaladığı durumlarda genellikle tercih edilen seçenektir, çünkü Microsoft’un signtool aracı varsayılan olarak geçerli kullanıcının My deposunu açar.
• Computer account, anahtarı makine deposuna yerleştirir; bu, imzalamanın bir servis hesabı altında çalıştığı bir derleme sunucusuna uygundur. İmzalama araçlarına buraya bakmaları söylenmelidir: signtool, makine deposu için /sm anahtarını alır.

My user account‘u seçerseniz Finish‘e tıklayın. Computer account‘u seçerseniz Next‘e tıklayın, Local computer (the computer this console is running on) seçili kalsın ve Finish‘e tıklayın. Her iki durumda da, Add or Remove Snap-ins penceresini kapatmak için OK‘a tıklayın.

Kaydedilmiş bir konsola ihtiyacınız olmadığında snap-in adımını tamamen atlayan iki kısayol vardır: certmgr.msc geçerli kullanıcının sertifika depolarını doğrudan açar ve certlm.msc yerel bilgisayar depolarını açar. Konsolu elle oluşturduysanız ve tekrar dönmeyi düşünüyorsanız, onu saklamak için File ardından Save‘i kullanın.

Adım 2: Özel bir talep başlatın

Konsol ağacında, Certificates‘i genişletin ve Personal klasörüne (veya depoda zaten sertifika varsa altındaki Certificates klasörüne) sağ tıklayın. All Tasks‘ı, ardından Advanced Operations‘ı ve ardından Create Custom Request‘i seçin. Tercih ederseniz aynı komutlar Action menüsünde de bulunur.

Certificate Enrollment sihirbazı, Before You Begin ekranında açılır. Next‘e tıklayın.

Select Certificate Enrollment Policy ekranında, Custom Request başlığı altına bakın ve Proceed without enrollment policy‘i seçin, ardından Next‘e tıklayın. Bu, Windows’a bir Active Directory şablonuna karşı kaydolmak yerine harici bir CA için bağımsız bir talep oluşturmasını söyler.

Custom request sayfasında üç ayar bulunur:

• Template. (No template) CNG key‘i seçin. Bu, modern donanım sağlayıcılarının kaydolduğu bir Key Storage Provider kullanır. (No template) Legacy key ise daha eski CryptoAPI sağlayıcılarını kullanır ve yalnızca belirli bir cihaz veya uygulama bunu gerektirdiğinde ihtiyaç duyulur.
• Suppress default extensions. Yalnızca elle ayarladığınız uzantıları göndermek istemiyorsanız işaretsiz bırakın.
• Request format. PKCS #10‘u seçin. Her CA bunu kabul eder. CMC, özellikle bunu isteyen sistemlere yönelik taleplere yöneliktir.

Next‘e tıklayın. Certificate Information sayfasında, durumu Available olan Custom request etiketli tek bir satır göreceksiniz. Bu satırı genişletmek için sağındaki Details okuna, ardından görünen Properties düğmesine tıklayın. Dört sekmeli Certificate Properties iletişim kutusu açılır: General, Subject, Extensions ve Private Key.

Adım 3: Subject bilgilerini girin

General sekmesinde bir Friendly name ve isterseniz bir Description yazın. Her ikisi de sertifikayı daha sonra depoda bulmanıza yardımcı olan yerel etiketlerdir. Hiçbiri talebin bir parçası değildir ve hiçbiri doğrulanmaz.

Subject sekmesine geçin. Yazılım yayıncısı olarak görünecek kimlik burada oluşturulur. Subject name altında, Type açılır menüsünden bir giriş seçin, Value kutusuna karşılık gelen metni yazın ve Add >‘a tıklayın. Her giriş, Windows’un kısa biçimde (CN=, O=, OU=, L=, S=, C=) gösterdiği sağdaki listeye taşınır. Aşağıdakilerin her biri için bu işlemi tekrarlayın:

• Common name (CN): kuruluşunuzun kayıtlı adı veya bireysel bir sertifika için kişinin tam yasal adı. Bu, Windows yayıncıyı adlandırırken kullanıcıların gördüğü kimliktir.
• Organization (O): sertifikanın ait olduğu kayıtlı kuruluş adı. Ad, ampersand gibi bir sembol içeriyorsa, bu tür karakterler alanda kabul edilmediği için açıkça yazın veya kaldırın. “AB & C Corporation” “AB and C Corporation” veya “ABC Corporation” olur.
• Organizational unit (OU): kaydı yürüten departman, örneğin IT. İsteğe bağlıdır.
• Locality (L): kuruluşun kayıtlı olduğu şehir.
• State (S): eyalet veya il, tam adıyla yazılmalıdır. FL değil Florida kullanın.
• Country (C): kuruluşun kayıtlı olduğu yerin iki harfli ISO ülke kodu, örneğin US.

Bilgileri yasal kayıtlarınızla tam olarak eşleşecek şekilde girin, çünkü CA herhangi bir şey vermeden önce bunları kamuya açık ve resmi kaynaklarla doğrular. Bir uyumsuzluk, kod imzalama siparişinin durmasının en yaygın nedenidir.

Alternative name kutusunu boş bırakın. Subject Alternative Names sunucuları ana bilgisayar adına göre tanımlar; bir kod imzalama sertifikası ise bir makineyi değil bir yayıncıyı tanımladığından hiçbir DNS girişi taşımaz.

Adım 4: Sağlayıcıyı, anahtar boyutunu ve hash’i seçin

Private Key sekmesini açın. Bu sekmede birkaç daraltılabilir grup bulunur: Cryptographic Service Provider, Key options, Select Hash Algorithm, Select Signature Format ve Key permissions. Genişletmek için bir başlığa tıklayın.

Önce Cryptographic Service Provider‘ı genişletin, çünkü Baseline Requirements’ın devreye girdiği ayar budur. Liste, makineye kurulu her sağlayıcıyı, her biri bir onay kutusuyla birlikte gösterir. İşaretli tek seçeneğin gerçekten istediğiniz sağlayıcı olduğundan emin olun:

• Herkese açık olarak güvenilen bir kod imzalama sertifikası için, token’ınıza veya HSM’nize ait sağlayıcıyı seçin. Bu, yalnızca cihazın sürücüsü veya minidriver’ı kurulduktan sonra bu listede görünür, bu yüzden önce cihazı takıp yazılımını kurun.
• RSA, Microsoft Software Key Storage Provider yazılım seçeneğidir. Bunu yalnızca bir iç CA veya test sertifikası için kullanın.
• Liste ayrıca ECDSA_P256, Microsoft Software Key Storage Provider gibi ECDSA girişleri de içerir. Her ürünün ECDSA desteklemediğini unutmadan, birini seçmeden önce CA’nızın kod imzalama için ECDSA’yı desteklediğini doğrulayın.

Key options‘u genişletin. Key size‘ı 3072 veya 4096 olarak ayarlayın. Kod imzalama için RSA 3072 alt sınırdır ve 2048 ile oluşturulmuş bir talep reddedilecektir. Seçtiğiniz sağlayıcı için açılır menü 3072’yi sunmuyorsa 4096 kullanın.

Aynı grupta, Make private key exportable seçeneğini işaretsiz bırakın. Bu, eski MMC talimatlarındaki en önemli düzeltmedir. Dışa aktarılabilir bir anahtar, .pfx dosyası olarak makineden kopyalanabilir; bu ise donanım gereksiniminin tam olarak önlemeye çalıştığı şeydir ve tasdik yolu, anahtarın dışa aktarılamaz bir şekilde oluşturulduğunu açıkça belgeler. Bunu işaretlemenin tek geçerli durumu, sertifika ve anahtarı başka bir makineye taşımak zorunda olduğunuz bir iç imzalama kurulumudur ve bu durumda bile anahtarı zayıflatır. Allow private key to be archived‘ı da işaretsiz bırakın. Strong private key protection isteğe bağlıdır ve Windows’un anahtar her kullanıldığında sormasını sağlar; bu, paylaşılan bir iş istasyonundaki bir imzalama anahtarı için makul bir seçenektir.

Select Hash Algorithm‘ı genişletin ve Hash Algorithm‘ı sha256 olarak ayarlayın. Kod imzalama sertifikaları için SHA-1’e izin verilmez.

Bir iç CA’ya kayıt yapıyorsanız Extensions sekmesine bakmakta fayda vardır. Key usage‘ı genişletin ve Digital signature‘ı ekleyin, ardından Extended Key Usage (application policies)‘i genişletin ve Code Signing‘i ekleyin. Genel bir CA, sertifikayı talebinizdeki uzantılardan değil, sipariş ettiğiniz üründen oluşturur; bu nedenle genel bir sipariş için bu sekme hiçbir şeyi değiştirmez. Bir iç CA buna uyabilir.

Certificate Properties‘i kapatmak için OK‘a, ardından Next‘e tıklayın.

Adım 5: Talebi kaydedin

Sihirbaz Where do you want to save the offline request? diye sorar. Browse‘a tıklayın, kontrolünüz altındaki bir klasör seçin, dosyaya codesigning.req gibi bir ad verin ve onaylayın. Her zaman düz bir dosya adı yazmak yerine bir klasöre gidin: bir yol belirtmezseniz talep, konsolun o an çalıştığı klasöre kaydedilir ki bu nadiren istediğiniz yer olur ve tekrar bulması zordur.

File format altında Base 64 seçili kalsın. Bu, CA’ların bir kayıt kutusuna yapıştırdığı metin biçimidir. Binary ise ham DER yazar ve çoğu sipariş formu bunu reddeder. Finish‘e tıklayın.

Dosyayı Notepad gibi herhangi bir düz metin düzenleyicisinde açın ve ilk ve son satırlar dahil olmak üzere tüm bloğu kopyalayın:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Windows kayıt araçları normalde, işaretçi satırlarında NEW kelimesi geçen, yukarıda gösterilen daha uzun ifadeyi yazarken, OpenSSL BEGIN CERTIFICATE REQUEST ve END CERTIFICATE REQUEST yazar. Dosyanız kısa formu kullanıyorsa yanlış bir şey yok: içerik aynı PKCS #10 talebidir ve Sertifika Otoriteleri her ikisini de kabul eder. Gördüğünüzü tam olarak kopyalayın ve işaretçi satırlarını yeniden yazmayın.

Sihirbazın üretmediği bir şey de, kaydedebileceğiniz veya kopyalayabileceğiniz bir özel anahtar dosyasıdır; genel ve özel anahtar dosyalarını güvende tutmanızı söyleyen eski kılavuzlar farklı bir aracı anlatıyordur. MMC, yeni özel anahtarı sadece o bilgisayarda, adım 1’de seçtiğiniz hesap altında, Windows anahtar deposunun içinde tutar. Bekleyen talep normalde snap-in içinde Certificate Enrollment Requests altında görünür. Bunun üç sonucu vardır:

• Verilme işlemini beklerken bekleyen talebi silmeyin. Silmek anahtarı da yok eder ve verilecek sertifika o zaman kullanılamaz hale gelir.
• Siparişi aynı bilgisayarda, aynı hesap bağlamında tamamlayın. Kullanıcı deposunda oluşturulan bir talep, makine deposunda tamamlanamaz veya bunun tersi de geçerlidir.
• Talebi oluşturma ile sertifikayı kurma arasında makineyi yeniden oluşturmayın veya yeniden imajlamayın.

Adım 6: Göndermeden önce talebi kontrol edin

Bir talep oluşturulduktan sonra düzenlenemez, bu yüzden doğrulama başladıktan sonra bir yazım hatası keşfetmek yerine şimdi kontrol edin. Windows bunu ekstra bir yazılım olmadan geri okuyabilir. Dosyayı içeren klasörde bir Komut İstemi açın ve şunu çalıştırın:

certutil -dump codesigning.req

OpenSSL kuruluysa, bu aynı dosyayı okur ve ayrıca talep imzasını da kontrol eder:

openssl req -noout -text -verify -in codesigning.req

Çıktıda dört şeyi doğrulayın: subject’in ülke, eyalet, şehir, kuruluş ve common name’i tam olarak amaçladığınız şekilde listelediğini; genel anahtarın 3072 bit veya üzeri, ya da onaylı bir ECDSA eğrisi olduğunu; imza algoritmasının SHA-256 olduğunu; ve OpenSSL komutuyla, talebin eşleşen özel anahtarı tarafından imzalandığını doğrulayan bir verify OK satırının göründüğünü. Bloğu bir tarayıcıda okumak için CSR decoder‘a da yapıştırabilirsiniz.

Bir şey yanlışsa, adım 2’den başlayarak yeni bir talep oluşturun. Kurduğunuz donanım sağlayıcıları dahil, makinede hangi sağlayıcıların mevcut olduğunu görmek için şunu çalıştırın:

certutil -csplist

Adım 7: Verilen sertifikayı aynı makineye kurun

Sertifika siparişiniz sırasında Base 64 bloğunu gönderin, CA’nın istediği doğrulamayı tamamlayın ve verilen sertifika geldiğinde indirin. Özel anahtar Windows anahtar deposunda kaldığından, sertifikanın kullanılabilir olması için aynı depoya geri dönmesi gerekir.

Aynı snap-in’de, Personal‘a sağ tıklayın, All Tasks‘ı, ardından Import‘u seçin ve sihirbazı dosyaya yönlendirin. Windows, sertifikayı talepten sakladığı anahtarla eşleştirir ve Certificate Enrollment Requests altındaki bekleyen giriş kaybolur. Daha sonra sertifikayı açın ve General sekmesinin bu sertifikaya karşılık gelen bir özel anahtarınız olduğunu belirttiğini kontrol edin. Bu satır eksikse, eşleştirme gerçekleşmemiştir ve bunu sertifikanın seri numarasıyla yeniden bağlayabilirsiniz:

certutil -repairstore My <serial-number>

Sertifika makineye değil de geçerli kullanıcıya aitse -user anahtarını ekleyin:

certutil -user -repairstore My <serial-number>

Buradan itibaren imzalama aracınız sertifikayı depodan seçer. Adım 1’de seçtiğiniz depoyu hatırlayın: signtool, makine deposu için /sm geçirmediğiniz sürece geçerli kullanıcının My deposunu okur.

Aynı talebi oluşturmanın diğer yolları CertReq, OpenSSL, Java Keystore ve macOS Keychain Access kılavuzlarında ele alınmıştır. Ayrıca daha geniş kapsamlı kod imzalama eğitimlerini veya CSR oluşturmanın diğer yollarını da inceleyebilirsiniz.

Sıkça Sorulan Sorular