SSL Sertifika Formatları PEM, DER, PFX ve CRT

Sertifika sağlayıcınızdan ZIP dosyasını indirdiniz, açtınız ve içinden birbirinden farklı uzantılara sahip bir sürü dosya çıktı: .crt, .pem, .cer, .key, .p7b, belki bir de .pfx. Sunucunuz bunlardan hangisini istiyor? IIS "bir PFX dosyası seçin" diyor ama sizde PEM var; ya da Nginx yalnızca metin tabanlı bir dosya kabul ediyor ama elinizde ikili bir DER var. Bu kafa karışıklığı SSL kurulumunda en sık takılınan noktalardan biridir ve çoğu zaman aslında tek bir sertifikanın farklı ambalajlar içinde sunulmasından ibarettir.

Bu rehberde sertifika dünyasındaki formatları tek tek ele alacağız. Önce en temel ayrımı, yani metin tabanlı PEM ile ikili DER kodlamasını netleştirecek, ardından anahtar ve sertifikayı tek bir dosyada birleştiren PFX/P12 paketini açıklayacağız. .crt, .cer, .key gibi uzantıların neyi ifade ettiğini, hangi sunucunun (Linux, Windows/IIS, Java) hangi formatı beklediğini göreceğiz. En sonda ise openssl ile PFX'ten PEM'e, PEM'den DER'e ve tersine tüm dönüşümleri komut komut vereceğiz. SSL'in temel çalışma mantığına henüz yabancıysanız önce SSL sertifikası nedir yazımızı okumanız, buradaki kavramları çok daha net oturtacaktır.

Format mı, Kodlama mı, Uzantı mı? Kavramları Ayıralım#

Sertifika formatları konusundaki karmaşanın büyük kısmı üç ayrı şeyin birbirine karıştırılmasından doğar: kodlama, kapsam ve uzantı. Bunları baştan ayırırsak geri kalan her şey yerine oturur.

Birincisi kodlama (encoding): Bir sertifikanın içindeki verinin diske nasıl yazıldığıdır. İki ihtimal vardır. Ya insan gözüyle bakınca -----BEGIN CERTIFICATE----- ile başlayan, Base64'e çevrilmiş metin (PEM) olarak saklanır, ya da doğrudan sıkıştırılmış ikili baytlar (DER) hâlinde tutulur. İçerideki bilgi aynıdır; yalnızca ambalajın malzemesi değişir.

İkincisi kapsam: Dosyanın içinde ne olduğu. Bir dosya yalnızca tek bir sertifika taşıyabileceği gibi; sertifika + özel anahtar + tüm ara sertifikaları bir arada da taşıyabilir. İşte PFX/P12 ve P7B gibi "kapsayıcı" (container) formatlar bu ikinci gruba girer. Üçüncüsü ise uzantı: .crt, .cer, .pem, .key gibi dosya adının sonundaki etiket. Uzantı çoğu zaman içeriği ima eder ama garanti etmez; bir .crt dosyası hem PEM hem DER olabilir. Bu yüzden "uzantıya değil, içeriğe bak" ilkesi bu işin altın kuralıdır.

PEM: Metin Tabanlı, Her Yerde Çalışan Standart#

PEM (Privacy-Enhanced Mail), Linux ve açık kaynak dünyasının fiili standardıdır. Base64 ile kodlanmış, ASCII metin hâlinde saklanan bir formattır; bir metin editörüyle açtığınızda okunabilir başlık ve sonluk satırları görürsünüz. Bu okunabilirlik onu kopyalayıp yapıştırmaya, e-postayla göndermeye ve panellere elle girmeye son derece uygun kılar. cPanel'in "Sertifikayı Yükle" ekranına yapıştırdığınız o metin bloğu tam olarak PEM'dir.

Bir PEM dosyası tek bir nesne içerebileceği gibi, arka arkaya birden fazla blok da barındırabilir. Örneğin fullchain.pem içinde önce sunucu sertifikası, sonra ara sertifikalar sıralanır; her biri kendi BEGIN/END çiftiyle ayrılır:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAII... (sunucu sertifikası)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEZTCCA02gAwIBAgIQ... (ara sertifika)
-----END CERTIFICATE-----

Başlık satırındaki etiket, bloğun ne taşıdığını söyler. BEGIN CERTIFICATE bir sertifika, BEGIN PRIVATE KEY (veya BEGIN RSA PRIVATE KEY) bir özel anahtar, BEGIN CERTIFICATE REQUEST ise bir CSR demektir. Bir PEM dosyasının içinde ne olduğunu anlamanın en hızlı yolu ilk satırına bakmaktır:

