Linux'ta TLS Sertifika Doğrulaması: Neden Uygulamalar Aynı Sunucuda Anlaşamaz
Linux'ta TLS sertifika doğrulamasının uygulama bazında nasıl farklılaştığını, sistem güven deposunun sınırlarını ve özel CA sorunlarını inceliyoruz.
Linux'ta 'sistem güven deposu' aslında bir zorlama mekanizması değil, bir centilmenlik anlaşmasıdır. TLS doğrulaması tamamen kullanıcı alanında, her uygulamanın bağlandığı kütüphane içinde gerçekleşir ve çekirdek bu sürece hiç karışmaz. Bu yüzden aynı makinede curl bir sertifikaya güvenirken bir Java servisi 'certificate verify failed' hatası verebilir.
Sorunun kökü zincir doğrulama mekaniğinde değil, güven kaynağının parçalanmışlığında. OpenSSL, GnuTLS ve NSS kendi varsayılan yollarına sahip; dağıtımlar bunları /etc/ssl veya /etc/pki/ca-trust altındaki sisteme yönlendirir ama tutarlılık garanti değil. Daha da önemlisi Java kendi cacerts deposunu taşır, Node.js Mozilla kök listesini derleme zamanında ikiliye gömer, Python'da ise standart kütüphane sistem deposunu kullanırken requests kütüphanesi certifi paketiyle tamamen ayrı bir kaynağa güvenir.
Bu parçalanma özellikle kurumsal ortamlarda kendi CA'nızı çalıştırdığınızda acı verici hale gelir. Sistem deposuna CA ekleyip update-ca-certificates çalıştırmak yalnızca C tabanlı araçları çözer; ardından Java için keytool, Node için NODE_EXTRA_CA_CERTS, Python/requests için REQUESTS_CA_BUNDLE ayarlamak, sonra her container'ın kendi izole /etc/ssl'ini tekrar yamalamak gerekir. Mühendisler için pratik sonuç açık: 'sistem bu sertifikaya güveniyor' diye bir şey yok, sadece her çalışma zamanının kendi güven kararı var.