עדכון אחרון: | הצגת כל התיעוד
מסמך זה מכיל עצות שימושיות אם יש ספק אירוח או אתר גדול בתחום אחריותך שמשתלבים מול Let’s Encrypt או שבחרת לפתח תכנית לקוח עבור Let’s Encrypt.
תכנון לעדכונים
גם Let’s Encrypt וגם Web PKI ימשיכו להתפתח עם הזמן. עליך לוודא שיש לך את היכולת לעדכן את כל השירותים שמשתמשים ב־Let’s Encrypt. אם בנוסף לכך הטמעת לקוחות שנסמכים על אישורים של Let’s Encrypt היא באחריותך, כדאי מאוד לוודא שהלקוחות האלו יתעדכנו על בסיס קבוע.
בעתיד, אלו עשויים להשתנות:
- האישורים העליונים והמתווכים מתוכם אנחנו מנפיקים
- האלגוריתמים של הגיבוב בהם אנו משתמשים בעת חתימת אישורים
- סוגי המפתחות ובדיקות חוזק המפתחות שעבורם אנחנו רוצים לחתום אישורים ליישויות קצה
- ופרוטוקול ACME
אנו תמיד נתכננן להודיע מראש עד כמה שניתן על שינויים שאלה, למרות שבמקרים של איתור פרצת אבטחה חמורה ברכיב כלשהו ייתכן שניאלץ לערוך שינויים בטווח קצר מאוד או מיידית. לשינויים במתווכים במיוחד, אין לקבע את המתווך שיהיה בשימוש, במקום עדיף להשתמש בכותרת Link: rel="up" מפרוטוקול ACME מאחר שמתווכים עשויים להשתנות.
באופן דומה, סביר להניח שנשתה את כתובת תנאי השירות (ToS) עם עדכונם. יש להימנע מקיבוע כתובת תנאי השירות ובמקום לסמוך על הכותרת Link: rel="terms-of-service" כדי לפענח באיזו כתובת תנאי שירות להשתמש.
יתכן שגם יעניין אותך לפתח דרך להשאיר את הגדרות ה־TLS שלך עדכניות לאור גילוי מתקפות חדשות בערכות צופן או בגרסאות פרוטוקולים.
קבלת עדכונים
כדי לקבל עדכונים דלילים על שינויים חשובים כמו אלו שתוארו לעיל, ניתן להירשם לקבוצה הכרזות API. שימושי למפתחי לקוחות וספקי אירוח.
לקבלת עדכונים יותר צפופים על תחזוקה ותקלות בשירות, יש לבקר בעמוד המצב שלנו וללחוץ על רישום בפינה השמאלית העליונה. עשוי בעיקר להועיל לספקי אחסון.
כמו כן, כדאי לוודא שימוש בכתובת דוא״ל תקנית עבור חשבון ה־ACME שלך. אנו נשתמש בכתובת הזאת כדי לשלוח לך התראות תפוגת תוקף וכדי ליצור אתך קשר בנוגע לכל מיני תקלות שנוגעות לחשבון שלך.
מי המנוי
ה־CPS (הצהרת מדיניות האישור) והסכם המנוי מציינים שהמנוי הוא מחזיק במפתח הפרטי לאישור. לספקיות אירוח, מדובר בספקית, לא בלקוח של הספקית. אם נמצאת אצלך כרגע בפיתוח תכנית שאנשים מטמיעים בעצמם, אז אלו המטמיעים עצמם.
כתובת הדוא״ל ליצירת קשר שמסופקת בזמן יצירת חשבונות (ידועים גם בשם נרשמים) אמורה להפנות למנוי. אנו נשלח הודעות בדוא״ל כדי להזהיר מפני אישורים שתוקפם עומד לפוג, ולהודיע על שינויים במדיניות הפרטיות שלנו. אם הנך נציגות מטעם ספקית אחסון, ההודעות האלו צריכות להגיע אליך במקום ללקוח הקצה. מוטב להגדיר רשימת תפוצה או כינוי דוא״ל כדי שמספר אנשים יוכלו להגיב להודעות במקרה שיצאת לחופשה.
כתוצאה מכך, אם הנך נציגות מטעם ספקית אחסון, אין צורך בשליחת כתובות הדוא״ל של הלקוחות שלך או לבקש מהם להסכים להסכם המנויים שלנו. באפשרותך פשוט להנפיק אישורים עבור שמות התחום שבשליטתך ולהתחיל להשתמש בהם.
חשבון אחד או יותר?
ב־ACME אפשר ליצור חשבון אחד ולהשתמש בו לכל ההרשאות וההנפקות או ליצור חשבון אחד ללקוח. הגמישות הזאת היא יקרת ערך. למשל, חלק מספקיות האחסון עשויות לרצות להשתמש בחשבון אחד ללקוח ולאחסן את מפתחות החשבון בהקשרים אחרים, כדי שפגיעה במפתח חשבון אחד לא תאפשר הנפקה עבור כל הלקוחות שלהם.
עם זאת, עבור רוב ספקיות האחסון הגדולות יותר אנו ממליצים להשתמש בחשבון בודד ולהגן על מפתח החשבון הזה בקפידה. מצב זה מקל על זיהוי אישורים ששייכים לאותה יישות, קל יותר לשמור על עדכניות פרטי קשר וקל יותר לספק התאמות מגבלות מיכסה אם יש צורך בכך. לא תהיה לנו אפשרות להתאים מגבלות מיכסה ביעילות אם נעשה שימוש במספר רב של חשבונות.
אישורים למגוון שמות תחום (SAN)
מדיניות ההנפקה שלנו מאפשרת עד 100 שמות לאישור. בין אם בחרת להשתמש באישור נפרד לכל שם מארח או לקבץ יחד מגוון שמות מארחים במקבץ קטן של אישורים, בחירה זו נתונה לשיקולך.
המשמעות שבהפרדת אישורים לפי שם מארח היא שנדרשים פחות חלקים נעים לצורך הוספה והסרה של שמות תחום ברמה הלוגית בעת הקמתם או פרישתם. אישורים נפרדים יכולים למזער את גודל האישור, מה שעשוי להאיץ את לחיצת היד לטובת HTTPS ברשתות עם רוחב פס נמוך.
מצד שני, שימוש באישורים גדולים עם מגוון שמות מאחרים מאפשר לך לנהל פחות אישורים בסך הכול. אם עליך לתמוך בלקוחות ישנים כגון Windows XP שאינם תומכים בציון שם שרת עם TLS (Server Name Indication - SNI), תידרשנה לך כתובת IP ייחודית עבור כל אישור, לכן הוספת כמה שיותר שמות בכל אישור מפחיתה את כמות כתובות ה־IP שתידרשנה לך.
עבור רוב תצורות ההטמעה שתי האפשרויות מציעות את אותה רמת האבטחה.
אחסון ושימוש חוזר באישורים ובמפתחות
החלק הארי בערך של Let’s Encrypt הוא שהמערכת מאפשרת הנפקה אוטומטית כחלק מתהליך הקמת אתר חדש. עם זאת, אם התשתית שלך עשויה ליצור שרתי חזית (frontends) באופן מחזורי עבור אותו אתר, על אותם שרתי החזית לנסות תחילה להשתמש באישור ובמפתח הפרטי מהאחסון היציב ולהנפיק אישור חדש רק אם אין אישור זמין או שתוקפם כל האישורים הנוכחיים פג.
עבור Let’s Encrypt, מנגנון שכזה מסייע לנו לספק שירותים ביעילות לכמות האנשים האפשרית הגדולה ביותר. עבורך, מנגנון שכזה מוודא שבאפשרותך להטמיע אתר האתר שלך בכל זמן נתון, ללא תלות במצב של Let’s Encrypt.
למשל, אתרים רבים מתחילים להשתמש ב־Docker כדי לספק מופעי שרתי חזית (frontends) כנדרש. אם הגדרת את מכולות ה־Docker שלך להנפיק אישור עם כל הפעלה שלהם ולא אחסנת את האישורים והמפתחות שלך באופן יציב, סביר להניח שהחשבון שלך ייתקל במגבלת מיכסה אם יותר מדי מופעים יופעלו בבת אחת. במצב הגרוע ביותר, אם עליך להשמיד וליצור מחדש את כל המופעים שלך בבת־אחת, יתכן שאף אחד מהמופעים שלך לא יוכל לקבל אישור והאתר שלך יהיה פגום למשך כמה ימים עד לפקיעת תוקף מגבלת המיכסה. עם זאת, סוג כזה של תקלה אינו ייחודי למגבלות מיכסה. אם השירות של Let’s Encrypt אינו זמין מסיבה כלשהי כשעליך להעלות את שרתי החזית שלך, תהיה לך את אותה הבעיה.
נא לשים לב שחלק מתאוריות ההטמעה גורסות שמפתחות הצפנה אף פעם לא אמורים להישאר באותה המכונה הפיזית בה הם נוצרו. דגם זה יכול לעבוד נהדר עם Let’s Encrypt, כל עוד וידאת שהמכונות האלו והנתונים שלהם מיועדים לטווח ארוך וההתנהלות שלך בתוך מגבלות המיכסה היא מפוקחת.
בחירת סוג אתגר
אם בחרת באתגר http-01 של ACME, יהיה עליך לספק את התגובה לאתגר לכל אחד משרתי החזית (frontends) שלך בטרם הודעה ל־Let’s Encrypt שסיימת להתכונן למלא אחר האתגר. אם יש לך כמות גדולה של שרתי חזית, זה עשוי להיות מאתגר. במקרה כזה, כנראה שהשימוש באתגר dns-01 יהיה קל יותר. כמובן שאם יש לך מגוון שירותי DNS מבוזרים שעשויים לענות לפנייה, יהיה עליך לוודא שרשומת ה־TXT זמינה בכל אחד מהשירותים שעונים.
נוסף על כך, בעת שימוש באתגר dns-01, יש לוודא שמחקת רשומות TXT ישנות כדי שהתגובה לשאילתה של Let’s Encrypt לא תהיה גדולה מדי.
אם מעניין אותך להשתמש באתגר http-01 בין כה וכה, יכול להיות שעדיף לך להשתמש בהפניות HTTP. ניתן להגדיר כך שכל נקודות ההשקה שלך מול המשתמש (frontends) יפנו מ־/.well-known/acme-validation/XYZ אל validation-server.example.com/XYZ לכל XYZ שהוא. הגדרה שכזאת מעניקה את האחריות להנפקה לשרת תיקוף מרכזי, לכן עליך להגן על השרת הזה היטב.
שרתי תיקוף מרכזיים
בהקשר לשתי הנקודות שלעיל, יכול להיות שעדיף לך, במקרה של מגוון רחב של נקודות השקה מול המשתמש (frontends), להשתמש בסדרה מצומצמת של שרתים לניהול ההנפקה. הגדרה שכזאת מקלה על שימוש בהפניות בתיקוף http-01 ומספקת מקום לאחסון אישורים ומפתחות בצורה יציבה.
הגדרות חומת אש
כדי להשתמש ב־Let’s Encrypt עליך להרשות תעבורה יוצאת בפתחה 443 מהמכונות שמפעילות את לקוח ה־ACME שלך. אנו לא נפרסם את כתובות ה־IP לשירות ה־ACME והן תשתנינה ללא אזהרה מוקדמת.
לטובת אתגר ACME מסוג „http-01”, עליך לאפשר תעבורה נכנסת בפתחה 80. אנו לא מפרסמים את כתובות ה־IP מהן אנו מבצעים תיקוף והן תשתנינה ללא אזהרה מוקדמת.
לתשומת לבך: אנו תמיד ממליצים לאפשר גישת HTTP בצורה פשוטה לשרת שלך, עם הפניה ל־HTTPS. מצב זה תמיד מעניק חוויית משתמש טובה יותר מאשר שרת שמסרב או קוטע התחברויות לפתחה 80 ומספק את אותה רמת האבטחה.
עבור כל האתגרים, עליך לאפשר תעבורה נכנסת בפתחה 53 (TCP ו־UDP) לשרתי ה־DNS המוסמכים שלך.
אלגוריתמים נתמכים למפתחות
Let’s Encrypt מקבלת מפתחות RSA באורך של 2048, 3072 או 4096 סיביות ומפתחות P-256 או P-384 ECDSA. זה נכון גם לגבי מפתחות חשבונות וגם לגבי מפתחות אישורים. אי אפשר לעשות שימוש חוזר במפתח חשבון בתור מפתח אישור.
ההמלצה שלנו היא לשרת תצורת מפתחות זוגית, שמציעה אישור מסוג RSA כבררת מחדל, ואישור (קטן בהרבה) מסוג ECDSA ללקוחות שמציינים שהם תומכים בו.
HTTPS כבררת מחדל
לספקי אחסון, ההמלצה שלנו היא להנפיק אוטומטית אישורים ולהגדיר HTTPS לכל שמות המארחים שבשליטתך ולהציע הגדרה שהמשתמש יכול לשנות האם להפנות כתובות HTTP למקבילות ה־HTTPS שלהן. אנו ממליצים שעבור חשבונות קיימים, ההגדרה הזאת תושבת כבררת מחדל אבל לחשבונות חדשים האפשרות הזאת תפעל כבררת מחדל.
הסיבה לכך: אתרים קיימים עשויים לכלול תת־משאבים ב־HTTP (סקריפטים, CSS ותמונות). אם האתרים האלו מופנים אוטומטית לגרסת ה־HTTPS שלהם, הדפדפנים יחסמו חלק מתת־המשאבים האלה עקב חסימת תוכן מעורב. מצב שכזה יכול לפגום בתקינות האתר. עם זאת, אם מדובר באתר חדש שכבר מפנה ל־HTTPS אז סביר להניח שמקים האתר יכלול תת־משאבים ב־HTTPS בלבד, כיוון שאם הם ינסו לכלול משאבים ב־HTTP הם מיד ישימו לב שזה לא עובד.
אנו ממליצים לאפשר ללקוחות להגדיר כותרת HTTP Strict-Transport-Security (HSTS) עם max-age של שישים ימים כבררת מחדל. עם זאת, את ההגדרה הזאת יש ללוות באזהרה שאם על הלקוח לעבור לספקית אחסון שאינה מציעה HTTPS, הגדרת ה־HSTS שבדפדפנים יגרום לכך שהאתר שלהם יהיה לא זמין. כמו כן, גם הלקוח וגם ספקית האחסון אמורים להיות מודעים לכך שכותרת ה־HSTS עשויה להפוך שגיאות אישורים לכשלים מורכבים. למשל, בעוד אנשים יכולים בדרך כלל לדלג על אזהרה בדפדפן בנוגע לחוסר התאמה בשם או תפוגת תוקף אישור, הדפדפנים לא מאפשרים לדלג על אזהרה עבוד שמות מארחים עם כותרת HSTS פעילה.
מתי לחדש
אנו ממליצים לחדש אישורים אוטומטית כאשר נותר עוד שליש מתוך סך כל חייהם. עבור האישורים הנוכחיים של Let’s Encrypt שתוקפם הוא 90 ימים, משמעות הדבר היא לחדש 30 יום לפני מועד התפוגה.
אם עליך להנפיק למעלה מ־10,000 שמות מארחים, אנו גם ממליצים על חידוש אוטומטי במקבצים קצרים על פני איסוף חידושים לחבילות גדולות. התנהלות שכזאת מפחיתה את הסיכון: אם השירות של Let’s Encrypt אינו פעיל בזמן שעליך לחדש או שיש תקלה זמנית במערכת החידושים שלך, תהיה השפעה רק על חלק מהאישורים במקום על כולם. נוסף על כך, תכנון הקיבולת שלנו פשוט יותר.
יכול להיות שהעדפתך תהיה להנפיק כמות גדולה של אישורים לכל שמות התחום שלך כדי להיכנס מהר לעניינים, זה בסדר. לאחר מכן אפשר פשוט לפזר את מועדי החידוש על ידי תהליך חד־פעמי של חידוש חלק מהאישורים יום לפני מועד החידוש הרגיל, חלקם יומיים לפני וכן הלאה.
אם יש לך תכנה שמוצעת מטעמך ומגדירה אוטומטית משימה כמותית תקופתית, נא לוודא שהיא פועלת בשנייה אקראית המשלך היום במקום לרוץ באותה השעה כל פעם. שיטה זו מבטיחה שלא יופנו עומסי תעבורה כבדים ל־Let’s Encrypt באופן שרירותי בתחילת שעה או דקה. מאחר שעל Let’s Encrypt להתכונן לקיבולת שתעמוד בעומס נקודתי, הפחתת עומסים פתאומיים יכולה לסייע לנו לחסוך בעלויות.
ניסוי חוזר של כשלונות
אין להתנהל מול כשל בחידוש כמו לשגיאה משמעותית. עליך להטמיע לוגיקת ניסיון חוזר רכה בשירותי ההנפקה שלך באמצעות תבנית נסיגה מעריכית שמגיעה לפעם ביום לכל היותר לכל אישור. למשל, תזמון נסיגה סביר יהיה משהו כמו: ניסיון ראשון אחרי דקה, ניסיון שני אחרי עשר דקות, ניסיון שלישי אחרי 100 דקות, ניסיונות רביעי ואילך לאחר יום. אמורה להיות למנהלים שלך דרך לבקש ניסיונות חוזרים מהירים יותר לפי שם תחום או להכול.
משמעות נסיגות על ניסיונות חוזרים היא שהתכנה שמנפיק עבורך אמורה לעקוב אחר כשלונות לצד הצלחות ולבדוק האם היה כשל בניסיון האחרון בטרם ניסיון הנפקה מחדש. אין טעם לנסות להנפיק מאות פעמים בשעה מאחר שכשלונות חוזרים הם בדרך כלל עקביים.
את כל השגיאות יש לשלוח להנהלה האחראית כדי לראות אם יש תקלות מסוימות שדורשות תיקון.