SSD Nodes Learn Hosting plans →
Rehberler Matt ConnorYazan Matt Connor

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

Ubuntu 24.04 üzerinde apt ile Certbot 2.9.0 kurulumunu öğrenin. Let's Encrypt sertifika hatalarını önlemek için kritik ServerName yapılandırmasını ve çözüm yollarını inceleyin.

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 koşullar 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ın ve ardından buraya dönün; bu kılavuz, 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ı veya .local isimleri bu işlem için uygun değildir. HTTP-01 çıplak bir IP adresini doğrulayabilir ancak Let's Encrypt, IP sertifikalarını yalnızca isteğe bağlı shortlived profilinde (160 saatlik geçerlilik süresi ile) düzenler. apt üzerindeki Certbot 2.9.0 ise ne ACME profillerini ne de IP adreslerini talep edebilir; bu nedenle bu kılavuz bir alan adı gerektirir. 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.
  • AAAA kaydı mevcutsa, doğru olmalıdır. Let's Encrypt, bir AAAA kaydı yayınlandığında her zaman önce IPv6 üzerinden bağlantı kurmayı dener. Eğer bu bağlantı zaman aşımına uğrarsa IPv4 üzerinden tekrar dener; ancak başka hiçbir hata türü bu ikinci şansı alamaz. Dizüstü bilgisayarınızdan (muhtemelen IPv4 üzerinden) yaptığınız curl başarılı olsa bile, bağlantıları reddeden veya bu sunucuya ait olmayan bir adresteki 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 koşullar sağlandığında tüm işlem on beş dakika sürer; bunun on dakikası okumaya ayrılmıştı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 bu sürüm hiç güncellenmedi; proje ekibi beş yıllık hataları ayıklamaktan yoruldu. 24.04 sürümünde bu sorun ortadan kalktı; arşiv, modern 2.x serisinden Şubat 2024 çıkışlı Certbot 2.9.0 sürümünü sunuyor ve unattended-upgrades, Ubuntu'nun yayınladığı tüm güvenlik güncellemelerini yüklüyor. Upstream tarafı 5.x serisine geçiş yapmış olsa da, bu kılavuzdaki hiçbir işlem için bu sürüme ihtiyaç duyulmamaktadır. Bu işletim sistemi için önerim: apt kullanın. Böylece snapd daemon'dan 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 en doğru tercihtir: Certbot'un en güncel 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 asla çalıştırmayın. İki kurulum, /etc/letsencrypt üzerinde hak iddia eden iki yenileme zamanlayıcısı anlamına gelir ve shell'inizin PATH içinde bulduğu certbot, sertifikalarınızın sahibi 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 (Let's Encrypt artık bunu ACME hesabınızla saklamaz ve son kullanma uyarıları göndermez, bu nedenle 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 1.0 sürümünden bu yana Apache yükleyicisi HTTP trafiğini varsayılan olarak HTTPS'e yönlendirir (sorunun kendisi 1.4 sürümünde kaldırılmıştır), bu da istenen davranıştır. İçeriği düz HTTP üzerinden sunmaya devam etmeniz gerekiyorsa --no-redirect bayrağını 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 2027-01-09.

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: Apache'nin ssl modülünü etkin değilse etkinleştirmiş, *:443 üzerinde SSLEngine on ve sertifika yolları ile birlikte 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 oluşturulmuş olup eklenen her satırı incelemenize olanak tanır.

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 şu anda 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üresinin dolmasına 30 gün kalan tüm sertifikaları yenileyen bir systemd zamanlayıcısı. Bunun üzerine bir cron işi eklemeyin; ikinci bir zamanlayıcı, log kirliliği ve hız sınırı (rate-limit) riskinden başka bir şey sağlamaz. Let's Encrypt, 10 Şubat 2027 tarihinden itibaren yeni sertifikaların varsayılan olarak 64 günlük ömre sahip olacağını duyurmuştur. 30 günlük pencere bu sertifikalarla da çalışmaya devam eder, yenileme işlemi 60. gün yerine 34. gün civarında gerçekleşir, bu nedenle sunucuda herhangi bir değişiklik yapılmasına gerek yoktur.

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 noktada olduğunu gösterir; zamanlama rastgele bir gecikme ile günde iki kez olacak şekildedir, bu nedenle tam zaman kasıtlı olarak tahmin edilemezdir (snap kurulumunda zamanlayıcı bunun yerine snap.certbot.renew.timer şeklindedir). Kuru çalışma (dry run), Let's Encrypt'in hazırlık ortamına karşı tam bir yenileme provası gerçekleştirir; gerçek sınama yapılır, sertifika düzenlenmez ve hız sınırı maliyeti oluşmaz. 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 sonraki 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. Yaygın karşılaşılan sorun, 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önlendirmeyi temsil eden bir Location: https://example.com/ başlığı ile birlikte HTTP/1.1 301 Moved Permanently döndürmelidir. İkinci komut, curl tarafından herhangi bir TLS hatası alınmaksızın HTTP/1.1 200 OK döndürmelidir. Üçüncü komut ise sertifika vereni, YE1 veya YE2 (ECDSA anahtarları için) ya da YR1 veya YR2 (RSA anahtarları için) gibi kısa bir CN değerine sahip bir O = Let's Encrypt satırını ve yaklaşık 90 gün sonrasını işaret eden bir notAfter değerini yazdırır. Let's Encrypt eski ara sertifikalarını kullanımdan kaldırmadan önce oluşturulan bir sertifika, bir sonraki yenilemeye kadar R12 veya E7 gibi bir CN değeri gösterebilir; bu bir hata değildir. Tarayıcıda kilit simgesi görünür ve üzerine tıklandığında aynı sertifika veren bilgisi görüntülenir. Eğer curl komutu çalışıyor ancak tarayıcı uyarı veriyorsa, sorun büyük olasılıkla sertifika ile ilgili 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şlatılamıyor.

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 işlem yapmadan önce configtest komutunu çalıştırır ve Apache'nin durumu düzgün değilse işlemi durdurur. \n dizeleri gerçektir çünkü Certbot, istisnanın repr çıktısını yazdırır. sudo apache2ctl configtest komutunu kendiniz çalıştırın: bu komut, genellikle elle düzenleme kaynaklı bir yazım hatasını, artık var olmayan bir yola işaret eden bir SSLCertificateFile ifadesini veya referans verilmiş ancak etkinleştirilmemiş bir modülü belirterek dosya ve satır numarasını gösterir. Çıktı Syntax OK olana kadar düzeltmeleri yapın ve ardından Certbot'u tekrar çalıştırın.

