התעודה פגה: למה החידוש האוטומטי נשבר

Let’s Encrypt מנפיקה תעודות לתשעים יום ומחדשת אותן אוטומטית, ולכן מפסיקים לחשוב עליהן שבוע אחרי ההגדרה. הצרה היא שהחידוש האוטומטי נשבר בשקט: איש אינו רואה את השגיאות, ושלושה חודשים אחר כך האתר מקבל את פני המבקרים באזהרת דפדפן. משנת 2025 הפסיקה Let’s Encrypt לשלוח הודעות על פקיעת תוקף, כך שגם התזכורת החיצונית האחרונה נעלמה.

להלן הסיבות שבגללן החידוש מפסיק לעבוד, בסדר יורד של תדירות.

1. התעודה חודשה והשירות מעולם לא קרא אותה מחדש

הנפוצה ביותר. certbot renew עבד, הקובץ החדש בדיסק, ו-nginx או Apache מחזיקים את הישן בזיכרון — ומגישים אותו למבקרים עד שההגדרות ייטענו מחדש. פורמלית הכול בסדר; למעשה לאתר יש תעודה שפג תוקפה.

התרופה היא וו שרץ אחרי חידוש מוצלח:

sudo certbot renew --deploy-hook "systemctl reload nginx"

זה נכתב פעם אחת בקובץ החידוש (/etc/letsencrypt/renewal/example.com.conf, המקטע [renewalparams], השורה renew_hook) ומשם והלאה עובד מעצמו.

2. שרת האתר השתנה והאתגר לא

אתגר HTTP-01 דורש שקובץ מ-/.well-known/acme-challenge/ יוגש דרך HTTP רגיל. וזה נשבר בדרך כלל כך:

• נוספה להגדרות הפניה בלתי מותנית מ-HTTP ל-HTTPS — האתגר עוקב אחרי ההפניה ונכשל;
• הופיע כלל location ~ /\. עם deny all שסגר כל תיקייה עם נקודה, כולל .well-known;
• שורש האתר עבר בעוד ההגדרות של certbot שמרו על --webroot-path הישן;
• הופעלה חסימה לפי מדינה או אימות בסיסי ותפסה יחד עם כולם גם את שרת האימות.

הסדר הנכון בהגדרות: תחילה location ייעודי ל-/.well-known/acme-challenge/, ורק אחר כך ההפניה הכללית.

3. הטיימר כבוי

החידוש רץ מטיימר של systemd או ממשימת cron, וכל אחד מהם עלול להיכבות בטעות בזמן איתור תקלות או ללכת לאיבוד בהעברת שרת.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

הפקודה השנייה מבצעת מחזור חידוש מלא במצב בדיקה בלי לבזבז את המכסה שלכם. וזו הבדיקה היחידה שעונה מראש על השאלה «האם זה יתחדש בעוד חודש» ולא בדיעבד.

4. דומיין כבר אינו מצביע לכאן

התעודה מכסה חמישה דומיינים, אחד מהם עבר למארח אחר, וה-DNS השתנה. האימות לאותו דומיין מפסיק לעבור, ו-certbot אינו מחדש את כל התעודה — כולל ארבעת הדומיינים שעובדים. את הדומיינים המיותרים צריך להסיר מהתעודה ולא להתעלם מהם יחד עם ההודעה.

5. נתקלתם במגבלות הקצב

Let’s Encrypt מגבילה את מספר התעודות לכל דומיין בשבוע. וזו בדרך כלל תוצאה של לולאת «לא עבד, אנסה שוב» בזמן איתור תקלות. לניסויים יש שרת בדיקה (--dry-run או --test-cert), ובו צריך להשתמש לפני מיצוי המגבלה ולא אחריה.

בדקו מה מוגש, לא מה מאוחסן

לכל בדיקה שמסתמכת על קבצים בדיסק יש פגם אחד: הקובץ עשוי להיות טרי בעוד המבקר מקבל את התעודה הישנה. הביטו מצד הלקוח:

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

האפשרות -servername היא חובה: בלעדיה בשרת עם כמה אתרים תקבלו את התעודה של המארח הווירטואלי שבא ראשון, ולא של זה שהתכוונתם אליו. בפלט, notAfter הוא תאריך הפקיעה האמיתי.

ובעודכם שם, בדקו את השרשרת:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

אם יש רק תעודה אחת, תעודת הביניים אינה מוגשת. דפדפנים בדרך כלל סולחים על התצורה הזאת — הם בונים את השרשרת בעצמם — אבל curl, אפליקציות מובייל ולקוחות Java ייכשלו באימות. וזה המקרה הקלאסי של «אצלי זה נפתח מצוין ואצל הלקוח לא עובד».

כמה ימים מראש להתריע

שלושים יום הם התראה ראשונה סבירה: זה גם מה שנותר כאשר certbot מתחיל בניסיונות החידוש, ולכן אם עד אז לא קרה דבר, המנגנון שבור. ארבעה עשר יום הם ההתראה השנייה, והיא כבר דורשת פעולה היום. שבעה הם מצב חירום.

וחשוב לעקוב אחרי כל התעודות בבת אחת, כולל אלה שלא הגיעו מ-Let’s Encrypt: אלה שנקנו לשנה נשכחות באמינות הרבה יותר, כי בתוך שנה כולם שוכחים גם אותן וגם לאיזו תיבת דואר הולכות ההתראות. עמוד אחד עם הדומיינים, התאריכים והימים שנותרו סוגר את השאלה לחלוטין — כמו בהדגמה למטה.