HTTPS, TLS ve sertifikalar
Sertifikalar, SAN ve güven zinciri
Şifreli olmak ile doğru sunucuya bağlı olmak ayrı kontrollerdir.
Kavramı anlayalım
Sunucu sertifikası bir isim ve public key bağını doğrulanan bir zincirle sunar. Tarayıcı uygun güven köküne zinciri, geçerlilik süresini ve erişilen host ile SAN isimlerinin eşleşmesini değerlendirir. Domain doğrulamalı sertifika şirketin ahlaki güvenilirliğini kanıtlamaz.
Eksik intermediate sertifika bazı istemcilerde çalışıp bazılarında hata verebilir. Wildcard genellikle tek isim seviyesini kapsar; *.example.test, a.b.example.test’i otomatik kapsamaz. Sertifikanın yenilenmesiyle proxy’nin yeni dosyayı gerçekten yüklemesi ayrı adımlardır. Saat yanlışlığı da geçerlilik hatası yaratabilir.
Private key korunmalıdır; depoya veya örnek kodlara konmaz. Otomatik yenileme, alarm ve expiry kontrolü gerekir. Sertifika pinning bazı ortamlarda rotasyonu zorlaştırabilir; rastgele eklenen bir güvenlik etiketi değildir. İstemcinin doğrulamasını kapatmak kök problemi gizler.
“Benim bilgisayarımda açılıyor” TLS hatalarını çözmek için.
curl -k ile çalışınca sertifika sorunu çözüldü sanmak.
Aynı konu. Üç farklı derinlik.
Host: api.example.test
Certificate SAN: api.example.testHost kimliği eşleşmelidir.
Bu sayfa dış sunuculara istek göndermez. HTTP mesajları temsili, HTTP/1.1 biçiminde okunabilir gösterimlerdir; HTTP/2 ve HTTP/3 wire formatı değildir. example.test ayrılmış öğretim alan adıdır. Komut ve JavaScript örneklerini yalnız kendi test ortamında uygula; gerçek token veya cookie yayımlama.
Önce kendin dene.
Sertifika expired ise sadece client doğrulamasını kapatmalı mısın?
Çözümü ve açıklamasını göster
Renew → deploy → verify → monitorHayır; yenile, doğru yerde yükle ve gerçek istemcilerle doğrula.