Ubuntu 24.04 Apache Certbot Kurulumu ve Yapılandırması

Ne inşa ediyorsunuz

Ubuntu 24.04 üzerinde, tarayıcılar tarafından güvenilen ücretsiz bir Let's Encrypt sertifikası ile HTTPS üzerinden yanıt veren bir Apache sitesi. Sertifika Certbot tarafından düzenlenir ve bir daha düşünmenize gerek kalmayacak şekilde systemd zamanlayıcısı ile otomatik olarak yenilenir. İşi yapan komut tek satırdır. Ters giden her şey bu satırdan önce gerçekleşir: ServerName içermeyen bir vhost, sağlayıcı güvenlik duvarında kapalı olan 80 numaralı port veya hala eski sunucuyu işaret eden DNS kayıtları. Bu nedenle rehberin büyük bir kısmı ön koşullara ayrılmış olup, her hatanın oluşturduğu kesin hata dizeleri belirtilmiştir.

İki kapsam notu. Web sunucunuz nginx ise, süreç aynı yapıdadır ancak eklenti ve yapılandırmalar farklıdır; bunun yerine bu rehberin nginx sürümünü kullanın. Eğer güvenliğini sağladığınız şey yalnızca dahili kullanıma yönelikse, özel bir adresteki yönetici paneli veya kimsenin ziyaret etmediği bir test sunucusuysa, bir sertifika otoritesine ihtiyacınız yoktur; kendinden imzalı sertifika daha az işlem yükü gerektirir ve çevrimdışı çalışır.

Ön gereksinimler ve Certbot çalışmadan önce başarısızlığa yol açan üç durum

• Apache'nin sitenize halihazırda düz HTTP üzerinden hizmet veriyor olması. Certbot'un Apache eklentisi mevcut bir siteyi düzenler; yeni bir site oluşturmaz. Eğer boş bir VPS ile başlıyorsanız, önce Ubuntu 24.04 üzerinde LAMP yığını kurulumunu tamamlayıp geri dönün; bu rehber, o kurulumun eksik TLS bölümüdür.
• VPS adresinize tanımlı bir A kaydına sahip herkese açık bir alan adı. Let's Encrypt'in HTTP-01 doğrulaması, doğrulama sunucularının internet üzerinden sunucunuza bağlanması anlamına gelir: port yönlendirmesi olmayan NAT arkasındaki ev laboratuvarları, .local isimleri veya doğrudan IP adresleri kullanılamaz. dig +short example.com, VPS adresinizi döndürmelidir; eğer DNS ayarlarını son bir saat içinde değiştirdiyseniz, sertifika talebinde bulunmadan önce eski kaydın TTL süresinin dolmasını bekleyin.
• Eğer bir AAAA kaydı mevcutsa, bu kayıt doğru olmalıdır. Let's Encrypt, AAAA kaydı yayınlandığında IPv6'yı tercih eder; bu nedenle, dizüstü bilgisayarınızdan (muhtemelen IPv4 üzerinden) yaptığınız curl başarılı olsa bile, güncel olmayan bir AAAA kaydı doğrulamanın başarısız olmasına neden olur. Ya doğru bir AAAA kaydı yayınlayın ya da hiç yayınlamayın.

80 ve 443 numaralı portların hem ufw üzerinde hem de servis sağlayıcınızın ağ güvenlik duvarında açık olması gerekir; çoğu barındırma paneli, işletim sisteminin görmediği ikinci bir güvenlik duvarına sahiptir. HTTP-01 doğrulaması özellikle 80 numaralı port üzerinden yapılır; bu işlemi yalnızca 443 numaralı portu kullanarak gerçekleştiremezsiniz.

sudo ufw allow "Apache Full"
sudo ufw status

Bu gereksinimler sağlandığında tüm işlem on beş dakika sürer ve bunun on dakikası okumaya ayrılır.

Snap mi yoksa apt Certbot mu? 24.04 sürümünde apt nihayet sorunsuz

