Ubuntu 22.04 Üzerinde Bir Sertifika Otoritesi (CA) Kurulumu ve Yapılandırması
Giriş
Günümüz dijital dünyasında güvenli iletişim, veri bütünlüğü ve kimlik doğrulama, siber güvenliğin temel taşlarından biridir. Bu hedeflere ulaşmanın en yaygın ve etkili yollarından biri, Açık Anahtar Altyapısı (PKI) ve dijital sertifikaların kullanılmasıdır. Bir Sertifika Otoritesi (CA), bu PKI’nın merkezinde yer alan, dijital sertifikaları veren, yöneten ve iptal eden güvenilir bir üçüncü taraftır. Kendi Sertifika Otoritenizi kurmak, özellikle kapalı ağ ortamlarında, geliştirme süreçlerinde veya belirli hizmetler için özel sertifikalar gerektiren durumlarda büyük esneklik ve kontrol sağlar.
Bu kapsamlı teknik makalede, Ubuntu 22.04 işletim sistemi üzerinde adım adım kendi özel Sertifika Otoritenizi (CA) nasıl kuracağınızı ve yapılandıracağınızı anlatacağız. Makale, kök CA oluşturmaktan başlayarak, alt CA (isteğe bağlı), sunucu ve istemci sertifikaları oluşturmaya, bunları imzalamaya ve sertifika iptal listesi (CRL) yönetimine kadar tüm süreci detaylandıracaktır. Amacımız, okuyuculara pratik ve güvenli bir CA çözümü oluşturmaları için gerekli bilgi ve komutları sunmaktır.
Sertifika Otoritesi (CA) Nedir ve Neden İhtiyaç Duyulur?
Sertifika Otoritesi (CA) ve Açık Anahtar Altyapısı (PKI)
Sertifika Otoritesi (CA), dijital sertifikaları düzenleyen, imzalayan ve yöneten güvenilir bir kuruluştur. Bir dijital sertifika, bir varlığın (kullanıcı, sunucu, uygulama vb.) kimliğini doğrulamak için kullanılan elektronik bir belgedir. Bu sertifikalar, anahtar çiftlerinin (genel anahtar ve özel anahtar) genel anahtarını belirli bir kimlikle ilişkilendirir. PKI ise, dijital sertifikaların oluşturulması, yönetilmesi, dağıtılması, kullanılması, depolanması ve iptal edilmesi için gerekli olan tüm donanım, yazılım, politikalar ve prosedürler kümesidir.
Bir PKI’nın temel bileşenleri şunlardır:
* Sertifika Otoritesi (CA): Sertifikaları veren ve imzalayan güvenilir varlık.
* Kayıt Otoritesi (RA): CA adına sertifika taleplerini doğrulayan ve işleyen varlık.
* Sertifika Deposu: Sertifikaların ve CRL’lerin saklandığı bir veritabanı.
* Sertifika İptal Listesi (CRL): Geçerlilik süresi dolmadan önce iptal edilen sertifikaların listesi.
Neden Kendi CA’nıza İhtiyaç Duyasınız?
Kendi CA’nızı kurmanın çeşitli nedenleri vardır:
* İç Ağ Güvenliği: Şirket içi sunucular, VPN’ler, Wi-Fi ağları ve diğer dahili hizmetler için güvenilir sertifikalar sağlamak. Böylece, harici CA’lara bağımlılık ortadan kalkar ve maliyetler düşer.
* Geliştirme ve Test Ortamları: Geliştirme aşamasındaki uygulamalar ve hizmetler için gerçek sertifikalara ihtiyaç duymadan güvenli bir ortam oluşturmak.
* Maliyet Tasarrufu: Ticari CA’lardan sertifika satın alma maliyetlerinden kaçınmak. Özellikle çok sayıda sertifikaya ihtiyaç duyulan durumlarda bu önemlidir.
* Tam Kontrol: Sertifika yaşam döngüsü (oluşturma, yenileme, iptal etme) üzerinde tam kontrol sağlamak.
* Özel Gereksinimler: Ticari CA’ların sunmadığı özel sertifika uzantıları veya politikaları gerektiren durumlar.
Bu makalede openssl aracı kullanılarak bir CA oluşturulacaktır. openssl, açık kaynaklı, güçlü, çok yönlü bir komut satırı aracıdır ve SSL/TLS protokolleri ile ilgili kriptografik işlevler sunar.
Ön Hazırlıklar
CA kurulumuna başlamadan önce aşağıdaki ön hazırlıkları yapmanız gerekmektedir:
Sistem Gereksinimleri
* İşletim Sistemi: Ubuntu 22.04 LTS (Jammy Jellyfish) veya uyumlu bir Debian tabanlı dağıtım.
* Yetkilendirme: sudo ayrıcalıklarına sahip bir kullanıcı hesabı.
* Disk Alanı: CA dosyaları için yeterli disk alanı (genellikle çok fazla yer kaplamaz).
Gerekli Paketlerin Kurulumu
Ubuntu 22.04 genellikle openssl paketini varsayılan olarak içerir. Ancak, kurulu olup olmadığını kontrol etmek ve gerekirse kurmak iyi bir uygulamadır:
sudo apt update
sudo apt install openssl -yCA Dizin Yapısının Planlanması
Güvenlik ve düzen açısından, CA dosyalarını belirli bir dizin yapısı içinde saklamak önemlidir. Kök CA için /etc/ssl/ca ve isteğe bağlı olarak alt CA için /etc/ssl/subca gibi bir yapı kullanabiliriz. Bu makalede kök CA için /etc/ssl/ca dizinini kullanacağız.
CA Kurulum Adımları
CA Dizin Yapısının Oluşturulması
İlk adım olarak, CA’mız için gerekli dizin yapısını oluşturalım. Bu yapı, özel anahtarları, sertifikaları, sertifika imzalama isteklerini (CSR’ler), sertifika iptal listelerini (CRL’ler) ve diğer ilgili dosyaları düzenli bir şekilde saklamamızı sağlayacaktır.
sudo mkdir -p /etc/ssl/ca/{certs,crl,newcerts,private,csr}
sudo chmod 700 /etc/ssl/ca/private* certs: İmzalanmış sertifikaların depolanacağı yer.
* crl: Sertifika İptal Listelerinin (CRL) depolanacağı yer.
* newcerts: Yeni imzalanan sertifikaların sembolik bağlantılarının tutulacağı yer.
* private: CA’nın özel anahtarının saklanacağı yer. Bu dizin yalnızca root kullanıcısı tarafından okunabilir olmalıdır (chmod 700).
* csr: Sertifika İmzalama İsteklerinin (CSR) depolanacağı yer.
CA’nın durumunu takip etmek için iki önemli dosya oluşturmamız gerekiyor: index.txt ve serial.
* index.txt: CA tarafından verilen tüm sertifikaların bir veritabanı görevi görür. Boş bir dosya olarak başlar.
* serial: Yeni sertifikalar için kullanılacak bir sonraki seri numarasını içerir. Genellikle 1000 ile başlatılır.
sudo touch /etc/ssl/ca/index.txt
sudo sh -c 'echo 1000 > /etc/ssl/ca/serial'CA Yapılandırma Dosyasının Oluşturulması
openssl komutunun nasıl davranacağını belirleyen bir yapılandırma dosyasına ihtiyacımız var. Bu dosya, CA’nın varsayılan ayarlarını, anahtar boyutlarını, sertifika geçerlilik sürelerini ve politikalarını tanımlar. /etc/ssl/ca/openssl.cnf dosyasını oluşturalım:
sudo nano /etc/ssl/ca/openssl.cnfDosya içeriği aşağıdaki gibi olmalıdır:
# OpenSSL root CA configuration file.
Copy to '/etc/ssl/ca/openssl.cnf'.
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/ssl/ca # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
new_certs_dir = $dir/newcerts # Default place for new certs.
database = $dir/index.txt # Database index file.
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number (srl)
crlnumber must also be created initially.
touch $dir/crlnumber
echo 1000 > $dir/crlnumber
private_key = $dir/private/ca.key.pem # The private key
certificate = $dir/certs/ca.cert.pem # The CA certificate
For certificate revocation lists.
crl = $dir/crl/ca.crl.pem # The current CRL
default_crl_days = 30 # How long before next CRL
default_days = 3650 # How long to certify for (10 years)
default_md = sha256 # Use SHA-256 for digests
preserve = no # Keep passed DN ordering
policy = policy_strict
x509_extensions = v3_ca # The extensions to add to the cert
For the CA policy
[ policy_strict ]
The root CA should only sign certs for itself,
so we reject anything that doesn't match.
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ policy_loose ]
Allow more flexibility for subordinate CAs or other certs
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
For the CA certificate itself
[ req ]
default_bits = 4096 # RSA key size
distinguished_name = req_distinguished_name
string_mask = utf8only # UTF-8 for names
default_md = sha256 # Use SHA-256 for digests
The root CA request will be self-signed.
x509_extensions = v3_ca
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (e.g. server FQDN or YOUR name)
emailAddress = Email Address
For the CA certificate itself
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
For subordinate CA certificates
[ v3_sub_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
For server certificates
[ server_cert ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
For client certificates
[ client_cert ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
For CRLs
[ crl_ext ]
authorityKeyIdentifier = keyid:always,issuerÖnemli Notlar:
* default_days = 3650: Kök CA sertifikasının 10 yıl geçerli olacağını belirtir.
* default_md = sha256: Hashing algoritması olarak SHA-256 kullanır.
* policy = policy_strict: Sertifika imzalama sırasında alanların kesinlikle eşleşmesini gerektiren katı bir politika uygular.
* x509_extensions = v3_ca: Kök CA sertifikasına v3_ca uzantılarını ekler, bu da sertifikayı bir CA olarak işaretler.
* [v3_ca], [v3_sub_ca], [server_cert], [client_cert] gibi bölümler, farklı sertifika türleri için özel uzantıları tanımlar. Bu uzantılar, sertifikanın ne amaçla kullanılabileceğini belirler (örn. CA olarak imzalama, sunucu kimlik doğrulaması, istemci kimlik doğrulaması).
CA Kök Anahtarının ve Sertifikasının Oluşturulması
Şimdi CA’nın özel anahtarını ve kendi kendini imzalayan kök sertifikasını oluşturabiliriz.
Kök CA Özel Anahtarının Oluşturulması
Bu anahtar, tüm sertifikaları imzalamak için kullanılacağından son derece önemlidir ve güvenli bir şekilde saklanmalıdır. aes256 ile şifrelenecek ve bir parola ile korunacaktır.
sudo openssl genrsa -aes256 -out /etc/ssl/ca/private/ca.key.pem 4096
sudo chmod 400 /etc/ssl/ca/private/ca.key.pem* genrsa: RSA özel anahtarı oluşturur.
* -aes256: Anahtarı AES-256 şifrelemesi ile korur. Bir parola girmeniz istenecektir. Bu parolayı unutmayın!
* -out: Anahtarın kaydedileceği dosya.
* 4096: Anahtarın bit cinsinden boyutu. Daha büyük boyut, daha güçlü güvenlik sağlar.
* chmod 400: Özel anahtar dosyasının yalnızca root kullanıcısı tarafından okunabilir olmasını sağlar.
Kök CA Kendi Kendini İmzalayan Sertifikasının Oluşturulması
Bu sertifika, CA’nın kimliğini doğrular ve diğer tüm sertifikaların güven zincirinin kökünü oluşturur.
sudo openssl req -x509 -new -nodes -key /etc/ssl/ca/private/ca.key.pem -sha256 -days 3650 -out /etc/ssl/ca/certs/ca.cert.pem -config /etc/ssl/ca/openssl.cnf* req: Sertifika imzalama isteği (CSR) veya kendi kendini imzalayan sertifika oluşturur.
* -x509: Kendi kendini imzalayan bir sertifika oluşturur.
* -new: Yeni bir sertifika isteği oluşturur.
* -nodes: Anahtarın şifrelenmemesini sağlar (ancak biz anahtarı zaten şifreledik, bu komut sertifika isteği için parolayı sormaz).
* -key: Kullanılacak özel anahtar.
* -sha256: Hashing algoritması.
* -days 3650: Sertifikanın geçerlilik süresi (10 yıl).
* -out: Sertifikanın kaydedileceği dosya.
* -config: Kullanılacak yapılandırma dosyası.
Komutu çalıştırdığınızda, CA’nın kimliğini belirten bilgiler girmeniz istenecektir. Bu bilgiler, sertifikada “Subject” alanı olarak görünecektir:
* Country Name (2 letter code) [AU]: TR
* State or Province Name (full name) [Some-State]: Istanbul
* Locality Name (eg, city) []: Kadikoy
* Organization Name (eg, company) [Internet Widgits Pty Ltd]: MyCompany CA
* Organizational Unit Name (eg, section) []: IT
* Common Name (e.g. server FQDN or YOUR name) []: MyCompany Root CA
* Email Address []: ca@mycompany.com
Common Name (Ortak Ad) alanı, CA’nın adını açıkça belirtmelidir. Örneğin, “MyCompany Root CA”.
CA Sertifikasını Doğrulama
Oluşturduğunuz kök CA sertifikasının içeriğini kontrol edebilirsiniz:
sudo openssl x509 -in /etc/ssl/ca/certs/ca.cert.pem -text -nooutBu komut, sertifikanın tüm detaylarını (geçerlilik süresi, veren, konu, uzantılar vb.) gösterecektir. Basic Constraints: CA:TRUE ve Key Usage: ... keyCertSign, cRLSign gibi uzantıların doğru şekilde ayarlandığından emin olun.
Alt Sertifika Otoritesi (Subordinate CA) Oluşturma (İsteğe Bağlı)
Güvenlik en iyi uygulamalarından biri, kök CA’yı çevrimdışı (air-gapped) tutmak ve günlük sertifika imzalama işlemleri için bir alt (subordinate) CA kullanmaktır. Bu bölüm, böyle bir alt CA’nın nasıl oluşturulacağını açıklar. Eğer sadece basit bir kök CA yeterliyse, bu bölümü atlayabilirsiniz.
Alt CA Dizin Yapısının Oluşturulması
Alt CA için de benzer bir dizin yapısı oluşturacağız, örneğin /etc/ssl/subca.
sudo mkdir -p /etc/ssl/subca/{certs,crl,newcerts,private,csr}
sudo chmod 700 /etc/ssl/subca/private
sudo touch /etc/ssl/subca/index.txt
sudo sh -c 'echo 1000 > /etc/ssl/subca/serial'Alt CA Yapılandırma Dosyasının Oluşturulması
Alt CA için de kendi openssl.cnf dosyasına ihtiyacımız var. Bu dosya, kök CA’nınkiyle benzer olacak, ancak dir yolu ve bazı varsayılan ayarlar farklılık gösterecektir. En önemlisi, alt CA sertifikası imzalanırken v3_sub_ca uzantıları kullanılacaktır.
sudo nano /etc/ssl/subca/openssl.cnfDosya içeriği, dir yolunu /etc/ssl/subca olarak güncelleyerek ve x509_extensions = v3_sub_ca kullanarak kök CA yapılandırma dosyasına benzer olacaktır:
# OpenSSL subordinate CA configuration file.
Copy to '/etc/ssl/subca/openssl.cnf'.
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/ssl/subca # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
new_certs_dir = $dir/newcerts # Default place for new certs.
database = $dir/index.txt # Database index file.
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number (srl)
touch $dir/crlnumber
echo 1000 > $dir/crlnumber
private_key = $dir/private/subca.key.pem # The private key
certificate = $dir/certs/subca.cert.pem # The CA certificate
crl = $dir/crl/subca.crl.pem # The current CRL
default_crl_days = 7 # How long before next CRL
default_days = 1825 # How long to certify for (5 years)
default_md = sha256 # Use SHA-256 for digests
preserve = no # Keep passed DN ordering
policy = policy_strict
x509_extensions = v3_sub_ca # The extensions to add to the cert
... (policy_strict, policy_loose, req, req_distinguished_name bölümleri kök CA ile aynı kalabilir) ...
Sadece uzantılar bölümünü tekrar ekleyelim, tam bir dosya olsun
[ policy_strict ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ policy_loose ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha256
x509_extensions = v3_sub_ca
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (e.g. server FQDN or YOUR name)
emailAddress = Email Address
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ v3_sub_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ server_cert ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[ client_cert ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ crl_ext ]
authorityKeyIdentifier = keyid:always,issuerÖnemli Not: pathlen:0 uzantısı, bu alt CA’nın başka bir alt CA imzalayamayacağını belirtir. Bu, güven zincirinin derinliğini sınırlar ve güvenlik açısından iyi bir uygulamadır.
Alt CA Anahtarının Oluşturulması
sudo openssl genrsa -aes256 -out /etc/ssl/subca/private/subca.key.pem 4096
sudo chmod 400 /etc/ssl/subca/private/subca.key.pemAlt CA Sertifika İmzalama İsteği (CSR) Oluşturma
Alt CA için bir CSR oluşturulur. Bu CSR, kök CA tarafından imzalanacaktır.
sudo openssl req -new -sha256 -key /etc/ssl/subca/private/subca.key.pem -out /etc/ssl/subca/csr/subca.csr.pem -config /etc/ssl/subca/openssl.cnfCommon Name için “MyCompany Subordinate CA” gibi bir isim kullanın.
Kök CA Tarafından Alt CA Sertifikasının İmzalama
Şimdi kök CA’yı kullanarak alt CA’nın CSR’sini imzalayacağız. Bu işlem için kök CA’nın özel anahtarının parolasına ihtiyacınız olacaktır.
sudo openssl ca -config /etc/ssl/ca/openssl.cnf -extensions v3_sub_ca -days 1825 -notext -md sha256 -in /etc/ssl/subca/csr/subca.csr.pem -out /etc/ssl/subca/certs/subca.cert.pem* -config /etc/ssl/ca/openssl.cnf: Kök CA’nın yapılandırma dosyasını kullanır.
* -extensions v3_sub_ca: Alt CA için özel uzantıları uygular.
* -days 1825: Alt CA sertifikasının 5 yıl geçerli olacağını belirtir.
Komutu çalıştırdığınızda, sertifika isteğini onaylamanız istenecektir (Sign the certificate? [y/n]) ve ardından kök CA’nın özel anahtarının parolası sorulacaktır.
Alt CA Sertifikasını Doğrulama
sudo openssl x509 -in /etc/ssl/subca/certs/subca.cert.pem -text -nooutBurada Basic Constraints: CA:TRUE, pathlen:0 ve Key Usage: ... keyCertSign, cRLSign uzantılarının doğru ayarlandığını kontrol edin.
Bundan sonraki tüm sertifika imzalama işlemleri için (sunucu, istemci) alt CA’yı kullanabilirsiniz. Bu, kök CA’yı çevrimdışı tutmanıza olanak tanır. Eğer alt CA oluşturmadıysanız, aşağıdaki adımlarda /etc/ssl/ca/openssl.cnf dosyasını kullanmaya devam edin.
Sunucu Sertifikası Oluşturma ve İmzalama
Bir web sunucusu (Apache, Nginx vb.) veya başka bir hizmet için SSL/TLS şifrelemesi sağlamak amacıyla bir sunucu sertifikasına ihtiyacımız var.
Sunucu Anahtarının Oluşturulması
Sunucu için özel anahtar oluşturulur. Bu anahtarın şifresiz olması tercih edilir, böylece sunucu yeniden başlatıldığında otomatik olarak başlatılabilir.
sudo openssl genrsa -out /etc/ssl/ca/private/server.key.pem 2048
sudo chmod 400 /etc/ssl/ca/private/server.key.pem* 2048: Anahtar boyutu. Üretim ortamları için genellikle 2048 veya 4096 bit kullanılır.
Sunucu Sertifika İmzalama İsteği (CSR) Oluşturma
Sunucu sertifikası için bir CSR oluşturulur. Common Name (Ortak Ad) alanı, sunucunun tam nitelikli alan adını (FQDN) içermelidir (örn. www.example.com).
sudo openssl req -new -sha256 -key /etc/ssl/ca/private/server.key.pem -out /etc/ssl/ca/csr/server.csr.pem -config /etc/ssl/ca/openssl.cnf* Common Name: www.example.com veya sunucunuzun IP adresi.
CA Tarafından Sunucu Sertifikasının İmzalama
Şimdi CA (kök veya alt CA) kullanarak sunucu CSR’sini imzalayacağız. Bu örnekte kök CA’yı kullanıyoruz. Eğer alt CA’yı kullanıyorsanız, openssl ca -config /etc/ssl/subca/openssl.cnf ... komutunu kullanmalısınız.
sudo openssl ca -config /etc/ssl/ca/openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in /etc/ssl/ca/csr/server.csr.pem -out /etc/ssl/ca/certs/server.cert.pem* -extensions server_cert: Sunucu sertifikası için özel uzantıları uygular. Bu uzantılar, sertifikanın serverAuth için kullanılabileceğini belirtir.
* -days 375: Sertifikanın geçerlilik süresi (genellikle 1 yıl + birkaç gün).
Sunucu Sertifikasını Doğrulama
sudo openssl x509 -in /etc/ssl/ca/certs/server.cert.pem -text -nooutBurada Basic Constraints: CA:FALSE ve Extended Key Usage: TLS Web Server Authentication uzantılarının doğru ayarlandığını kontrol edin.
Bu sertifikayı, Apache, Nginx veya diğer web sunucularınızda kullanabilirsiniz. Genellikle sunucuya server.key.pem ve server.cert.pem dosyalarını kopyalamanız ve web sunucusunun yapılandırma dosyalarında belirtmeniz gerekir. Ayrıca, CA sertifikasını (örn. ca.cert.pem veya subca.cert.pem) web sunucusuna zincir sertifika olarak eklemeniz gerekebilir, böylece istemciler sunucu sertifikasının güvenilirliğini doğrulayabilir.
İstemci Sertifikası Oluşturma ve İmzalama
İstemci sertifikaları, kullanıcıların veya cihazların belirli hizmetlere erişirken kimliklerini doğrulamak için kullanılır. Örneğin, VPN’ler, SSH veya belirli web uygulamaları için kullanılabilirler.
İstemci Anahtarının Oluşturulması
sudo openssl genrsa -out /etc/ssl/ca/private/client.key.pem 2048
sudo chmod 400 /etc/ssl/ca/private/client.key.pemİstemci Sertifika İmzalama İsteği (CSR) Oluşturma
Common Name alanı, istemcinin kimliğini belirten bir isim veya kullanıcı adı içermelidir (örn. john.doe).
sudo openssl req -new -sha256 -key /etc/ssl/ca/private/client.key.pem -out /etc/ssl/ca/csr/client.csr.pem -config /etc/ssl/ca/openssl.cnf* Common Name: john.doe
CA Tarafından İstemci Sertifikasının İmzalama
Yine, kök CA’yı (veya alt CA’yı) kullanarak istemci CSR’sini imzalayacağız.
sudo openssl ca -config /etc/ssl/ca/openssl.cnf -extensions client_cert -days 375 -notext -md sha256 -in /etc/ssl/ca/csr/client.csr.pem -out /etc/ssl/ca/certs/client.cert.pem* -extensions client_cert: İstemci sertifikası için özel uzantıları uygular. Bu uzantılar, sertifikanın clientAuth için kullanılabileceğini belirtir.
İstemci Sertifikasını Doğrulama
sudo openssl x509 -in /etc/ssl/ca/certs/client.cert.pem -text -nooutBurada Basic Constraints: CA:FALSE ve Extended Key Usage: TLS Web Client Authentication uzantılarının doğru ayarlandığını kontrol edin.
İstemci sertifikalarını genellikle .p12 veya .pfx formatına dönüştürüp kullanıcılara dağıtmanız gerekir, böylece tarayıcılara veya işletim sistemlerine kolayca aktarılabilirler.
# İstemci sertifikasını ve anahtarını bir .p12 dosyasına dönüştürme
sudo openssl pkcs12 -export -out /etc/ssl/ca/certs/client.p12 -inkey /etc/ssl/ca/private/client.key.pem -in /etc/ssl/ca/certs/client.cert.pem -certfile /etc/ssl/ca/certs/ca.cert.pem -name "John Doe Client Cert"Bu komut, istemcinin özel anahtarını, sertifikasını ve CA sertifikasını tek bir şifreli dosyada birleştirir. Bir dışa aktarma parolası belirlemeniz istenecektir.
Sertifika İptal Listesi (CRL) Yönetimi
Bazen bir sertifika, geçerlilik süresi dolmadan önce iptal edilmesi gerekebilir (örn. özel anahtarın ele geçirilmesi, kullanıcının işten ayrılması). Sertifika İptal Listesi (CRL), iptal edilen sertifikaların bir listesidir.
CRL Numarası Dosyasının Oluşturulması
İlk CRL’yi oluşturmadan önce bir crlnumber dosyası oluşturmalıyız.
sudo sh -c 'echo 1000 > /etc/ssl/ca/crlnumber'CRL Oluşturma
İlk CRL’yi oluşturun:
sudo openssl ca -config /etc/ssl/ca/openssl.cnf -gencrl -out /etc/ssl/ca/crl/ca.crl.pemBu komut, CA’nın özel anahtarının parolasını isteyecektir.
Sertifika İptal Etme
Bir sertifikayı iptal etmek için revoke komutunu kullanın:
sudo openssl ca -config /etc/ssl/ca/openssl.cnf -revoke /etc/ssl/ca/certs/server.cert.pemBu komut, belirtilen sertifikayı CA’nın index.txt veritabanında “Revoked” (İptal Edildi) olarak işaretler. Ancak, bu değişiklik CRL’ye yansımaz.
CRL Güncelleme
İptal edilen sertifikaların CRL’ye yansıması için CRL’yi yeniden oluşturmanız veya güncellemeniz gerekir:
sudo openssl ca -config /etc/ssl/ca/openssl.cnf -gencrl -out /etc/ssl/ca/crl/ca.crl.pemGüncellenmiş CRL, iptal edilen sertifikaların seri numaralarını içerecektir. Sunucularınızın veya istemcilerinizin bu CRL’yi düzenli olarak kontrol etmesi önemlidir.
Güvenlik Hususları
Kendi CA’nızı yönetirken güvenlik son derece önemlidir. İşte dikkat etmeniz gereken bazı temel noktalar:
* Kök CA’yı Çevrimdışı Tutun (Air-Gapped): Kök CA’nın özel anahtarı, PKI’nızın en kritik bileşenidir. Bu anahtarın ele geçirilmesi, tüm güven zincirinizin tehlikeye girmesi anlamına gelir. Kök CA’yı fiziksel olarak ağdan izole edilmiş bir makinede tutmak en güvenli yaklaşımdır. Günlük imzalama işlemleri için bir alt CA kullanın.
* Özel Anahtarları Koruyun: Tüm özel anahtarlar (CA, alt CA, sunucu, istemci) güçlü parolalarla şifrelenmeli ve dosya izinleri (chmod 400) ile korunmalıdır. Yalnızca yetkili kişilerin bu anahtarlara erişimi olmalıdır.
* Düzenli Yedeklemeler: CA dizin yapısının (özellikle private dizini, index.txt ve serial dosyaları) düzenli ve güvenli yedeklerini alın.
* Fiziksel Güvenlik: CA sunucusunun fiziksel güvenliğini sağlayın. Yalnızca yetkili personele erişim izni verin.
* CRL ve OCSP: Sertifika iptal listelerini (CRL) düzenli olarak güncelleyin ve dağıtımını sağlayın. Büyük ölçekli PKI’lar için daha verimli bir alternatif olan Çevrimiçi Sertifika Durumu Protokolü (OCSP) düşünülmelidir.
* Güncel Yazılım: Ubuntu ve OpenSSL paketlerini düzenli olarak güncelleyerek bilinen güvenlik açıklarından korunmaya dikkat edin.
* Denetim Kayıtları: CA işlemlerinin (sertifika verme, iptal etme vb.) denetim kayıtlarını tutun.
Sonuç
Bu makalede, Ubuntu 22.04 üzerinde kendi Sertifika Otoritenizi (CA) kurmak ve yapılandırmak için gerekli tüm adımları detaylı bir şekilde inceledik. Kök CA oluşturmaktan başlayarak, alt CA, sunucu ve istemci sertifikalarının nasıl oluşturulacağını, imzalanacağını ve iptal listelerinin nasıl yönetileceğini öğrendik. Ayrıca, CA’nızın güvenliğini sağlamak için önemli hususlara da değindik.
Kendi CA’nızı yönetmek, iç ağlarınızda ve özel hizmetlerinizde güçlü bir güvenlik kontrolü sağlar. Ancak, bu sorumlulukla birlikte gelen güvenlik risklerinin farkında olmak ve en iyi uygulamaları takip etmek hayati önem taşır. Doğru yapılandırılmış ve güvenli bir CA ile, dijital iletişimlerinizi güvenilir bir şekilde şifreleyebilir, kimlikleri doğrulayabilir ve veri bütünlüğünü sağlayabilirsiniz. Bu kurulum, PKI dünyasına sağlam bir giriş noktası sunarak, dijital güvenliğinizi kendi ellerinize almanızı sağlar.