Tiesto

Tiesto

WFN Üye
Konular
635
Mesajlar
635
Çözüm
0
Ticaret Puanı
0
Üyelik
24 Gün
Konum
Antalya
Web Sitesi
Var
Alanı
Domain Uzmanı
1/1
Konu sahibi
İlk olarak sertifikanın nasıl üretildiğini belirleyin: Certbot gibi bir ACME istemcisiyle alınan sertifikalar komut satırından, cPanel AutoSSL sertifikaları panelden veya cPanel komutlarıyla, elle yüklenen ticari sertifikalar ise yeni sertifika dosyaları sunucuya kopyalanıp web sunucusu yeniden yüklenerek yenilenir. Yenileme tamamlandıktan sonra yalnızca dosyanın değiştiğini değil, HTTPS servisinin gerçekten yeni sertifikayı sunduğunu da kontrol edin.

İşleme başlamadan önce sertifika yöntemini belirleyin​


Sunucuya root veya sudo yetkisiyle bağlanın ve önce hangi web sunucusunun çalıştığını, sertifikanın hangi dosyalardan okunduğunu ve yenileme işlemini hangi aracın yönettiğini tespit edin. Aynı alan adı için hem Certbot hem de panel üzerinden işlem yapmak, sertifika dosyalarının farklı yerlere yazılmasına ve yanlış dosyanın yüklenmesine neden olabilir.

Aşağıdaki ayrım doğru yolu seçmenizi sağlar:
Kurulum biçimiYenileme yoluYenileme sonrasında
Certbot veya başka ACME istemcisiİstemcinin yenileme komutunu çalıştırınWeb sunucusunu reload edin veya istemcinin deploy hook yapılandırmasını kullanın
cPanel AutoSSLcPanel’de SSL/TLS Status bölümünden AutoSSL çalıştırın veya yetkili komutu kullanınAlan adının ve ilgili servislerin yeni sertifikayı sunduğunu doğrulayın
Elle yüklenmiş ticari sertifikaYeni sertifika, ara sertifika ve özel anahtar dosyalarını sağlayıcının talimatına göre yerleştirinWeb sunucusunun yapılandırmasını test edip yeniden yükleyin
Bu tablo yalnız yöntemi ayırır; sertifikanın hangi dosyada olduğunu tek başına göstermez. Nginx yapılandırmasındaki ssl_certificate ve ssl_certificate_key, Apache yapılandırmasındaki SSL direktifleri veya panelin SSL yönetimi incelenmelidir. Özel anahtar dosyasını kimseyle paylaşmayın ve değiştirmeden önce mevcut yapılandırmanın yedeğini alın.

Certbot ile alınan sertifikayı yenileme​


Certbot kuruluysa önce deneme yenilemesi yapın. Bu işlem gerçek sertifikayı değiştirmeden yenileme koşullarının ve alan adı doğrulamasının çalışıp çalışmadığını gösterir:

Bash: 
sudo certbot renew --dry-run

Komut başarılıysa gerçek yenilemeyi çalıştırın:

Bash: 
sudo certbot renew

renew komutu yalnız yenileme zamanı gelen sertifikaları yeniler; bu nedenle başarılı bir sonuç her sertifikanın o anda değiştirildiği anlamına gelmez. Çıktıda sertifikanın yenilendiği veya henüz yenileme dönemine girmediği belirtilir. Hata alırsanız özellikle alan adı doğrulaması, DNS kaydı, 80/443 numaralı portlara erişim, web kök dizini ve sertifika dosyalarının izinlerini kontrol edin.

Sertifika dosyaları yenilense bile çalışan Nginx veya Apache süreci eski sertifikayı belleğinde tutabilir. Nginx kullanıyorsanız önce yapılandırmayı test edin, ardından reload uygulayın:

Bash: 
sudo nginx -t
sudo systemctl reload nginx

nginx -t yapılandırma sözdizimini ve yapılandırmada belirtilen dosyaların açılabilirliğini denetler. Test başarısızsa reload çalıştırmayın; hata mesajındaki dosya yolu ve satır numarasını düzeltin. Nginx’in yapılandırma değişikliklerini uygulaması için reload veya yeniden başlatma gerekir; reload işlemi başarılı olmazsa eski çalışan yapılandırma korunabilir. Bu nedenle komutun sessiz dönmesi, yeni sertifikanın kesinlikle sunulduğunu kanıtlamaz.

Apache kullanıyorsanız dağıtımınıza göre servis adını doğrulayarak yapılandırma testi ve graceful reload uygulayın. Yaygın örnek şöyledir:

Bash: 
sudo apachectl configtest
sudo systemctl reload apache2

Bazı sistemlerde servis adı httpd olabilir. Test komutu hata verirse yeni sertifika dosyalarının yolu, özel anahtarın eşleşmesi ve Apache sanal ana bilgisayar yapılandırması kontrol edilmelidir. Sertifika dosyası ile özel anahtarın birbirine ait olmaması, web sunucusunun yeniden yüklenmesini engelleyebilir.

cPanel AutoSSL kullanılıyorsa​


cPanel hesabında SSL/TLS Status bölümünü açıp ilgili kullanıcı için AutoSSL çalıştırın. WHM yöneticisiyseniz tüm kullanıcılar için AutoSSL işlemi şu komutla başlatılabilir:

Bash: 
/usr/local/cpanel/bin/autossl_check --all

Sunucunun hostname sertifikasını yenilemek için root kullanıcısıyla şu komut kullanılır:

Bash: 
/usr/local/cpanel/bin/checkallsslcerts

AutoSSL’nin çalışması, her alan adının mutlaka yenilendiği anlamına gelmez. Alan adı doğrulaması başarısızsa DNS, HTTP doğrulama yolu veya CAA kaydı incelenmelidir. cPanel belgelerine göre AutoSSL, yenileme dönemi gelen sertifikaları işler; bazı sağlayıcılarda yenileme, sertifikanın sona ermesine belirli bir süre kalınca denenir. Ayrıca AutoSSL dışındaki bir sağlayıcının verdiği sertifikayı varsayılan olarak değiştirmeyebilir.

Komut veya panel çıktısında bir alan adının doğrulanamadığını görürseniz, hata veren tam alan adını, doğrulama yöntemini ve hata metnini kaydedin. DNS kullanılıyorsa alan adının güncel sunucuya çözümlendiğini ve CAA kaydının seçilen sertifika otoritesine izin verdiğini; HTTP doğrulaması kullanılıyorsa doğrulama isteğinin ilgili sunucuya ulaştığını kontrol edin. Sorun düzeltilmeden aynı isteği tekrar tekrar göndermek yerine önce DNS veya web sunucusu tarafındaki nedeni giderin.

Yeni sertifikanın gerçekten sunulduğunu doğrulama​


Yenileme ve reload sonrasında sunucunun 443 numaralı portundan sunulan sertifikayı kontrol edin:

Bash: 
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -serial

Buradaki example.com yerine gerçek alan adınızı yazın. Çıktıdaki notAfter tarihi yeni son kullanma tarihidir; subject veya SAN alanlarının beklenen alan adını kapsadığını, issuer bilgisinin beklenen sertifika otoritesini gösterdiğini kontrol edin. Yeni dosyanın diskte güncellenmiş olması tek başına yeterli değildir; bu komut eski tarih gösteriyorsa yanlış sanal host, yanlış IP adresi, ters vekil veya reload edilmemiş bir web sunucusu olabilir.

Tarayıcıda kilit simgesinin görünmesi de yalnızca bağlantının şifreli olduğunu gösterir; tüm alan adlarının sertifikada bulunduğunu veya sunucuda otomatik yenilemenin yapılandırıldığını kanıtlamaz. Alan adı, sertifika zinciri ve son kullanma tarihi ayrıca doğrulanmalıdır.

Yenilemenin otomatik çalışmasını sağlama​


Certbot’un zamanlayıcısı veya cron görevi varsa, gerçek yenilemeyi beklemeden --dry-run ile düzenli olarak test edin. Yenileme sonrasında Nginx ya da Apache reload edilmiyorsa, sertifika dosyalarının değişmesinden sonra çalışan bir deploy hook tanımlayın. Hook içinde önce web sunucusunun yapılandırmasını test etmek, test başarısız olduğunda hatalı yapılandırmayı yayına almamak için önemlidir.

Son kontrol; sertifikanın doğru alan adını kapsaması, notAfter tarihinin güncellenmesi, özel anahtar ve sertifika eşleşmesi, ara sertifika zincirinin tamamlanması ve 443 numaralı portta yeni sertifikanın sunulmasıdır. Bu kontrollerden biri başarısızsa sertifikayı yeniden istemeden önce hangi aşamada kaldığını belirleyin: doğrulama başarısızsa DNS/HTTP erişimini, dosya güncellenmiş fakat dışarıda eski sertifika görünüyorsa web sunucusu reload’ını, TLS hatası oluşuyorsa sertifika-özel anahtar-zincir eşleşmesini inceleyin.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
Toplam: 1 (Üye: 0, misafir: 0, robot: 1)