Certbot, dağıtım paketlerinin eskimesi nedeniyle yıllar önce snap dağıtımına geçti. Ubuntu 20.04, Certbot 0.40 sürümüyle geldi ve bir daha güncellenmedi; proje ekibi ise beş yıllık hataları ayıklamaktan yoruldu. 24.04 sürümünde bu neden ortadan kalktı; arşiv artık güncel bir sürüm olan Certbot 2.9.0'ı sunuyor ve unattended-upgrades bu paketi yamalı tutuyor. Bu işletim sistemi için önerim: apt kullanın. Böylece snapd daemon'ından kurtulur, Apache eklentisini aynı işlemle kurar ve yenileme zamanlayıcısını standart Debian yöntemiyle systemd'ye entegre edersiniz.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

Doğru sonuç: certbot 2.9.0. python3-certbot-apache paketi, Apache yapılandırmalarınızı okuyan ve düzenleyen eklentidir; bu paket olmadan certbot --apache, The requested apache plugin does not appear to be installed hatasıyla başarısız olur.

Snap kullanımı şu iki durumda hala doğru tercihtir: Certbot'un en yeni sürümünü çıktığı gün kullanmak istiyorsanız veya yalnızca snap olarak dağıtılan bir DNS eklentisine (bazı certbot-dns-* sağlayıcı eklentileri böyledir) ihtiyacınız varsa. Bu yolu seçerseniz:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Hangisini seçerseniz seçin, ikisini birden çalıştırmayın. İki kurulum, /etc/letsencrypt üzerinde hak iddia eden iki yenileme zamanlayıcısı anlamına gelir ve kabuğunuzun PATH içinde bulduğu certbot, sertifikalarınızın sahibi olan sürüm olmayabilir. Yukarıdaki apt remove satırı isteğe bağlı bir süsleme değildir.

Certbot vhost düzenlemeleri halihazırda mevcut olmalıdır, ServerName her şeydir

certbot --apache, geçirdiğiniz her -d alan adı ile eşleşen ServerName veya ServerAlias değerine sahip 80 numaralı port sanal ana bilgisayarını (virtual host) bularak, alan adı üzerindeki kontrolü bu yolla kanıtlayarak ve ardından bu vhost'un bir SSL ikizini yazarak çalışır. Eşleşen bir ServerName yoksa eşleşme sağlanamaz ve Ubuntu'nun varsayılan 000-default.conf dosyası, ServerName satırı yorum satırı yapılmış halde gelir. Bu tek yorum satırı, bu kılavuzdaki tek büyük komutun başarısız olmasının en yaygın nedenidir.

Bu nedenle Certbot'a dokunmadan önce siteye düzgün bir isme dayalı vhost verin. /etc/apache2/sites-available/example.com.conf dosyasını oluşturun:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

Bunu etkinleştirin ve Apache'nin hem dosyayı ayrıştırdığını hem de ismi buraya yönlendirdiğini doğrulayın:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest komutu Syntax OK çıktısını vermelidir. Eğer AH00558: apache2: Could not reliably determine the server's fully qualified domain name çıktısını da veriyorsa, bu vhost'unuzla ilgili değil global ServerName ile ilgili bir uyarıdır, burada zararsızdır ve echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 ile susturulabilir.

-S çıktısı, önemli olan kontroldür. Altında alias www.example.com bulunan port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) gibi bir satır görmelisiniz; Apache, sites-available içinde düzenlediğiniz dosyayı değil, aslında okuduğu sites-enabled sembolik bağlantısını rapor eder. Eğer example.com, 80 numaralı port karşısında listelenmiyorsa, Certbot da onu bulamayacaktır.

Sertifikayı düzenleyin: certbot --apache

sudo certbot --apache -d example.com -d www.example.com