# Dosyanın ilk satırından türünü anla
head -n 1 dosya.pem

# İçindeki nesneleri say (kaç sertifika var?)
grep -c "BEGIN CERTIFICATE" fullchain.pem

# PEM sertifikasını insan-okur hâline çevirip incele
openssl x509 -in sertifika.pem -noout -subject -issuer -dates

Nginx, Apache, HAProxy, Postfix, Dovecot ve neredeyse tüm Linux tabanlı yazılımlar PEM ile çalışır. Bu nedenle elinize hangi format gelirse gelsin, bir Linux sunucusunda kuracaksanız büyük olasılıkla önce PEM'e dönüştüreceksiniz. Paylaşımlı hosting paketlerimizde SSL kurulumu zaten tek tıkla yapıldığı için bu dönüşümlerle hiç uğraşmazsınız; ama kendi sunucunuzu yönetiyorsanız PEM sizin ana çalışma formatınız olacaktır.

DER: İkili Kodlama ve Nerede Karşınıza Çıkar#

DER (Distinguished Encoding Rules), PEM'in ikili karşılığıdır. Aynı sertifika verisini Base64 metin yerine ham baytlar hâlinde saklar. Bir metin editörüyle açarsanız anlamsız, okunamayan karakterler görürsünüz; BEGIN/END satırları yoktur. Aslında PEM, bir DER bloğunun Base64'e çevrilip başına-sonuna etiket eklenmiş hâlidir. Yani ikisi arasındaki dönüşüm kayıpsızdır ve içerdikleri bilgi bit düzeyinde aynıdır.

DER genellikle Windows ve Java ekosisteminde karşınıza çıkar. Windows sertifika içe/dışa aktarma sihirbazı "DER encoded binary X.509" seçeneğini sunar; Java keytool bazı işlemlerde DER bekler. Uzantı olarak sıklıkla .der veya .cer kullanılır (ama .cer PEM de olabilir — yine uzantıya güvenmeyin). Bir dosyanın PEM mi DER mi olduğundan emin değilseniz openssl ile test edin:

# PEM olarak okumayı dene; hata verirse muhtemelen DER'dir
openssl x509 -in dosya.cer -noout -subject 2>/dev/null \
  && echo "PEM" \
  || echo "DER olabilir"

# DER olduğunu doğrulamak için -inform der ile oku
openssl x509 -in dosya.der -inform der -noout -subject -issuer

Pratikte DER'i genellikle "geçiş formatı" olarak görürsünüz: bir Windows sisteminden dışa aktarılır, siz de Linux'a taşımak için PEM'e çevirirsiniz. DER'in tek başına bir özel anahtar taşıma yeteneği yoktur; anahtar ve sertifikayı birlikte taşımanız gerektiğinde devreye bir sonraki formatımız, PFX girer.

PFX / P12: Anahtar ve Sertifikayı Tek Dosyada Birleştirmek#

PFX (Personal Information Exchange), teknik adıyla PKCS#12 ve sık kullanılan .p12 uzantısı, tek bir şifreli dosyanın içine özel anahtarı, sunucu sertifikasını ve tüm ara sertifikaları birlikte koyar. PEM ve DER birer "sertifika" formatıyken, PFX bir "paket" formatıdır. Bir sunucudan diğerine taşınabilir bir SSL kimliğini tek dosyada bulundurmak istediğinizde ideal olan budur; bu yüzden Windows/IIS ve Microsoft Exchange dünyasının varsayılan biçimidir.

PFX'i özel kılan iki şey vardır. Birincisi, özel anahtarı da içermesidir — bu yüzden bir parolayla korunur ve o parolayı kaybederseniz dosya işe yaramaz. İkincisi, ara sertifikaları da paketleyebildiği için taşıma sırasında zincirin kopma riskini azaltır. Aşağıdaki tablo dört formatı yan yana koyar:

