Kod İmzalama Sertifikası için CSR Nasıl Oluşturulur

Bir kod imzalama sertifikası, bir yazılım parçasını kimin yayınladığını kanıtlar ve kodun imzalandığından sonra değiştirilmediğini gösterir. Bir sertifika sipariş etmek için, Sertifika Yetkilisi’nin (CA) sizi tanımlamak ve sertifikayı vermek için kullandığı kodlanmış metin bloğu olan bir CSR (Sertifika İmzalama Talebi) oluşturursunuz. Kod imzalama CSR’leri, bir web sitesi için oluşturduğunuz CSR’lerden farklı kurallara uyar ve bu kurallar 2023’te değişti. Bu kılavuz, geçerli süreci ve halen uygulanabilir yöntemleri açıklamaktadır.

Özel anahtar donanımda bulunmalıdır

1 Haziran 2023‘ten beri, CA/Browser Forum Kod İmzalama Temel Gereksinimleri, herkese açık olarak güvenilen her kod imzalama sertifikası için özel anahtarın FIPS 140-2 Seviye 2, Common Criteria EAL4+ veya eşdeğer bir standardı karşılayan donanımda oluşturulmasını ve saklanmasını gerektirmektedir. Bu, hem standart sertifikalar (Organizasyon Doğrulaması ve Bireysel Doğrulama) hem de Genişletilmiş Doğrulama (EV) sertifikaları için geçerlidir. EV kod imzalama, bu tarihten önce zaten donanım gerektiriyordu; 2023 değişikliği aynı kuralı standart sertifikalara da genişletti.

Pratik sonuç önemlidir: yalnızca yazılımda, bir tarayıcıda veya bir dizüstü bilgisayarda ya da sunucuda normal bir dosyada oluşturulan bir özel anahtar ve CSR, herkese açık olarak güvenilen bir kod imzalama sertifikası için artık kabul edilmemektedir. CA’lar bu ürünler için tarayıcı tabanlı anahtar oluşturmayı ve indirilebilir .pfx teslimatını desteklemeyi durdurdu. Anahtar, uyumlu bir cihazda oluşturulmalı ve orada kalmalıdır. Bu, iki geçerli yol bırakır:

• CA’dan önceden yapılandırılmış bir donanım token’ı. CA, anahtar çiftini ve CSR’yi doğrudan sertifikalı bir USB token üzerinde oluşturur, verilen sertifikayı üzerine kurar ve token’ı size gönderir. Token bağlıyken imzalarsınız. Bu yöntemle CSR’yi kendiniz oluşturmazsınız.
• Anahtar doğrulaması ile kendi HSM’iniz veya bulut HSM’iniz. Zaten uyumlu bir Donanım Güvenlik Modülü (veya AWS CloudHSM, Azure Dedicated HSM ya da Google Cloud HSM gibi bir bulut HSM) işletiyorsanız, anahtarı ve CSR’yi bu cihaz üzerinde oluşturur ve anahtarın uyumlu donanımda oluşturulduğunu ve bu donanımdan dışa aktarılamayacağını CA’ya kanıtlayan bir doğrulama dosyası sunarsınız.

Hangi yolu izleyeceğiniz sipariş verdiğinizde belirlenir. Yan yana bir karşılaştırma için kod imzalama sertifikası teslimat yöntemlerine bakın.

Seçenek 1: token ve gönderim (CSR’yi CA oluşturur)

Bu, çoğu bireyin ve küçük ekibin seçtiği yoldur, çünkü kendi donanımınıza gerek yoktur. Ödeme sırasında token ve gönderim seçeneğini seçtiğinizde, CA kendi tarafında sertifikalı bir token üzerinde anahtar oluşturma ve CSR oluşturmayı halleder, ardından size sertifika zaten yüklenmiş şekilde token’ı postayla gönderir. Bir sipariş formuna yapıştıracağınız bir CSR yoktur.

Bunun yerine yaptığınız şey:

• CA’nın istediği doğrulama adımlarını tamamlayın (organizasyon veya kimlik doğrulaması).
• Fiziksel token’ın gelmesini bekleyin.
• Token sürücülerini yükleyin (yaygın olarak SafeNet Authentication Client) ve token bağlıyken yazılımınızı imzalayın.

Seçenek 2: CSR’yi kendi HSM’inizde veya token’ınızda oluşturun

Zaten uyumlu donanıma sahipseniz, anahtar çiftini ve CSR’yi bu cihaz üzerinde oluşturur ve eşleşen bir doğrulama sunarsınız. Kesin adımlar donanıma bağlıdır, bu nedenle cihazınız için kılavuzu veya sağlayıcınızın kendi belgelerini takip edin:

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

Bulut HSM’ler için (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM), anahtarı HSM içinde oluşturun, CSR’yi ve platformun ürettiği doğrulama dosyasını dışa aktarın, ve her ikisini sipariş sırasında CA’nıza gönderin.

Donanım destekli CSR’ler için geçerli birkaç ayrıntı vardır:

• Temel Gereksinimlerin belirttiği gibi en az 3072 bitlik bir RSA anahtarı veya eşdeğer bir ECDSA anahtarı kullanın.
• Anahtarı dışa aktarılamaz olarak işaretleyin, böylece cihazdan çıkamaz.
• Doğrulamayı anahtarla aynı zamanda oluşturun. Geçerli bir doğrulaması olmayan bir CSR reddedilecektir.

OpenSSL, Java Keytool, MMC, CertReq ve Keychain yöntemleri şimdi nereye uyuyor

OpenSSL, Java keytool aracı, Microsoft Management Console (MMC), Windows certreq komutu veya macOS’ta Keychain Access ile kod imzalama CSR’si oluşturan eski talimatlar görmüş olabilirsiniz. Kendi başlarına bu araçlar yazılımda bir anahtar oluşturur, bu nedenle bu şekilde üretilen bir CSR bugün herkese açık olarak güvenilen bir kod imzalama sertifikası için geçerli değildir.

Bu araçlar, bir yazılım anahtar deposu yerine uyumlu donanımı hedef aldıklarında hâlâ bir yere sahiptir. Örneğin, OpenSSL bir PKCS#11 modülü üzerinden bir HSM’ye karşı bir CSR oluşturabilir ve CertReq veya MMC, bir donanım anahtar depolama sağlayıcısı kullanan bir talep oluşturabilir. Bu referansları yalnızca bu bağlamda kullanın ve talebi her zaman cihazdan gelen doğrulamayla eşleştirin:

• OpenSSL ile kod imzalama CSR’si oluşturun
• Java Keystore ile kod imzalama CSR’si oluşturun
• CertReq ile kod imzalama CSR’si oluşturun
• Microsoft Management Console ile kod imzalama CSR’si oluşturun
• macOS Keychain Access ile kod imzalama CSR’si oluşturun

CSR’nizin içeriğini kontrol edin

Bir CSR göndermeden önce, konu ayrıntılarının doğru olduğunu doğrulayın. OpenSSL’e sahipseniz, talebi yerel olarak çözümleyin ve düz metin olarak geri okuyun:

openssl req -noout -text -in codesigning.csr

Çıkışta organizasyon veya ortak adı ve anahtar boyutunu inceleyin. Standart bir web sitesi CSR denetleyicisi burada doğru araç değildir, çünkü bir kod imzalama CSR’si donanıma bağlıdır ve genel bir HTTPS taraması yerine doğrulama yoluyla onaylanır.

Sıkça Sorulan Sorular