İlk çalıştırma üç şey sorar: bir e-posta adresi (ACME hesabınız ve acil CA bildirimleri için kullanılır; Let's Encrypt artık süre sonu uyarıları göndermediğinden, yenilemeleri izlemek sizin sorumluluğunuzdadır), Let's Encrypt şartlarının kabul edilmesi ve e-posta adresinizin EFF ile paylaşılıp paylaşılmayacağı. Artık bir yönlendirme sorusu bulunmamaktadır: Certbot 2.0 sürümünden itibaren Apache yükleyicisi, HTTP trafiğini varsayılan olarak HTTPS'e yönlendirir; bu da istenen durumdur. İçerik sunmaya devam etmek için düz HTTP'ye kesinlikle ihtiyacınız varsa --no-redirect parametresini kullanın.

Başarılı işlem çıktısı aşağıdaki gibidir; bu çıktıyı göz gezdirmek yerine dikkatlice okumalısınız:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

Bu mesajın arka planında Certbot dört işlem gerçekleştirmiştir: henüz etkin değilse Apache'nin ssl modülünü etkinleştirmiş, *:443 üzerinde SSLEngine on ve sertifika yolları ile vhost dosyanızın bir kopyası olan example.com-le-ssl.conf dosyasını oluşturmuş, bu dosyayı etkinleştirmiş ve orijinal 80 numaralı port vhost dosyasına her şeyi HTTPS'e 301 ile yönlendiren bir RewriteRule bloğu eklemiştir. Orijinal vhost dosyanız değiştirilmemiş, düzenlenmiştir; SSL ikizi ise yanında yer alır ve eklenen her satırı inceleyebilirsiniz.

Sertifikanın gerçek konumu ve neden asla kopyalanmaması gerektiği

Her şey /etc/letsencrypt/live/example.com/ dizini altında toplanır: fullchain.pem (sertifika ve ara zincir; sunucuların işaret etmesi gereken dosya), privkey.pem (yalnızca root tarafından okunabilen özel anahtar) ve parçaları ayrı ayrı isteyen yazılımlar için cert.pem ile chain.pem. Bunlar /etc/letsencrypt/archive/ dizinine giden sembolik bağlardır (symlink) ve bu dolaylı yapı yenileme mekanizmasını oluşturur: yenileme işlemi archive/ dizinine yeni dosyalar yazar ve sembolik bağları günceller. Diğer tüm yazılımları live/ yollarına yönlendirirseniz, yenileme işlemlerinden otomatik olarak faydalanırlar; dosyaları başka bir yere kopyalarsanız, 90 gün sonra gerçekleşecek bir kesintiye davetiye çıkarmış olursunuz.

Bilinmesi gereken diğer önemli dosya /etc/letsencrypt/renewal/example.com.conf dosyasıdır; bu dosya sertifikanın nasıl düzenlendiğini, authenticator = apache, installer = apache bilgilerini ve alan adlarını kaydeder. Böylece yenileme işlemi, sonrasında Apache'nin yeniden yüklenmesi de dahil olmak üzere tüm süreci müdahale gerektirmeden tekrarlayabilir.

Yenileme zaten planlanmış durumda, doğrulayın, yeniden oluşturmayın

Let's Encrypt sertifikaları tasarım gereği 90 gün geçerlidir ve apt paketi gerekli mekanizmayı zaten kurmuştur: Certbot'u günde iki kez rastgele zamanlarda çalıştıran ve süresi dolmasına 30 gün kalan tüm sertifikaları yenileyen bir systemd zamanlayıcısı. Bunun üzerine ek bir cron işi eklemeyin; ikinci bir zamanlayıcı, log kirliliği ve hız sınırlaması (rate-limit) riskinden başka bir şey sağlamaz.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

İlk komut, zamanlayıcının aktif olduğunu ve NEXT zamanının önümüzdeki 24 saat içinde bir noktayı gösterdiğini doğrular. Zamanlama, rastgele bir gecikme ile günde iki kez olacak şekilde ayarlanmıştır, bu nedenle tam zaman kasıtlı olarak tahmin edilemezdir (snap kurulumunda zamanlayıcı snap.certbot.renew.timer şeklindedir). Kuru çalışma (dry run), Let's Encrypt'in hazırlık ortamında tam bir yenileme provası gerçekleştirir; gerçek bir doğrulama yapılır, sertifika düzenlenmez ve hız sınırlamasına takılmazsınız. Doğru sonuç şu ifadeyle biter:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Eğer kuru çalışma başarısız olursa, yaklaşık 60 gün sonra gerçekleşecek gerçek yenileme de aynı şekilde başarısız olacaktır; mevcut sertifikanın kullanım ömrü henüz dolmamışken sorunu şimdi giderin. En yaygın neden, sertifika düzenlendikten sonra eklenen ve 80 numaralı portu tekrar kapatan bir güvenlik duvarı kuralıdır.

curl ile doğrulama ve kilit simgesinin içeriği

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

İlk komut, Certbot tarafından yüklenen yönlendirme sayesinde HTTP/1.1 301 Moved Permanently durum kodu ve Location: https://example.com/ başlığı döndürmelidir. İkinci komut, curl tarafından herhangi bir TLS hatası alınmadan HTTP/1.1 200 OK döndürmelidir. Üçüncü komut ise sertifika sağlayıcısını, R12 veya E7 gibi kısa bir CN değerine sahip O = Let's Encrypt satırını ve yaklaşık 90 gün sonrasını gösteren notAfter tarihini yazdırır. Tarayıcıda kilit simgesi görünür ve üzerine tıklandığında aynı sağlayıcı bilgisi görüntülenir. Eğer curl ile işlem başarılı oluyor ancak tarayıcı uyarı veriyorsa, sorun büyük olasılıkla sertifika kaynaklı değil, önbelleğe alınmış bir sayfa veya yanlış ana bilgisayar adı (hostname) ile ilgilidir.

Birden fazla site: tek bir SAN sertifikası mı yoksa her site için ayrı sertifika mı?

Her iki yöntem de çalışır ve aynı şekilde yenilenir. Aynı sunucudaki birbiriyle ilişkisiz siteler için, her site için bir kez yayınlama komutunu çalıştırın; her biri live/ altında kendi dizinine ve kendi yenileme yapılandırmasına sahip olur. Böylece bir alan adındaki sorun, diğerlerinin yenilenmesini asla engellemez. Benim varsayılan tercihim budur.

Birden fazla isme sahip tek bir site için, bunları tek bir SAN sertifikası üzerinde toplayın; tek bir sertifika 100 isme kadar barındırabilir. Bunu yukarıda example.com ve www.example.com ile zaten yaptınız. Daha sonra mevcut bir sertifikaya yeni bir isim eklemek için, sertifikayı ve tam yeni listeyi belirterek yeniden yayınlama yapın:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot, değişen alan adı kümesini fark eder, genişletmeyi onaylamanızı ister ve sertifikayı yerinde değiştirir. Aynı live/ yolu kullanıldığı için başka hiçbir ayara dokunmanız gerekmez. Listenin bir ekleme değil, bir değiştirme işlemi olduğunu unutmayın: www ifadesini bu komuttan çıkarırsanız, yeni sertifika bu alan adını sessizce siler.

Wildcard sertifikalar DNS-01 gerektirir ve genellikle wildcard sertifikaya ihtiyaç duymazsınız

HTTP-01 yöntemi *.example.com düzenleyemez; bir web sunucusuna dosya yerleştirmek, tüm bir isim alanını değil, yalnızca tek bir ana bilgisayar adının kontrolünü kanıtlar. Wildcard sertifikalar DNS-01 doğrulaması gerektirir: Certbot, _acme-challenge.example.com üzerinde bir TXT kaydı oluşturur. Bu işlem pratikte, DNS sağlayıcınızın API kimlik bilgilerini içeren bir certbot-dns-* eklentisi kullanmanızı veya her yenileme döneminde --manual ile TXT kayıtlarını manuel olarak düzenlemenizi gerektirir (bu yöntem oldukça zahmetlidir, planlarınızı buna göre yapmayın). TXT kaydı mekaniklerinden, otomatik yenileme yapan bir eklentiye kadar tüm süreç Certbot ile DNS-01 üzerinden wildcard sertifikalar rehberinde yer almaktadır. Dürüst bir tavsiye: Eğer dört adet bilinen alt alan adınız varsa, hepsini listeleyen bir SAN sertifikası, wildcard sertifikadan daha basittir ve sunucuda DNS API anahtarları bulundurmanızı gerektirmez.

Hata modları ve karşılaşacağınız dizeler

Apache yapılandırması bozuk olduğu için Certbot başlamayı reddediyor.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

Eklenti, herhangi bir değişiklik yapmadan önce configtest komutunu çalıştırır ve Apache'nin kendisi sorunluysa işlemi durdurur. \n dizeleri, Certbot istisnanın repr çıktısını yazdırdığı için birebir yansıtılır. sudo apache2ctl configtest komutunu kendiniz çalıştırın: bu komut dosya adını ve satır numarasını belirtir. Bu genellikle elle düzenleme kaynaklı bir yazım hatası, artık var olmayan bir yola işaret eden bir SSLCertificateFile veya referans verilmiş ancak etkinleştirilmemiş bir modüldür. Çıktı Syntax OK olana kadar düzeltmeleri yapın ve ardından Certbot'u tekrar çalıştırın.

Etki alanı ile eşleşen bir vhost bulunamadı.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

Bu, daha önce bahsedilen eksik ServerName hatasıdır ve sertifika düzenleme aşamasında yakalanır. Certbot, etkinleştirilmiş tüm 80 numaralı port vhost'larını, -d değerinizle eşleşen bir ServerName/ServerAlias için tarar ve hiçbir şey bulamaz. sudo apache2ctl -S, Apache'nin gerçekte nereye yönlendirme yaptığını gösterir; doğru vhost dosyasına ServerName satırını ekleyin, yeniden yükleyin ve tekrar deneyin. Bunun benzer bir durumu, doğrulama isteğinin yanlış vhost'a ulaşmasıdır; başka bir site isteği yakaladığı için sınama yanıtı Invalid response ... 404 döner. Teşhis ve çözüm aracı aynıdır: apache2ctl -S.

Doğrulama zaman aşımına uğradı.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let's Encrypt, DNS'inizin belirttiği adresteki 80 numaralı porta TCP bağlantısı açamadı. Olasılık sırasına göre: sağlayıcınızın ağ güvenlik duvarı (ufw'den bağımsız, barındırma panelinden yapılandırılır), yalnızca 443 veya SSH'ye izin veren bir ufw kural kümesi, DNS'in hala eski bir sunucuya işaret etmesi veya IPv6'nın eski kalması (sunucuları IPv6 denedi, sizinki ise sadece IPv4 üzerinden yanıt veriyor). VPS'in dışından test edin: dizüstü bilgisayarınızdan curl -I http://example.com komutunu çalıştırmak, doğrulayıcılarının gördüğü durumu simüle eder.

Tekrar denemeleriniz nedeniyle hız sınırına takıldınız.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt, ana bilgisayar adı başına saatte 5 başarısız doğrulamaya izin verir. 2025 hız sınırı düzenlemesinden bu yana bu, dolan bir kova mantığıyla çalışır ve yaklaşık her 12 dakikada bir yeniden deneme hakkı kazandırır; bozuk bir güvenlik duvarına karşı sürekli deneme yapmak bu hakkı hızla tüketir. Beklemek bir çözümdür ancak asıl çözüm davranış değişikliğidir: herhangi bir hatadan sonra, başarılı olana kadar staging ortamı ile hata ayıklama yapın.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

certonly işaretine dikkat edin: --dry-run yalnızca certonly ve renew alt komutları tarafından kabul edilir; çıplak certbot --apache --dry-run formu ise çalışmayı reddederek size --dry-run currently only works with the 'certonly' or 'renew' subcommands mesajını verir. Dry run (deneme çalıştırması), kendi geniş sınırlarına sahip olan ve gerçek sertifika düzenlemeyen staging ortamına karşı doğrulama yapar; bu sayede tüm öğleden sonra hata yapabilirsiniz. Staging ortamında başarılı olduktan sonra gerçek komutu yalnızca bir kez çalıştırın. Haftada kayıtlı etki alanı başına 50 sertifika veya aynı ad kümesi için haftada 5 kopya gibi diğer sınırlar, yalnızca bir betik döngü içinde sertifika yeniliyorsa karşınıza çıkar.

HTTPS kurulduktan sonra, sertifikanın sunucuyu değil iletimi güvence altına aldığını unutmayın: 22 numaralı port tüm gün parola tahminlerine maruz kalmaya devam eder. Bunu Ubuntu 24.04 üzerinde Fail2ban ile eşleştirmek, atılacak en doğal sonraki otuz dakikalık adımdır.

FAQ

Ubuntu 24.04 üzerinde Apache için Certbot'u snap ile mi yoksa apt ile mi kurmalıyım?

apt kullanın. Ubuntu 24.04, bu kılavuzdaki her işlem için yeterince güncel olan Certbot 2.9.0 sürümünü sunar, güvenlik yamalarını unattended-upgrades aracılığıyla alır ve snapd gerektirmez. Yalnızca en yeni sürüme acilen ihtiyaç duyuyorsanız veya yalnızca snap olarak dağıtılan bir DNS eklentisi kullanmanız gerekiyorsa snap yöntemini seçin; eğer geçiş yaparsanız, iki yenileme zamanlayıcısının çakışmaması için önce apt remove certbot python3-certbot-apache komutunu çalıştırın.

Certbot neden "80 numaralı portu dinleyen bir sanal ana bilgisayar bulunamadı" hatası veriyor?

Çünkü etkinleştirilmiş hiçbir 80 numaralı port vhost'u, -d ile belirttiğiniz alan adıyla eşleşen bir ServerName veya ServerAlias değerine sahip değildir; Ubuntu'nun varsayılan vhost'u ServerName satırı yorum satırı yapılmış halde gelir. sudo apache2ctl -S komutunu çalıştırın, ilgili alan adını yönetmesi gereken vhost'u bulun (veya oluşturun), ServerName example.com satırını ekleyin, Apache'yi yeniden yükleyin ve Certbot'u tekrar çalıştırın.

"Bağlantı sırasında zaman aşımı (muhtemelen güvenlik duvarı sorunu)" hatasını nasıl düzeltirim?

Let's Encrypt, DNS kayıtlarınızda yayınlanan adreste 80 numaralı porta ulaşamadı. Sağlayıcınızın panel düzeyindeki ağ güvenlik duvarını ve ufw ayarlarını kontrol edin, dig +short example.com komutunun bu VPS'i döndürdüğünden emin olun ve eski AAAA kayıtlarını silin veya düzeltin; doğrulama işlemi, IPv6 mevcut olduğunda onu tercih eder. Düzeltmeyi sunucu dışından curl -I http://example.com ile doğrulayın ve gerçek sertifika alımından önce sudo certbot certonly --apache --dry-run -d example.com ile deneme yapın.

Certbot, Ubuntu 24.04 üzerinde sertifikaları otomatik olarak yeniler mi?

Evet. apt paketi, günde iki kez çalışan ve süresinin dolmasına 30 gün kalan tüm sertifikaları yenileyip ardından Apache'yi yeniden başlatan bir systemd zamanlayıcısı olan certbot.timer servisini kurar; snap sürümü ise aynı iş için snap.certbot.renew.timer kullanır. systemctl list-timers certbot.timer ile durumu doğrulayın ve sudo certbot renew --dry-run ile deneme yapın; üzerine kendi cron işinizi eklemeyin.

Certbot ve Apache ile nasıl wildcard sertifikası alabilirim?

Wildcard sertifikaları DNS-01 doğrulamasını gerektirir: Certbot'un _acme-challenge.example.com adresinde bir TXT kaydı oluşturması gerekir, bu da DNS sağlayıcınız için API kimlik bilgilerine sahip bir certbot-dns-* eklentisi gerektirir (--manual alternatifi, her yenilemede TXT kayıtlarının elle düzenlenmesini gerektirir). Eğer yalnızca birkaç adet bilinen alt alan adınız varsa, bunları açıkça listeleyen bir SAN sertifikası daha basittir ve DNS API anahtarlarının sunucuda tutulmasını gerektirmez.