התקנת Certbot ב-Apache על Ubuntu 24.04

מה אתם בונים

אתר Apache על Ubuntu 24.04 המגיב ב-HTTPS עם תעודה חינמית מ-Let's Encrypt המוכרת על ידי הדפדפן. התעודה מונפקת על ידי Certbot ומחויה באופן אוטומטי באמצעות systemd timer שלא תצטרכו לנהל שוב. הפקודה המבצעת את העבודה היא שורה אחת בלבד. כל מה שעלול להשתבש, ישתבש לפני השורה הזו: vhost ללא ServerName, פורט 80 חסום ב-firewall של הספק, או DNS שעדיין מפנה לשרת הישן. לכן, מדריך זה מקדיש את רוב הזמן לתנאים המוקדמים, ומציין את מחרוזת השגיאה המדויקת שכל טעות מציגה.

שתי הערות היקפיות. אם שרת ה-web שלכם הוא nginx, התהליך דומה אך התוסף וההגדרות שונים — השתמשו ב-גרסת nginx למדריך זה במקום. ואם מה שאתם מאבטחים הוא פנימי בלבד — כגון לוח בקרה (admin panel) בכתובת פרטית, או שרת staging שאף אחד אחר לא מבקר בו — אינכם זקוקים לרשות אישורים (certificate authority) כלל; תעודה חתומה עצמית (self-signed certificate) דורשת פחות תשתית ועובדת ללא חיבור לאינטרנט.

Prerequisites, and the three ways this fails before Certbot even runs

• Apache already serving your site over plain HTTP. תוסף ה-Apache של Certbot עורך את אתר קיים; הוא אינו יוצר אתר חדש. אם אתם מתחילים מ-VPS ריק, התקינו תחילה את ה-LAMP stack on Ubuntu 24.04 וחזרו מדריך זה הוא הפרק החסר עבור TLS.
• A public domain with an A record at your VPS address. פרוטוקול ה-HTTP-01 challenge של Let's Encrypt דורש ששרתי האימות שלהם יתחברו למחשב שלכם דרך האינטרנט: לא ניתן להשתמש ב-homelab עם NAT ללא הפניית פורט (port forward), ללא שמות .local, וללא כתובות IP בלבד. dig +short example.com חייב להחזיר את כתובת ה-VPS שלכם, ואם שיניתם את ה-DNS בשעה האחרונה, המתינו לסיום ה-TTL של הרשומה הישנה לפני הנפקת התעודה.
• If an AAAA record exists, it must be correct. Let's Encrypt מעדיפים IPv6 כאשר קיימת רשומת AAAA. רשומת AAAA לא מעודכנת תגרום לכשל באימות, גם אם curl מהמחשב האישי שלכם — כנראה באמצעות IPv4 — עובד כראוי. פרסמו רשומת AAAA תקינה או אל תפרסמו רשומה כזו בכלל.

פורטים 80 וגם 443 חייבים להיות פתוחים ב-ufw וב-firewall של ספק השירות שלכם — לרוב ללוחות בקרה של אירוח יש firewall נוסף ש-OS אינו רואה. HTTP-01 מבצע אימות דרך פורט 80 בלבד; לא ניתן להריץ תהליך זה בפורט 443 בלבד.

sudo ufw allow "Apache Full"
sudo ufw status

לאחר שהתנאים הללו מוגדרים, כל התהליך לוקח 15 דקות, ועשר דקות מתוכן הן קריאה.

Snap או apt Certbot? בגרסה 24.04, apt סוף סוף מתאים

Certbot עבר להפצה באמצעות snap לפני שנים מסיבה מוצדקת: חבילות ההפצה (distro packages) הפכו למיושנות. גרסת Ubuntu 20.04 הגיעה עם Certbot 0.40 ולא התעדכנה, והפרויקט נמאס לו לתקן באגים בני חמש שנים. בגרסה 24.04 הסיבה הזו אינה קיימת יותר — המאגר מספק את Certbot 2.9.0, גרסה עדכנית, ו-unattended-upgrades שומרת עליו מעודכן. ההמלצה שלי עבור מערכת הפעלה זו: השתמש ב-apt. כך תוכל לוותר על ה-daemon של snapd, תוסף ה-Apache יותקן באותה פעולה, וטיימר החידוש (renewal timer) ישתלב עם systemd בשיטת Debian הרגילה.

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

