PKCS12, PEM veya DER: Bir VPN İstemcisinin Gerçekte Neye İhtiyacı Var
Paketleme, istemcinizin kimliği içe aktarıp aktaramayacağını belirler, güvenilir olup olmadığını değil. PKCS12, PEM ve DER’i karşılaştırın, sonra doğrulayın.
Sertifika tartışmalarında iki iddia dolaşır. Birincisi, .p12’nin güçlü seçenek, .pem’in ise gevşek olan olduğu; ikincisi, bir metin dosyasını okuyabildiğiniz için göndermenin güvenli olması gerektiği. İkisi de bir dakikalık incelemeye dayanmaz.
PKCS12, PEM ve DER, sertifika nesnelerinin nasıl paketlendiğini ve kodlandığını tanımlar. Karşı tarafın kim olduğunu, verenin güvenilir olup olmadığını veya dosyanın parola gerektirip gerektirmediğini belirlemezler.
İstemcinin neyi kabul ettiği bir uyumluluk sorusudur. Dosyanın ne içerdiği bir kimlik sorusudur. Bu ikisini ayrı tutun, çoğu içe aktarma hatası gizem olmaktan çıkar.
Üç kapsayıcı, tek nesne modeli
Gerçekte elinizde olanla başlayın. Sertifika, bir açık anahtar hakkında imzalanmış bir beyandır. Özel anahtar, o anahtarı kontrol ettiğinizi kanıtlayan ayrı bir malzemedir. Zincir, sertifikanızı istemcinin güvendiği bir köke bağlayan verenler kümesidir. Üçü de paketlemeden bağımsız olarak vardır.
Genellikle .p12 veya .pfx olan PKCS12 dosyası, RFC 7292’de tanımlanan ve bir özel anahtarı, bir veya daha fazla sertifikayı ve zinciri parola korumalı tek bir blob içinde, kimliği adlandıran bir takma adla taşıyabilen bir kapsayıcıdır. PEM dosyası, RFC 7468’de tanımlanan metin çerçevelemesidir: BEGIN ve END satırları arasında bir base64 gövdesi ve tek bir dosya art arda birkaç blok barındırabilir. DER, aynı ASN.1 yapılarının ikili kodlamasıdır ve PEM gövdesi tam anlamıyla base64 ile sarılmış DER’dir.
O son cümle akılda tutulmaya değer. PEM’i DER’e dönüştürmek sarmalayıcıyı yeniden yazar, içeriği değil; geri dönüştürmek özgün baytları verir.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
Kodlama şifreleme değildir
Base64 bir taşıma alfabesidir. Hiçbir şeyi gizlemez ve herkes bir kabukta PEM bloğunun kodunu çözebilir. DER dosyası ikilidir ve aynı ölçüde kamusaldır. Bu özelliklerin ikisi de koruma değildir ve ikisi de bir parolanın varlığını ima etmez.
Gerçek koruma anahtar malzemesinde yaşar. Bir PKCS12 paketi içeriğini paroladan türetilen bir anahtarla şifreleyebilir. Bir PEM özel anahtarı eski bir başlık bloğuyla şifrelenebilir veya PKCS#8 EncryptedPrivateKeyInfo içinde tutulabilir. Bir sertifika tek başına hiçbir sır barındırmaz, bu yüzden yalnızca sertifika üreten bir dışa aktarma, hangi biçimde sararsanız sarın istemciyi kimlik doğrulayamaz halde bırakır.
Uzantı bir ipucudur, sözleşme değil. .cer ve .crt ile biten dosyalar her iki kodlamada da görünür ve cihazlar DER sertifikalarını o kadar sık .pem adlarıyla dışa aktarır ki son ekinden tahmin yürütmek bir öğleden sonrayı harcar. Bunun yerine ilk baytlara bakın: PEM dosyası BEGIN satırıyla açılır, DER ise 0x30 ile başlar çünkü dış yapı bir SEQUENCE’tır.
İçe aktarma gerçekte neden başarısız olur
İstemci hata iletileri birkaç farklı sorunu geçersiz sertifika hakkında tek bir cümleye sıkıştırır, bu yüzden onları nedene göre ayırın. En yaygını kodlama uyuşmazlığıdır: PEM ayrıştıran bir istemci DER dosyasında ayrıştırma hatası döndürür ve çözüm yeni bir sertifika değil dönüştürmedir. İkincisi eksik anahtardır; sertifika iyidir ama kimlik kanıtlanamaz. Üçüncüsü zincirdir; ara sertifikası olmayan bir paket içe aktarma penceresinde doğru görünür ve el sıkışma sırasında başarısız olur.
Şifreleme parametreleri dördüncüsüne yol açar ve tam olarak yanlış parola gibi görünür. Eski cihazlar PKCS12 dosyalarını RC2-40 ve 3DES ile dışa aktarıyordu; OpenSSL 3 bunları eski sağlayıcı yüklenmedikçe reddeder. Cihazdan AES-256-CBC ve PBKDF2 ile yeniden dışa aktarmak kalıcı çözümdür. Tek bir dosya için bir istemci makinesinde eski şifreleyicileri kalıcı olarak açık bırakmak kötü bir takastır.
Beşincisi belirsizliktir. İki anahtar ve iki sertifika barındıran bir kapsayıcı ya da üç CERTIFICATE bloğu olan bir PEM dosyası istemciyi seçmeye zorlar ve seçimi çoğu zaman yalnızca ilk öğedir. Bir tünel yanlış kimlikle açıldığında, nedeni genellikle budur.
Dönüştürmeden önce inceleyin
Yapıyı sırları yazdırmadan okuyun. openssl pkcs12 -in bundle.p12 -info -noout anahtar ve sertifika çıktısını bastırırken şifreleme algoritmalarını ve takma adları bildirir ve openssl-pkcs12 kılavuzu bayrakları belgeler. -noout’u kaldırıp -nodes eklemek, saklamayı düşündüğünüz dosyaları üretmek içindir, hızlı bir bakış için değil, çünkü özel anahtarı açık olarak yazar.
Bir sertifika için openssl x509 -in cert.pem -noout -subject -issuer -dates, içe aktarma penceresinin yanıtlamadığını yanıtlar ve -ext subjectAltName eklemek sertifikanın gerçekte hangi adlar için geçerli olduğunu gösterir. Dosya DER ise -inform DER ekleyin; bu tek bayrak yüklenemiyor hatalarının çoğunu çözer.
Bir anahtarı bir sertifikayla eşleştirmek mekaniktir ve herhangi bir içe aktarmadan önce yapmaya değer:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
Aynı özetler bu çiftin birbirine ait olduğu anlamına gelir. Farklı özetler yanlış anahtara sahip olduğunuz anlamına gelir ve hiçbir biçim dönüştürmesi bunu değiştirmez.
Biçimin asla değiştirmediği şey
Güven kararları kapsayıcının üstünde gerçekleşir. İstemci zinciri kendi deposundaki bir köke kadar yürür, geçerlilik aralığını denetler, istemci kimlik doğrulaması için genişletilmiş anahtar kullanımını denetler ve sunucu tarafında aradığı adın sertifikada göründüğünü denetler. Bu adımların hiçbiri bir dosya uzantısını okumaz.
Bu yüzden bir dosyayı hata kaybolana kadar yeniden adlandırmak zaman kaybetmenin bu kadar güvenilir bir yoludur. İçe aktarma başarılı olur, kimlik hâlâ yanlıştır ve hata, iletinin daha az yardımcı olduğu el sıkışma sırasında yeniden ortaya çıkar. İki yıl önce dışa aktarılmış bir paketin temiz içe aktarılıp yine de reddedilmesinin nedeni de budur: son kullanma tarihi dosya adında değil, sertifikanın içinde yolculuk etti.
Yeniden işi önleyen bir sıra
İstemcinin belgelerine hangi kodlamaları kabul ettiğini ve bir istemci kimliği için hangi kapsayıcıyı beklediğini sorun, sonra size verilene bakın. İstemci içe aktarılabilir tek bir kimlik istiyorsa ve elinizde ayrı PEM dosyaları varsa, paketi kontrol ettiğiniz bir parolayla bir kez oluşturun ve kaynakları saklayın. PEM istiyorsa anahtarı ve zinciri çıkarın, ardından ara dosyaları ekibinizin zaten kullandığı kimlik bilgisi işleme süreciyle sonradan silin.
İçe aktarmadan sonra pencereyi değil kimliği doğrulayın: konu, veren, son kullanma tarihi ve istemcinin sunacağı ad. Bir listedeki dostça ad bir etikettir, doğrulanmış bir kimlik değildir. Tünel bundan sonra başarısız olursa, paketleme yerine kimlik doğrulama veya yönlendirme ayıklıyorsunuz demektir ve bu çok daha kısa bir konuşmadır.