Alan adı 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 trafiği gerçekte nereye yönlendirdiğini gösterir; ilgili vhost dosyasına ServerName satırını ekleyin, yeniden yükleyin ve tekrar deneyin. Bunun benzer bir durumu, doğrulama işleminin yanlış vhost'a ulaşmasıdır; başka bir site isteği yakaladığı için sınama yanıtı Invalid response ... 404 olarak döner. Teşhis aynıdır, araç 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 kayıtlarınızda belirttiğiniz 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, hosting panelinden yapılandırılır), yalnızca 443 veya SSH trafiğine izin veren bir ufw kural kümesi ya da DNS'in hala eski bir sunucuya işaret etmesi. Yalnızca eski bir AAAA kaydı genellikle buna neden olmaz; çünkü IPv6 denemesi zaman aşımına uğradığında Let's Encrypt IPv4 üzerinden tekrar dener. AAAA sorunları genellikle yanlış sunucudan gelen bir Connection refused veya Invalid response hatası olarak ortaya çıkar. VPS'in dışından test edin: dizüstü bilgisayarınızdan çalıştıracağınız curl -I http://example.com komutu, doğrulayıcının gördüğü durumu simüle eder.

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

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let's Encrypt, hesap başına ve alan adı başına saatte 5 başarısız doğrulamaya izin verir. Bu, yaklaşık her 12 dakikada bir yeniden dolan bir kova gibidir; bozuk bir güvenlik duvarına karşı sürekli tekrar 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 başarısızlıktan 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 ifadesine dikkat edin: --dry-run yalnızca certonly ve renew alt komutları tarafından kabul edilir; çıplak certbot --apache --dry-run formu ise --dry-run currently only works with the 'certonly' or 'renew' subcommands uyarısını vererek çalışmayı reddeder. Dry run (kuru çalışma), kendi geniş limitlerine sahip olan ve gerçek sertifika düzenlemeyen staging ortamında doğrulama yapar; bu sayede tüm öğleden sonrayı hata ayıklayarak geçirebilirsiniz. Gerçek komutu yalnızca staging aşaması geçildikten sonra çalıştırın. Kayıtlı alan adı başına haftada 50 sertifika veya aynı isim kümesi için haftada 5 kopya gibi diğer limitlere, yalnızca bir betik döngü içinde sürekli sertifika yeniliyorsa ulaşırsınız.

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 denemelerine maruz kalmaya devam eder. Bunu Ubuntu 24.04 üzerinde Fail2ban ile eşleştirmek, yapılması gereken bir sonraki mantıklı adımdır.

FAQ

Ubuntu 24.04 üzerinde Apache için Certbot kurulumunu snap ile mi yoksa apt ile mi yapmalı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, Ubuntu'nun unattended-upgrades aracılığıyla yayınladığı tüm güvenlik güncellemelerini alır ve snapd gerektirmez. Yalnızca en yeni sürüme hemen 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 aynı anda çalış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 yapılandırması, -d ile belirttiğiniz alan adıyla eşleşen bir ServerName veya ServerAlias değerine sahip değildir; Ubuntu'nun varsayılan vhost yapılandırması ServerName satırı yorum satırı yapılmış halde gelir. sudo apache2ctl -S komutunu çalıştırın, ilgili alan adını sahiplenmesi gereken vhost dosyasını bulun (veya oluşturun), ServerName example.com değerini 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ızın yayınladığı adresteki 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üğünü doğrulayın ve eski AAAA kayıtlarını düzeltin veya silin; çünkü doğrulama süreci önce IPv6'yı dener ve ancak zaman aşımından sonra IPv4'e geri döner. Düzeltmeyi sunucu dışından curl -I http://example.com ile doğrulayın, ardından 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 yükleyen bir systemd zamanlayıcısı olan certbot.timer aracını kurar; snap sürümü ise aynı işlem için snap.certbot.renew.timer kullanır. systemctl list-timers certbot.timer ile doğrulama yapın ve sudo certbot renew --dry-run ile deneme çalıştırın; üzerine kendi cron işinizi eklemeyin.

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

Wildcard sertifikaları DNS-01 sınamasını gerektirir: Certbot'un _acme-challenge.example.com adresine bir TXT kaydı yerleştirmesi gerekir; bu da DNS sağlayıcınız için API kimlik bilgilerine sahip bir certbot-dns-* eklentisi gerektirir (--manual alternatifi, her yenileme sırasında TXT kayıtlarının elle düzenlenmesini gerektirir). Eğer yalnızca birkaç bilinen alt alan adınız varsa, bunları açıkça listeleyen bir SAN sertifikası daha basittir ve DNS API anahtarlarını sunucuda tutmanıza gerek kalmaz.