תוצאה נכונה: certbot 2.9.0. החבילה python3-certbot-apache היא התוסף שקורא ועורך את קובצי ההגדרות של Apache — ללא התוסף, certbot --apache ייכשל עם The requested apache plugin does not appear to be installed.

שימוש ב-snap עדיין נכון בשני מקרים: אם ברצונך להשתמש בגרסת Certbot החדשה ביותר ברגע שיצאה, או אם דרוש לך תוסף DNS שמופץ אך ורק כ-snap (כמה מהתוספים של certbot-dns-* מופצים כך). אם תבחר בדרך זו:

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

לא משנה באיזו דרך תבחר, לעולם אל תריץ את שתיהן. שתי התקנות פירושן שני מנגנוני תזמון לחידוש שיתנוף על /etc/letsencrypt, וה-certbot שה-shell שלך ימצא ב-PATH עשוי שלא להיות זה שמנהל את התעודות שלך. השורה apt remove לעיל אינה קישוט אופציונלי.

עריכות ה-vhost של Certbot חייבות להיות קיימות — ServerName הוא המפתח

certbot --apache פועל על ידי מציאת ה-virtual host ב-port-80 שבו ה-ServerName או ה-ServerAlias תואמים לכל -d domain שמועבר לפקודה. פעולה זו מוכיחה שליטה בדומיין דרכו, ולאחר מכן Certbot כותב SSL twin עבור אותו vhost. אם אין התאמה ל-ServerName, לא תהיה התאמה — ובגרסת ברירת המחדל של Ubuntu, ה-000-default.conf מגיע עם ה-ServerName בהערה (commented out). שורת ההערה הזו היא הסיבה הנפוצה ביותר לכך שהפקודה המרכזית במדריך זה נכשלת.

לכן, לפני השימוש ב-Certbot, הגדר לאתר vhost מבוסס-שם תקין. צור את /etc/apache2/sites-available/example.com.conf:

<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>

אפשר אותו וודא ש-Apache מנתח אותו ומנתב את השם אליו:

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

הפקודה configtest חייבת להדפיס את Syntax OK. אם היא מדפיסה גם את AH00558: apache2: Could not reliably determine the server's fully qualified domain name, זוהי אזהרה לגבי ה-ServerName ה-global, ולא לגבי ה-vhost שלך — זהו אירוע שאינו מזיק ומושתק על ידי echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

הפלט של -S הוא הבדיקה החשובה. עליך לחפש שורה כמו port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) עם alias www.example.com מתחתיה — Apache מדווח על ה-sites-enabled symlink שהוא קרא בפועל, ולא על הקובץ שעצבת ב-sites-available. אם example.com לא מופיע תחת port 80, Certbot גם הוא לא ימצא אותו.

Issue the certificate: certbot --apache

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

