הגדרת Let's Encrypt עם חידוש SSL אוטומטי

תעודת Let's Encrypt פגה בלילה: מה נשבר

תעודה שפגה של Let's Encrypt מתבטאת לא בהדרגה, אלא מיד: דפדפנים מפסיקים לפתוח חיבור ומציגים אזהרה על אתר לא מאובטח. המשתמש לא יתחיל לברר מי אשם — הוא עוזב.

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

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

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

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

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

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

מה נותן חידוש אוטומטי של תעודות

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

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

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

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

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

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

דרכי הנפקה ובדיקה: השוואת גישות

הבחירה של שיטת הנפקה ואימות הדומיין קובעת עד כמה התעודה תתחדש באופן אוטונומי בהמשך. טעות בשלב הזה לא מתגלה מיד, אלא לאחר 60-90 ימים, כאשר תוקף התוקף מתקרב לסיומו והחידוש נכשל בשקט. להלן — אפשרויות עבודה שבהן באמת בוחרים בפועל.

מצבי עבודה

פיצול המפתח — היכן חי הלקוח ואיך הוא מקבל חידוש. במצב standalone הלקוח מרים פורט משלו לזמן הבדיקה, ולכן יש לעצור את שרת האינטרנט — זה מותר על צומת מבודד, אך שובר את העבודה בתעבורה חיה.

במצב webroot הבדיקה עוברת דרך שרת שכבר פועל, החידוש לא קוטע חיבורים, אך דורש שהנתיב לשורש האתר יהיה נגיש לתהליך. במצב DNS-01 הפורט בכלל לא נדרש — זהו הנתיב היחיד עבור wildcard ועבור שרתים מאחורי מאזן עומסים.

מגבלות שכדאי לקחת בחשבון מראש

ל-Let's Encrypt יש מגבלות על מספר ההנפקות עבור דומיין אחד לתקופה ועל בדיקות כושלות חוזרות — בפריסה המונית זה נתקל במכסה, אם לא לשמור תוצאות ביניים במטמון. התעודה חיה 90 ימים, את החידוש מפעילים 30 ימים לפני הסוף: מרווח זה מספיק כדי לתפוס כשל ולא להיכנס לפיגור. עבור דומיינים פנימיים ללא אזור ציבורי DNS-01 נשאר האפשרות העובדת היחידה.

כיצד אנו מיישמים אוטומציה: שלבי העבודה

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

1. ביקורת תצורה. אנו אוספים את התעודות הנוכחיות, תוקףן ואופן ההנפקה. בודקים האם כל השמות מכוסים, כולל אלו שנוספו ידנית ונשכחו מהאוטומציה.
2. תרשים החידוש. קובעים היכן יתגורר לקוח העדכון, כיצד הוא מקבל אימות בעלות על הדומיין והיכן הוא מאחסן את התעודות המוכנות. מקבעים נקודה יחידה כדי שלא יהיו שני תהליכים מתחרים.
3. הגדרת עדכון אוטומטי. רושמים משימה תקופתית עם מרווח זמן לפני פקיעת התוקף, מוסיפים הפעלה מחדש של שירותים שמחזיקים את התעודה בזיכרון, והתראות על ניסיונות כושלים.
4. בדיקה. מריצים הנפקה בסביבת בדיקות, ואז בודקים חידוש אמיתי ונסיגה לתעודה הקודמת. בודקים ששרשרת האמון נבנית כראוי ודפדפנים ישנים לא נופלים.
5. ניטור. מגדירים בקרת תוקף והתראות כמה ימים לפני הפקיעה — כדי שהבעיה תצוף אצלנו, ולא אצל המבקרים.
6. מסירה. מוסרים תצורות, תרשים פריסה והוראות להוספת דומיינים חדשים, כדי שצוות הלקוח יוכל להרחיב את הרשימה בלעדינו.

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

מה הלקוח מקבל לידיו לאחר סיום העבודה

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

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

כל פריט מועבר בצורתו כפי שהוא נמצא על השרת — ללא פערים בין התיעוד למצב בפועל. בנפרד מפרטים מה יקרה בעת ביטול תעודה וכיצד לחזור לתצורה הקודמת אם החידוש נכשל.

מקרה בוחן: איך הסרנו תקלות לילה בתעודות

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

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

מה היה לפני

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

מה שינינו

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

מה נהיה

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

במה שונה Let's Encrypt מתעודות בתשלום?

מנקודת המבט של הדפדפן אין הבדל: Let's Encrypt — תעודת DV רגילה מרשות אישורים מהימנה, שתעודת השורש שלה מותקנת מראש במערכות הפעלה ובדפדפנים. החיבור מוצפן באותה מידה, המנעול הירוק ו-HTTPS מוצגים באותו אופן. המשתמש לא יראה אם התעודה בתשלום או הונפקה אוטומטית — הוא יראה רק שהאתר מאובטח.

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

חידוש ידני פשוט לא עובד כאן — שכחו לחדש, והאתר מקבל את המבקרים באזהרה על חיבור לא מאובטח, מה שפוגע באמון ובמיקומים בחיפוש.

ברמת האמון ההבדל מתבטא בתרחישים. תעודת DV חינמית מאשרת רק בעלות על הדומיין — זה מספיק לאתרים, חנויות מקוונות, אזורי אישי ו-API. תעודות OV ו-EV בתשלום מאמתות בנוסף את הארגון ומציגות אותו בתעודה: זה מבוקש בבנקים, במגזר הציבורי, בשערי תשלום, שבהם חשובה זיהוי משפטי. אם התרחיש שלכם הוא שירות אינטרנט רגיל, אין הבדל באמון מבחינת הלקוח.

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

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

ספקות טכניים נפוצים בהגדרת SSL

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

יש כמה דומיינים — זו עבודה ידנית לכל אחד?

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

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

שירותים פנימיים לא אמורים להיות נגישים מבחוץ — מה עושים?

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

תאימות עם לקוחות ישנים ואפליקציות מובייל

תעודות Let's Encrypt מהימנות עבור הרוב המכריע של הדפדפנים המודרניים והפלטפורמות למובייל. בעיות מתעוררות רק במכשירים מיושנים, שבהם תעודת השורש לא עודכנה שנים.

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

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

נדון במשימה שלכם ונחזור עם הערכה

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

לפי נתוני פתיחה אלה נציע תוכנית עבודה והערכה — ללא התחייבות מצדכם וללא "נבהיר זאת מאוחר יותר".

מה לתאר בבקשה כדי שהשיחה תהיה עניינית:

• היכן נמצאים כעת האישורים: על שרת אחד, על מאזן עומסים, בפרוקסי הפוך או מופצים בין מספר צמתים.
• כיצד מונפקים ומתחדשים: ידנית, לפי לוח זמנים, דרך שירות נפרד לניהול אישורים.
• כמה דומיינים ותת-דומיינים בהיקף, כולל קונטורים שירותיים ו-staging.
• מה כבר נשבר: אישורים שפג תוקפם, חוסר סנכרון בין צמתים, תזכורות ידניות, שגיאות בחידוש.
• מגבלות התשתית: קונטורים סגורים ללא גישה חיצונית, מרכז אישורים עצמאי, דרישות בנוגע להרשאות גישה.
• מי אחראי על התפעול ואילו חלונות זמן לשינויים מותרים.

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

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