P7B (PKCS#7) formatına da kısaca değinelim: PFX'ten farklı olarak özel anahtar içermez, yalnızca sertifikaları ve zinciri taşır. Windows'tan zincir aktarımında sık görülür. Elinize bir .p7b geldiyse ve Linux'a kuracaksanız, onu da PEM'e çevirmeniz gerekir (aşağıda göstereceğiz). Özetle: özel anahtarı bir başka sunucuya taşımanız gerekiyorsa PFX, yalnızca sertifika zincirini taşıyorsanız P7B veya düz PEM işinizi görür.

Hangi Sunucu Hangi Formatı İster?#

Yanlış formatla uğraşmanın en pratik çözümü, kurulum yapacağınız yazılımın ne beklediğini baştan bilmektir. Kabaca ikiye ayrılır: Linux/açık kaynak dünyası PEM ister, Microsoft dünyası PFX ister. Aşağıdaki tablo en sık kullanılan platformları özetler:

Nginx örneğinde, kurulum tam olarak şu şekilde PEM dosyalarını gösterir. Sertifika ve ara sertifikalar fullchain.pem içinde birlikte olmalıdır; sadece sunucu sertifikasını göstermek eksik zincir hatasına yol açar:

server {
    listen 443 ssl;
    server_name alanadiniz.com;

    ssl_certificate     /etc/ssl/alanadiniz/fullchain.pem;   # leaf + ara
    ssl_certificate_key /etc/ssl/alanadiniz/privkey.pem;      # özel anahtar
}

IIS tarafında ise senaryo tersine döner: yönetim konsolu sizden bir .pfx dosyası ve onun parolasını ister, çünkü hem sertifikayı hem de özel anahtarı tek pakette bekler. Bu yüzden Linux'ta ürettiğiniz bir sertifikayı IIS'e taşıyacaksanız PEM parçalarını (cert + key + zincir) bir PFX'e "toplamanız" gerekir. İşte bu iki dünya arasında köprü kuran araç openssl, bir sonraki bölümün konusu. Sunucu yönetimini bize devrettiğiniz sunucu yönetimi hizmetinde bu dönüşümleri ve kurulumu sizin adınıza biz yaparız.

OpenSSL ile Format Dönüştürme Komutları#

Şimdi işin can alıcı kısmına, dönüşümlere geldik. Tüm bu formatlar arasında köprü kuran araç openssl'dir ve Linux, macOS ile Windows'un yeni sürümlerinde hazır bulunur. Aşağıdaki komutları senaryolara göre gruplandırdık.

PFX'ten PEM'e (Windows'tan Linux'a): En sık ihtiyaç duyulan dönüşüm budur. Bir müşteriden .pfx aldınız ve Nginx'e kuracaksınız. Tek bir PFX'i, ayrı ayrı sertifika ve anahtar dosyalarına ayırırsınız:

# Sadece özel anahtarı çıkar (şifresiz — dikkatli saklayın)
openssl pkcs12 -in sertifika.pfx -nocerts -nodes -out privkey.pem

# Sadece sunucu sertifikasını (leaf) çıkar
openssl pkcs12 -in sertifika.pfx -clcerts -nokeys -out cert.pem

# Ara sertifikaları (CA zinciri) çıkar
openssl pkcs12 -in sertifika.pfx -cacerts -nokeys -chain -out chain.pem

Komut sizden PFX'in parolasını isteyecektir. -nodes bayrağı özel anahtarı parolasız kaydeder; bu, sunucunun her yeniden başlatmada parola sormaması için gereklidir ama anahtar dosyasının izinlerini mutlaka chmod 600 yapın. Ardından Nginx için bir fullchain.pem oluşturmak isterseniz leaf ve ara sertifikaları birleştirin:

# leaf + ara = fullchain (Nginx bunu ister)
cat cert.pem chain.pem > fullchain.pem
chmod 600 privkey.pem

PEM'den PFX'e (Linux'tan Windows/IIS'e): Ters yön. Elinizde ayrı cert, key ve zincir dosyaları var; bunları IIS'in isteyeceği tek bir PFX'e paketlersiniz. -certfile ile ara sertifikaları da dâhil ederek zincirin kopmamasını sağlarsınız:

openssl pkcs12 -export \
  -inkey privkey.pem \
  -in cert.pem \
  -certfile chain.pem \
  -out sertifika.pfx

Komut sizden bir "export parolası" belirlemenizi ister; IIS içe aktarma sırasında bu parolayı soracaktır, bir yere not edin. PEM ile DER arası dönüşümler ise tek satırdır ve genellikle Java veya bazı ağ cihazları için gerekir:

# PEM → DER
openssl x509 -in cert.pem -outform der -out cert.der

# DER → PEM
openssl x509 -in cert.der -inform der -out cert.pem

# P7B → PEM (Windows zincirini Linux'a taşıma)
openssl pkcs7 -in zincir.p7b -print_certs -out fullchain.pem

Son bir ipucu: bir dönüşümden sonra çıkan sertifika ile özel anahtarın gerçekten birbirine ait olduğunu doğrulamak isterseniz, ikisinin modulus (veya modern anahtarlarda public key) özetlerini karşılaştırın. Eşit çıkmıyorsa yanlış anahtarı çıkarmışsınız demektir:

# İkisi de aynı özeti vermeli — vermiyorsa cert ile key eşleşmiyor
openssl x509 -noout -modulus -in cert.pem | openssl md5
openssl rsa  -noout -modulus -in privkey.pem | openssl md5

Format Karmaşasında En Sık Yapılan Hatalar#

Dönüşümler basit görünse de birkaç klasik tuzak vardır. En yaygını, uzantıya güvenip içeriği kontrol etmemektir. Bir .crt dosyasını Nginx'e verdiniz ama o dosya aslında DER kodlu; Nginx PEM beklediği için PEM_read_bio hatası döndürür. Çözüm, kurmadan önce head -n1 dosya.crt ile ilk satıra bakıp -----BEGIN görüp görmediğinizi kontrol etmektir. Görmüyorsanız önce PEM'e çevirin.

İkinci sık hata, özel anahtarı zincirle karıştırmaktır. PFX'ten çıkarım yaparken -nocerts ile anahtarı, -nokeys ile sertifikayı ayırdığınıza dikkat edin; ikisini karıştırırsanız sunucu "anahtar sertifikayla eşleşmiyor" (key values mismatch) hatası verir. Üçüncüsü, eksik ara sertifikadır: PFX'ten yalnızca leaf'i çıkarıp chain.pem'i unutursanız, sunucu ayakta kalır ama bazı mobil tarayıcılar ve API istemcileri zinciri doğrulayamaz. Bu tür "bende çalışıyor ama müşteride çalışmıyor" sorunlarının teşhisini SSL hataları ve çözümleri yazımızda araç araç ele alıyoruz.

Dördüncü ve en sinsi hata, satır sonu ve gizli karakterlerdir. Bir PEM dosyasını Windows'ta Notepad ile açıp kaydettiğinizde CRLF satır sonları veya bir BOM (byte order mark) eklenebilir; bu, openssl'in dosyayı okumasını bozar. PEM dosyalarını her zaman nano, vim gibi düz metin editörleriyle düzenleyin ve gerektiğinde dos2unix dosya.pem ile satır sonlarını temizleyin. Bu küçük detaylar, saatlerce sürebilecek kurulum baş ağrılarının çoğunun gerçek sebebidir. Tam kontrol istediğiniz senaryolarda ücretsiz SSL sertifikası çözümümüzle başlayıp yukarıdaki dönüşüm kurallarına dikkat etmeniz çoğu durumda yeterli olur.

Sıkça Sorulan Sorular#

PEM ile CRT arasında fark var mı?#

Aslında bu ikisi farklı kategorilerdeki kavramlardır, bu yüzden doğrudan kıyaslanamazlar. PEM bir kodlama biçimidir (Base64 metin), CRT ise yalnızca bir dosya uzantısıdır. Bir .crt dosyası çoğu zaman PEM kodlu bir sertifikadır, ama teknik olarak DER kodlu da olabilir. Yani "bu bir CRT" cümlesi size dosyanın bir sertifika taşıdığını söyler; içindeki kodlamanın PEM mi DER mi olduğunu söylemez. Emin olmak için dosyanın ilk satırına bakın: -----BEGIN CERTIFICATE----- görüyorsanız PEM'dir.

PFX dosyamın parolasını unuttum, kurtarabilir miyim?#

Ne yazık ki hayır, PFX dosyaları güçlü bir şifreleme ile korunduğu için parolayı kaybederseniz dosyanın içeriğine erişmenin pratik bir yolu yoktur. Bu durumda yapılacak en sağlıklı şey, sertifikayı yeniden ihraç etmek veya sertifika sağlayıcınızdan yeniden düzenlemesini (reissue) istemektir. Özel anahtar hâlâ orijinal sunucunuzda duruyorsa, oradan yeni ve parolasını bildiğiniz bir PFX üretebilirsiniz. Bu deneyim, PFX oluştururken parolayı bir parola yöneticisinde saklamanın ne kadar önemli olduğunu gösterir.

Nginx neden PFX kabul etmiyor?#

Çünkü Nginx, tasarımı gereği ayrı ayrı PEM dosyaları bekler; sertifikayı ssl_certificate direktifiyle, özel anahtarı ise ssl_certificate_key ile ayrı gösterirsiniz. PFX ise anahtar ve sertifikayı tek şifreli pakette birleştiren bir Windows formatıdır ve Nginx bunu doğrudan açamaz. Elinizde PFX varsa önce openssl pkcs12 komutlarıyla içindeki anahtarı ve sertifikaları PEM olarak çıkarır, sonra Nginx'e o PEM dosyalarını gösterirsiniz. Bu, bu rehberdeki "PFX'ten PEM'e" bölümünde adım adım anlatılmıştır.

Fullchain dosyasını PFX içine nasıl koyarım?#

Bunu openssl pkcs12 -export komutuyla yaparsınız ve ara sertifikaları -certfile bayrağıyla dâhil etmeniz kritik önemdedir. Özel anahtarı -inkey, sunucu sertifikasını -in, ara sertifika zincirini ise -certfile ile verdiğinizde, oluşan PFX hem anahtarı hem leaf'i hem de tüm zinciri barındırır. -certfile parametresini atlarsanız IIS'e aktardığınızda zincir eksik kalır ve bazı istemciler siteyi güvensiz sayar. Bu yüzden PFX üretirken ara sertifikaları eklemeyi asla unutmayın.

DER formatını ne zaman kullanmam gerekir?#

Günlük web sunucusu kurulumlarında DER'e neredeyse hiç ihtiyaç duymazsınız; Linux dünyası tümüyle PEM üzerine kuruludur. DER genellikle iki durumda karşınıza çıkar: bir sertifikayı Windows'tan dışa aktardığınızda "DER encoded binary" seçeneğini işaretlediyseniz, veya Java keytool gibi araçlar belirli işlemler için ikili giriş istediğinde. Böyle bir dosya elinize geçtiğinde tek yapmanız gereken openssl x509 -inform der ... -out cert.pem ile onu PEM'e çevirmektir. DER'i bir hedef format olarak değil, çoğunlukla bir geçiş biçimi olarak düşünün.

Sertifika ile özel anahtarın eşleştiğini nasıl kontrol ederim?#

En güvenilir yöntem, sertifikanın ve özel anahtarın modulus (modern anahtarlarda açık anahtar) değerlerinin özetini karşılaştırmaktır. openssl x509 -noout -modulus -in cert.pem | openssl md5 ve openssl rsa -noout -modulus -in privkey.pem | openssl md5 komutlarını çalıştırdığınızda iki çıktı da birbirinin aynısı olmalıdır. Özetler farklıysa elinizdeki anahtar o sertifikaya ait değildir ve sunucu kurulumda "key values mismatch" hatası verecektir. Bu kontrolü kuruluma başlamadan önce yapmak, çoğu SSL kurulum sorununu daha başlamadan önler.

Kapanış#

Sertifika formatları ilk bakışta göz korkutucu bir alfabe çorbası gibi görünse de, aslında iki basit soruya inerler: veri metin mi (PEM) yoksa ikili mi (DER) saklanıyor, ve dosya yalnızca sertifikayı mı yoksa özel anahtar dahil her şeyi mi (PFX/P12) taşıyor? Bu iki ekseni kavradığınızda, .crt, .cer, .key, .p7b gibi uzantıların çoğunun aynı içeriğin farklı ambalajları olduğunu görür ve openssl ile aralarında rahatça köprü kurarsınız. "Uzantıya değil, içeriğe bak" ilkesi ve dönüşümden sonra cert ile key'in eşleştiğini doğrulama alışkanlığı, kurulum baş ağrılarının büyük kısmını ortadan kaldırır.

Bu formatlarla, dönüşümlerle ve zincir kurulumuyla hiç uğraşmadan güvenli bir siteye sahip olmak istiyorsanız, SSL'in tek tıkla kurulduğu hosting paketlerimizle işe başlayabilir, kendi sertifikanızı kuracağınız senaryolarda ücretsiz SSL çözümümüzü kullanabilir ya da sunucunuzun sertifika, güvenlik ve bakım süreçlerini uzman ekibimize devretmek için sunucu yönetimi hizmetimize göz atabilirsiniz. Konuyu pekiştirmek için sertifikaların temel çalışma mantığını anlattığımız SSL sertifikası nedir yazımızla devam etmenizi öneririz.