ההרצה הראשונה מבקשת שלושה דברים: כתובת email (משמשת עבור חשבון ה-ACME שלך והודעות דחופות מה-CA; Let's Encrypt כבר לא שולחת אזהרות על תפוגת תעודה, לכן האחריות על ניטור חידושים היא עליך), הסכמה לתנאי השימוש של Let's Encrypt, והאם לשתף את כתובת ה-email שלך עם ה-EFF. אין יותר שאלה לגבי הפניה (redirect): החל מגרסה Certbot 2.0, מתקין ה-Apache מבצע הפניה מ-HTTP ל-HTTPS כברירת מחדל, וזהו המצב הרצוי. השתמש ב---no-redirect אם יש צורך אמיתי ב-HTTP רגיל להמשך שירות התוכן.

מצב הצלחה נראה כך, ועליך לקרוא את ההודעה ולא רק לעבור עליה:

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

מאחורי ההודעה הזו, Certbot ביצע ארבע פעולות: הפעיל את מודול ה-ssl של Apache אם לא היה פעיל, כתב את example.com-le-ssl.conf — עותק של ה-vhost שלך ב-*:443 עם SSLEngine on ונתיבי התעודה — הפעיל אותו, והוסיף בלוק RewriteRule ל-vhost המקורי בפורט 80 שמבצע 301s לכל התעבורה ל-HTTPS. קובץ ה-vhost המקורי שלך נערך ולא מוחלף, וקובץ ה-SSL המקביל נמצא לצדו, כך שניתן לקרוא כל שורה שהוא הוסיף.

היכן התעודה מאוחסנת בפועל, ומדוע לעולם אין להעתיק אותה

כל הקבצים נמצאים תחת /etc/letsencrypt/live/example.com/: privkey.pem (התעודה כולל שרשרת הביניים — מה שהשרתים צריכים להצביע אליו), fullchain.pem (המפתח הפרטי, נגיש ל-root בלבד), בנוסף ל-cert.pem ו-chain.pem עבור תוכנות הזקוקות לקבצים בנפרד. אלו הם symlinks לתוך /etc/letsencrypt/archive/, והעקיפה הזו היא מנגנון החידוש: תהליך החידוש כותב קבצים חדשים לתוך archive/ ומעדכן את ה-symlinks. אם תכוון תוכנה אחרת לנתיבי live/, היא תקבל את החידושים באופן אוטומטי; אם תעתיק את הקבצים למקום אחר, תצור לעצמך הפסקת שירות בעוד 90 יום.

הקובץ הנוסף שחשוב להכיר הוא /etc/letsencrypt/renewal/example.com.conf, המתעד כיצד הונפקה התעודה — authenticator = apache, installer = apache, והדומיינים — כך שניתן יהיה לחזור על התהליך ללא התערבות ידנית, כולל טעינה מחדש של Apache לאחר מכן.

Renewal is already scheduled — verify it, do not build it

תעודות Let's Encrypt תקפות ל-90 יום על פי התכנון, וחבילת ה-apt כבר התקינה את המנגנון הנדרש: timer של systemd שמריץ את Certbot פעמיים ביום בזמנים אקראיים, ומחדש כל תעודה שנותרה לה פחות מ-30 יום לפקיעה. אל תוסיפו cron job נוסף; מתזמן שני יוסיף רעש ביומני המערכת (logs) ויחשוף אתכם למגבלות קצב (rate-limits).

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

הפקודה הראשונה מציגה את ה-timer הפעיל, עם זמן NEXT בטווח של 24 השעות הקרובות — לוח הזמנים הוא פעמיים ביום עם השהיה אקראית, לכן הזמן המדויק אינו צפוי במכוון (בהתקנת snap, ה-timer הוא snap.certbot.renew.timer במקום). הרצת ה-dry run מבצעת הרצה יזומה של תהליך החידוש מול סביבת ה-staging של Let's Encrypt — כולל challenge אמיתי, ללא הנפקת תעודה וללא צריכת מכסות rate-limit. תוצאה תקינה מסתיימת ב:

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

אם ה-dry run נכשל, גם החידוש האמיתי בעוד כ-60 יום ייכשל באותו אופן — תקנו זאת כעת, כל עוד לתעודה הנוכחית יש עדיין זמן صلاحות מלא. הגורם השכיח לכך הוא כלל firewall שנוסף לאחר הנפקת התעודה וסגר מחדש את port 80.

Verify with curl, and what the padlock should say

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

הבדיקה הראשונה צריכה להחזיר את HTTP/1.1 301 Moved Permanently עם header מסוג Location: https://example.com/ — זהו ה-redirect שהתקין Certbot. הבדיקה השנייה צריכה להחזיר את HTTP/1.1 200 OK ללא שגיאת TLS מ-curl. הבדיקה השלישית תציג את המנפיק — שורה מסוג O = Let's Encrypt עם CN קצר כמו R12 או E7 — ותאריך תפוגה של notAfter בערך 90 יום מהיום. בדפדפן תופיע סמל המנעול, ולחיצה עליו תציג את אותו המנפיק. אם curl עובד אך הדפדפן מציג אזהרה, רוב הסיכויים שמדובר בדף שמור ב-cache או בשם מארח (hostname) שגוי, ולא בבעיית תעודה.

מספר אתרים: תעודת SAN אחת או תעודה נפרדת לכל אתר

שתי האפשרויות עובדות; תהליך החידוש זהה בשניהם. עבור אתרים שאינם קשורים באותו שרת, יש להריץ את הפקודה פעם אחת עבור כל אתר — לכל אתר יהיה ספרייה משלו תחת live/ וקובץ הגדרות חידוש משלו. תקלה בדומיין אחד לא תמנע את החידוש של הדומיינים האחרים. זוהי ברירת המחדל שלי.

עבור אתר אחד עם מספר שמות, ניתן להשתמש בתעודת SAN אחת — תעודה בודדת יכולה להכיל עד 100 שמות. כבר ביצעת זאת לעיל עם example.com ו-www.example.com. כדי להוסיף שם לתעודה קיימת מאוחר יותר, יש להנפיק מחדש את התעודה תוך ציון רשימת השמות המלאה:

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

Certbot מזהה את שינוי קבוצת הדומיינים, מבקש ממך לאשר את ההרחבה, ומחליף את התעודה במקומה — באותו נתיב live/, כך שאין צורך לשנות דבר אחר. שים לב שהרשימה היא רשימת החלפה ולא רשימת תוספת: אם תשמיט את www מהפקודה, הדומיין יוסר מהתעודה החדשה ללא הודעה.

Wildcards require DNS-01, and usually you do not need a wildcard

HTTP-01 cannot issue *.example.com — placing a file on a web server proves control of one hostname, not a whole namespace. Wildcards require the DNS-01 challenge: Certbot sets a TXT record at _acme-challenge.example.com, which in practice means a certbot-dns-* plugin with API credentials for your DNS provider, or hand-editing TXT records at every renewal with --manual (miserable — do not plan around it). The full walkthrough, from the TXT record mechanics to a plugin that renews unattended, is in wildcard certificates with Certbot over DNS-01. Honest advice: if you have four known subdomains, a SAN certificate listing all four is simpler than a wildcard and needs no DNS API keys sitting on the server.

Failure modes, with the strings you will see

Certbot refuses to start because Apache's config is broken.

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')

ה-plugin מריץ את configtest לפני כל פעולה אחרת ונכשל אם Apache אינו תקין — ה-\ns הם טקסט מדויק כיוון ש-Certbot מדפיס את ה-repr של ה-exception. הרץ את sudo apache2ctl configtest בעצמך: הוא מציין את שם הקובץ והשורה — בדרך כלל בשל טעות הקלדה בעריכה ידנית, SSLCertificateFile המצביע על נתיב שכבר לא קיים, או מודול שמוזכר אך אינו מופעל. תקן את הקובץ עד שיופיע Syntax OK, ולאחר מכן הרץ מחדש את Certbot.

No vhost matches the domain.

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

זהו כשל ה-missing-ServerName מהשלב הקודם, שנתפס בזמן ההנפקה. Certbot חיפש בכל ה-vhost הפעילים ב-port-80 עבור ServerName/ServerAlias התואם ל--d שלך ולא מצא דבר. sudo apache2ctl -S מציג את הניתוב בפועל של Apache; הוסף את שורת ה-ServerName ל-vhost הנכון, בצע reload, ונסה שוב. מקרה דומה הוא אימות (validation) שמגיע ל-vhost הלא נכון — ה-challenge response חוזר כ-Invalid response ... 404 מכיוון שאתר אחר לכד את הבקשה. אותו אבחון ואותו כלי: apache2ctl -S.

Validation times out.

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

Let's Encrypt לא הצליחה לפתוח TCP connection ל-port 80 בכתובת שה-DNS שלך מפרסם. לפי סדר ההסתברות: ה-network firewall של ספק האחסון (נפרד מ-ufw, מוגדר ב-hosting panel), סט חוקי ufw המאפשר רק 443 או רק SSH, DNS שעדיין מצביע לשרת קודם, או בעיית stale-AAAA — השרתים שלהם ניסו IPv6, אך השרת שלך מגיב רק ב-IPv4. בדוק ממחוץ ל-VPS: הרצת curl -I http://example.com מהמחשב האישי תשחזר את מה שה-validator שלהם רואה.

You retried your way into a rate limit.

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

Let's Encrypt מאפשרת 5 כשלים ב-validation לכל hostname לכל account בכל שעה — מאז עדכון ה-rate-limit של 2025, מדובר ב-"bucket" המתמלא מחדש, המקנה כחצי ניסיון מחדש כל 12 דקות — וניסיונות חוזרים מרובים מול firewall תקוע יכלו להוציא את המכסה במהירות. המתנה תעזור, אך הפתרון האמיתי הוא שינוי התנהגות: לאחר כל כשל, בצע debug באמצעות ה-staging environment עד להצלחה.

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

שים לב ל-certonly: --dry-run מתקבל רק על ידי ה-subcommands של certonly ו-renew, והצורה certbot --apache --dry-run בלבד תסרב להריץ ותציג לך את --dry-run currently only works with the 'certonly' or 'renew' subcommands. ה-dry run מבצע אימות מול staging, שיש לו מגבלות נדיבות משלו ואינו מנפיק תעודות אמיתיות, לכן ניתן להיכשל שם לאורך כל אחר הצהריים. הרץ את הפקודה האמיתית רק לאחר ש-staging עבר בהצלחה. המגבלות האחרות — 50 תעודות לכל registered domain בשבוע, 5 כפילויות של אותו set שמות בשבוע — יקרו רק אם סקריפט מנפיק מחדש בלולאה.

לאחר ש-HTTPS פעיל, זכור שהתעודה מאבטחת את ה-transport בלבד, לא את השרת: port 22 עדיין מקבל ניסיונות ניחוש סיסמה לאורך כל היום. שילוב זה עם Fail2ban on Ubuntu 24.04 הוא הצעד הבא המתבקש.

FAQ

האם עלי להתקין את Certbot באמצעות snap או apt עבור Apache ב-Ubuntu 24.04?

השתמש ב-apt. גרסת Certbot ב-Ubuntu 24.04 היא 2.9.0, שהיא עדכנית מספיק עבור כל מה שמופיע במדריך זה, מקבלת עדכוני אבטחה דרך unattended-upgrades, ואינה דורשת את snapd. בחר ב-snap רק אם דרושה לך הגרסה החדשה ביותר באופן מיידי או אם דרוש תוסף DNS המופץ אך ורק כ-snap — ואם תבחר לעבור, בצע את apt remove certbot python3-certbot-apache תחילה כדי למנוע מצב שבו שני מנגנוני חידוש פועלים במקביל.

מדוע Certbot מציג את השגיאה "Unable to find a virtual host listening on port 80"?

הסיבה היא שאין vhost פעיל בפורט 80 עם ServerName או ServerAlias התואם לדומיין שהעברת עם -d — ה-vhost الافتراضي של Ubuntu מגיע עם ServerName בהערה (commented out). הרץ את sudo apache2ctl -S, מצא (או צור) את ה-vhost שאמור להחזיק בשם, הוסף את ServerName example.com, בצע reload ל-Apache, והרץ מחדש את Certbot.

כיצד פותרים את השגיאה "Timeout during connect (likely firewall problem)"?

Let's Encrypt לא הצליחה להגיע לפורט 80 בכתובת שפורסמה ב-DNS שלך. בדוק את חומת האש ברמת הפאנל של ספק השירות וגם את ufw, וודא ש-dig +short example.com מחזיר את ה-VPS הזה, ומחק או תקן כל רשומת AAAA ישנה — תהליך האימות מעדיף IPv6 כאשר רשומה קיימת. וודא שהתיקון עובד מחוץ לשרת באמצעות curl -I http://example.com, ולאחר מכן בצע תרגול עם sudo certbot certonly --apache --dry-run -d example.com לפני הנפקת התעודה בפועל.

האם Certbot מחדש תעודות באופן אוטומטי ב-Ubuntu 24.04?

כן. חבילת ה-apt מתקינה את certbot.timer, timer של systemd הפועל פעמיים ביום ומחדש כל תעודה שנשארה פחות מ-30 יום לפקיעת תוקפה, ולאחר מכן מבצע reload ל-Apache; גרסת ה-snap משתמשת ב-snap.certbot.renew.timer עבור אותה מטרה. ניתן לוודא זאת באמצעות systemctl list-timers certbot.timer ולתרגל באמצעות sudo certbot renew --dry-run — אין צורך להוסיף משימת cron משלך.

כיצד מקבלים תעודת wildcard באמצעות Certbot ו-Apache?

תעודות wildcard דורשות את אתגר DNS-01: Certbot חייב להציב רשומת TXT ב-_acme-challenge.example.com, מה שדורש תוסף certbot-dns-* עם פרטי API עבור ספק ה-DNS שלך (החלופה של --manual דורשת עריכה ידנית של רשומות TXT בכל חידוש). אם יש לך רק מספר קטן של סאב-דומיינים ידועים, תעודת SAN המפרטת אותם באופן מפורש היא פשוטה יותר ושומרת על מפתחות ה-DNS API מחוץ לשרת.