עדכון אחרון: | הצגת כל התיעוד
בעת קבלת אישור מ־Let’s Encrypt השרתים שלנו מתקפים את השליטה שלך על שמות התחום שמוגדרים באישור זה באמצעות „אתגרים”, כפי שמוגדר בתקן ACME. רוב הזמן, התיקוף הזה מטופל על ידי לקוח ה־ACME שלך באופן אוטומטי, אבל אם עליך לקבל החלטות תצורה מורכבות יותר, עדיף להכיר אותן יותר לעומק. במקרה של ספק, עדיף ללכת עם בררות המחדל של הלקוח שלך או עם HTTP-01.
אתגר HTTP-01
זה סוג האתגר הנפוץ ביותר כיום. Let’s Encrypt מעניק ללקוח ה־ACME שלך אסימון ולקוח ה־ ACME שלך מציב קובץ בשרת שלך תחת http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>. קובץ זה מכיל את האסימון בתוספת טביעת האצבע של מפתח החשבון שלך. לאחר שלקוח ה־ACME שלך מודיע ל־Let’s Encrypt שהקובץ מוכן, Let’s Encrypt מנסה לקבל אותו (אולי אפילו מספר פעמים וממגוון נקודות יתרון). אם בדיקות התיקוף שלנו יקבלו את התגובות הנכונות מהשרת שלך, התיקוף ייחשב מוצלח ויתאפשר לך להמשיך להנפיק את האישור שלך. אם בדיקת התיקוף תיכשל, יהיה עליך לנסות שוב עם אישור חדש.
המימוש שלנו לאתגר HTTP-01 עוקב אחר הפניות, עד לעומק של 10 הפניות. הוא מקבל הפניות ל־„http:” או ל־„https:” בלבד, ולפתחות 80 או 443 בלבד. הוא לא מקבל הפניות לכתובות IP. כאשר הוא מופנה לכתובת HTTPS, הוא לא מתקף אישורים (מאחר שהאתגר הזה מיועד להניע תהליך של אישורים תקפים, הוא עשוי להיתקל באישורים שנחתמו עצמית או שתוקפם פג לאורך הדרך).
את אתגר HTTP-01 ניתן לבצע מול פתחה 80 בלבד. לאפשר ללקוחות לציין פתחות באופן שרירותי יוריד את רמת האבטחה של האתגר ולכן תקן ACME לא מרשה זאת.
יתרונות:
- קל לבצע לזה אוטומציה ללא ידע נוסף על הגדרות שם המתחם.
- מאפשר לספקי אחסון להנפיק אישורים לשמות תחום שיש להם CNAME אליהם.
- עובד עם שרתי אינטרנט כמו שהם.
חסרונות:
- זה לא עובד אם ספקית האינטרנט שלך חוסמת את פתחה 80 (נדיר אבל יש ספקיות קטנות שעושות את זה).
- Let’s Encrypt אינו מאפשר לך להשתמש באתר הזה כדי להנפיק אישורים כוללניים.
- אם יש לך מגוון שרתי אינטרנט, עליך לוודא שהקובץ הזה זמין בכולם.
אתגר DNS-01
אתגר זה מבקש ממך להוכיח שיש לך שליטה על ה־DNS של שם התחום שלך על ידי הצבת ערך מסוים ברשומת TXT תחת שם התחום הזה. הוא מסובך יותר להגדרה מאשר HTTP-01, אך עשוי לעבוד במצבים מסוימים בהם HTTP-01 לא יכול. הוא גם מאפשר לך להנפיק אישורים כוללניים. לאחר ש־Let’s Encrypt מעניק אסימון ללקוח ה־ACME שלך, הלקוח שלך ייצור רשומת TXT שנגזרת מאותו האסימון וממפתח החשבון שלך ויוסיף את הרשימה הזאת תחת _acme-challenge.<YOUR_DOMAIN>. לאחר מכן Let’s Encrypt יתשאל את מערכת ה־DNS כדי לאתר את הרשומה הזאת. אם נמצאת התאמה, ניתן להמשיך להנפיק אישור!
מאחר שהאוטומציה של ההנפקה והחידוש היא חשובה מאוד, זה בסך הכול הגיוני להשתמש באתגרי DNS-01 אם לספק ה־DNS יש API בו ניתן להשתמש כדי להגדיר עדכונים אוטומטיים. הקהילה שלנו החלה לגבש רשימה של ספקי DNS שכאלה כאן. יתכן שספק ה־DNS שלך זהה לרשם שמות התחום שלך (החברה ממנה רכשת את שם התחום שלך), או שהוא שונה ממנו. אם ברצונך להחליף ספק DNS, עליך לבצע כמה שינויים קלים אצל הרשם שלך. אין צורך להמתין להתקרבות למועד פקיעת תוקף שם התחום כדי לעשות זאת.
נא לשים לב ששמירת פרטי הגישה המלאים ל־API של ה־DNS שלך על גבי השרת עשויה להגדיל את הנזק במקרה של פריצה לשרת הזה. השיטה המומלצת היא להשתמש בפרטי גישה להיקף מצומצם יותר מתוך ה־API, או לבצע תיקוף DNS משרת נפרד ולהעתיק את האישורים לשרת שלך אוטומטית.
מאחר ש־Let’s Encrypt נצמד לתקני DNS בעת חיפוש רשומות TXT עבור תיקוף DNS-01, ניתן להשתמש ברשומות CNAME או NS כדי לייפות את כוחם של אזורי DNS אחרים במענה לאתגר. ניתן להשתמש בזה כדי לייפות את הכוח על תת־שם התחום _acme-challenge לאזור או שרת למטרות התיקוף. ניתן גם להשתמש בזה אם ספק ה־DNS שלך מתעדכן לאט וברצונך לייפות כוח לטובת שרת שמתעדכן מהר יותר.
לרוב ספקי ה־DNS יש „זמן הפצה” ששולט בכמה זמן לוקח מרגע עדכון רשומת DNS עד שהיא זמינה בכל השרתים שלהם. קשה למדוד את זה כיוון שהם בדרך כלל משתמשים ב־anycast - הפצה לכל אחד, מה שאומר שלמגוון שרתים יכולה להיות אותה כתובת ה־API ובהתאם למיקומך בעולם ייתכן שהתקשורת שלך מתבצעת מול שרת אחר (ולקבל תשובה שונה) ממה שמגיע אל Let’s Encrypt. מנשקי ה־API של ספקי ה־DNS הטובים ביותר מספקים לך דרך לבדוק אוטומטית האם העדכון הופץ במלואו. אם לספק ה־DNS שלך אין תכונה שכזאת, עליך להגדיר את הלקוח שלך להמתין מספיק זמן (לעתים אפילו שעה) כדי לוודא שהעדכון הופץ במלואו בטרם התחלת תהליך התיקוף.
יכולות להיות מספר רשומות TXT עבור אותו השם. זה יכול לקרות, למשל, אם בחרת לתקף אתגר לאישור כוללני ולאישור נקודתי בו־זמנית. עם זאת, עליך להקפיד להסיר רשומות TXT ישנות כיוון שאם גודל התגובה גדול מדי היא תתחיל להידחות על ידי Let’s Encrypt.
יתרונות:
- ניתן להשתמש באתגר הזה כדי להנפיק אישורים לשמות מתחם עם תווי הכללה (wildcards).
- הוא עובד טוב גם אם יש לך מגוון שרתים.
חסרונות:
- להשאיר את פרטי הגישה ל־API על השרת שלך הוא מצב מסוכן.
- יכול להיות שספק ה־DNS שלך לא מציע API.
- יתכן שה־API של ספק ה־DNS שלך לא מספיק מידע על זמני הפצה.
TLS-SNI-01
אתגר זה הוגדר בגרסאות טיוטה של ACME. הוא ביצע לחיצת יד עם TLS בפתחה 443 ושלח כותרת SNI מסוימת תוך חיפוש אחר האישור שכלול בתוך האסימון. הוא הושבת במרץ 2019 כיוון שלא היה מאובטח מספיק.
TLS-ALPN-01
אתגר זה פותח לאחר השבתת תקן TLS-SNI-01 והוא מפותח כתקן נפרד. בדומה ל־TLS-SNI-01, הוא מבוצע דרך TLS בפתחה 443. עם זאת, הוא משתמש בפרוטוקול ALPN כדי לוודא שרק שרתים שמודעים לסוג האתגר הזה יגיבו לבקשות תיקוף. מצב זה מאפשר גם לבקשות תיקוף בסוג אתגר זה להשתמש בשדה SNI שתואם לשם התחום שעובר תיקוף, מה שהופך אותו ליותר מאובטח.
אתגר זה אינו מתאים לרוב האנשים. הוא מתאים ליוצרי מתווכים הפוכים שמפשיטים TLS ומעוניינים לבצע תיקוף מבוסס מארח כגון HTTP-01 אך מעוניינים לעשות זאת בשכבת ה־TLS לחלוטין כדי להפריד סיכונים. כרגע זה אומר בעיקר ספקי אחסון גדולים, אך יכול להיות ששרתים כגון Apache ו־Nginx יממשו את זה ביום מן הימים (ו־Caddy כבר מממשת).
יתרונות:
- עובד גם אם פתחה 80 אינה זמינה לך.
- אפשר ליישם בצורה רעועה בשכבת ה־TLS.
חסרונות:
- הוא לא נתמך על ידי Apache, Nginx או Certbot, וכנראה שגם לא ייתמך בקרוב.
- בדומה ל־HTTP-01 אם יש לך מגוון שרתים, על כולם לענות עם אותו התוכן.
- לא ניתן להשתמש בשיטה הזאת כדי לתקף שמות תחום כוללניים.