Let's Encrypt

הרשאת רשות אישורים (CAA)

עדכון אחרון: | הצגת כל התיעוד

CAA היא סוג של רשומת DNS שמאפשרת לבעלי האתרים לציין לאילו רשויות אישורים (CAs) מותר להנפיק אישורים שמכילים את שם התחום שלהם. תוקננה לראשונה ב־2013, והגרסה שאנו משתמשים בה היום תוקננה ב־2019 על ידי RFC 8659 ו־RFC 8657. כברירת מחדל, כל רשות אישורים ציבורית מורשית להנפיק אישורים לכל שם תחום שהוא ב־DNS הציבורי, בהינתן שהם מאמתים את השליטה בשם התחום הזה. משמעות הדבר היא שיש תקלה בתהליכי התיקוף של כל אחת מבין רשויות אישורים רבות, כל שם תחום עשוי להיות מושפע. ספקי CAA מספקים דרך לבעלי שמות תחום להפחית את הסיכון הזה.

שימוש ב־CAA

אם CAA לא מעניין אותך, בדרך כלל אין צורך לנקוט בשום פעולה (למעט לצפות בשגיאות ה־CAA שלהלן). אם מעניין אותך להשתמש ב־CAA כדי להגביל אילו רשויות אישורים מורשות להנפיק אישורים לשם התחום שלך עליך להשתמש בספק DNS שתומך בהגדרת רשומות CAA. בעמוד של SSLMate על CAA ניתן למצוא רשימה של ספקים כאלה. אם הספק שלך מופיע, ניתן להשתמש במחולל רשומות ה־CAA של SSLMate כדי לייצר ערכה של רשומות CAA שמפרטות את רשויות האישורים שברצונך לאשר.

איפה לשים את הרשומה

בדרך כלל, כדאי להגדיר רשומות CAA בשם תחום שרשמת (כגון: „example.org” או „mysite.co.il”). כך הן חלות הן על שם התחום והן על תת־שמות תחום שנוצרים תחתיו, כגון „community.example.org”.

נא לשים לב שרשות האישורים תמיד מכבדת את רשומת ה־CAA שהכי קרובה לשם התחום שעבורו היא מנפיקה אישור. לכן, אם מוגשת בקשה לאישור עבור „www.community.example.org”, רשות האישורים תבדוק את „www.community.example.org”, לאחר מכן את „community.example.org” ואז את „example.org” והיא תעצר ברשומת ה־CAA הראשונה שהיא מוצאת.

משמעות הדבר היא שניתן לדרוס CAA לתת־שמות התחום שלך. למשל, נגיד ש־„example.org” מתארח אצלך, בעוד ש־„api.example.com” מתארח אצל ספק ענן. אפשר להשתמש ברשומת ה־CAA על „example.org” כדי להכריז שרק Let’s Encrypt יכולים להנפיק לשם התחום הזה וכל תת־שמות התחום שלו אך גם להשתמש ברשומת CAA על „api.example.org” כדי לדרוס את ההחלטה הזאת ולאפשר לספק הענן להנפיק אישורים לתת־התחום היחיד הזה.

נא לשים לב שבדיקת CAA מתייחסת להפניות CNAME, בדיוק כמו לכל בקשות ה־DNS האחרות. אם „community.example.org” הוא CNAME אל „example.forum.com”, רשות האישורים תכבד כל רשומת CAA שמוגדרת עבור „example.forum.com”. אסור שלשם תחום עם רשומת CNAME תהיינה רשומות אחרות כלשהן, כיוון שיכולות להיות סתירות בין רשומות CAA בשם המקורי ורשומות CAA על יעד ההפניה.

מה לשים ברשומה

כל רשומות ה־CAA הן באותה התבנית הבסיסית:

CAA <flags> <tag> <value>‎

ה־flags (דגלונים) הם סתם מספרים שלמים וכמעט תמיד צריכים להיות רק המספר 0, שמציין שלא הוגדרו דגלונים. לבחירתך, אפשר להגדיר לדגלונים את הערך 128 שמציין שהוגדרה „critical bit” (סיבית משמעותית) ושרשויות אישורים אמורות מיידית לעצור ולא להנפיק אישור אם הן לא מזהות את תוכן שדה התגית.

ה־tag (תגית) היא מחרוזת שמציינת איזה סוג של רשומת CAA זאת: או issue או issuewild ברוב המקרים. עוד על אלו להלן.

ולבסוף, ה־value (ערך) היא מחרוזת שמכילה מזהה רשות אישורים אחד לכל היותר (כגון „letsencrypt.org”) וכל מיני משתנים מופרדים בפסיקים כרשות, גם כן מפורט להלן.

המאפיינים issue ו־issuewild

רשומות עם תגית issue פשוט שולטות האם רשות האישורים יכולה להנפיק אישורים לשם התחום הזה ולתת־שמות התחום שלו. בדרך כלל, זו הרשומה היחידה שנחוצה שלך, כיוון שהיא שולטת גם בהנפקה רגילה (למשל: „example.org”) וגם בכוללנית (למשל: „‎*.example.org”) בהעדר רשומות אחרות כלשהן. אפשר לשלוט איזו רשות אישורים יכול להנפיק לשם התחום הזה על ידי הצבת שם התחום המזוהה של רשות האישורים הזה בחלק הערך של רשומת ה־CAA.

רשומות עם התגית issuewild שולטות האם רשות אישורים יכולה להנפיק אישורים כוללניים (למשל: „‎*.example.org”). צריך להשתמש ברשומות issuewild רק אם דרושות לך הרשאות שונות להנפקות כוללנית ובלתי־כוללנית.

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

שם התחום המזוהה עם Let’s Encrypt לטובת CAA הוא letsencrypt.org. מתועד רשמית בסעיף 4.2.1 במדיניות האישורים/הכרזת מדיניות האישורים.

המשתנה validationmethods

אפשר להציב את המשתנה הזה לאחר שם התחום המזוהה עם רשות האישורים כדי לשלוט בשיטות האימות שרשות האישורים יכולה להשתמש בה כדי לאשר את השליטה בשם התחום. אפשר להשתמש בזה כדי להגביל את שיטות האימות שיותר מהימנות בעיניך. למשל, כדי להגביל את רשות האישורים להשתמש רק בשיטת TLS-ALPN-01 אפשר להוסיף ‎;validationmethods=tls-alpn-01 לערך רשומת ה־CAA שלך.

Let’s Encrypt מזהה את מחרוזות שיטות האימות הבאות:

המשתנה accounturi

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

כתובות מלאות של חשבונות Let’s Encrypt נראות כך: https://acme-v02.api.letsencrypt.org/acme/acct/1234567890, כאשר המספרים בסוף הם מספר החשבון שלך.

דוגמאות

רשומת CAA פשוטה שמאפשרת ל־Let’s Encrypt להנפיק ל־„example.org” עשויה להיראות כך:

example.org         CAA 0 issue "letsencrypt.org"

ערכת רשומת CAA מורכבת יותר יכולה להיראות כך:

example.org         CAA 0 issue "myca.org;validationmethods=dns-01"
example.org         CAA 0 issuewild "myca.org"
example.org         CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"

בדוגמה הזאת, יכול MyCA להנפיק ל־„example.org” אך רק באמצעות שיטת האימות DNS-01. הוא יכול גם להנפיק אישורים כוללניים, באמצעות כל שיטת אימות שהיא. לבסוף, OtherCA יכול גם להנפיק אישורים, אך רק אם הבקשה מגיעה מחשבון מספר 123456 ורק עם OtherCA מזהה ויודע איך לטפל נכון במגבלות accounturi (כתובת חשבון מלאה).

שגיאות CAA

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

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

חלק מספקי ה־DNS שלא מכירים את CAA מגיבים תחילה לדיווחים על בעיות עם תשובה כמו „אנחנו לא תומכים ברשומות CAA.” ספק ה־DNS שלך לא צריך לתמוך במפורש ברשומות CAA, הוא צריך רק להשיב NOERROR בתגובה לסוגי שאילתות לא מוכרים (כולל CAA). החזרת קודים תפעוליים אחרים, כולל NOTIMP, לסוגי תשאולים (qtypes) בלתי ידועים היא הפרה של RFC 1035 וצריך לתקן אותה.

SERVFAIL

אחת מהשגיאות הכי נפוצות בה נתקלים אנשים היא SERVFAIL. לרוב היא מציינת כשל בתיקוף DNSSEC. אם קיבלת שגיאת SERVFAIL, הצעד הראשון שלך אמור להיות שימוש במנפה שגיאות DNSSEC כגון dnsviz.net. אם זה לא עובד, יכול להיות ששרתי השמות שלך מייצרים חתימות שגויות רק כאשר התגובה ריקה. ותגובות CAA הן בדרך כלל ריקות. למשל, ב־PowerDNS הייתה את התקלה הזאת מגרסה 4.0.3 ומטה.

אם DNSSEC אינו מופעל אצלך אבל עדיין מתקבלות שגיאות SERVFAIL, הסיבה השנייה הנפוצה ביותר היא ששרת השמות בסמכות העליונה החזיר NOTIMP, שהיא הפרה של RFC 1035 כפי שמתואר לעיל, במקום, אמור היה להישלם NOERROR עם תגובה ריקה. אם מדובר במקרה שכזה, כדאי לפתוח קריאת תמיכה לספק ה־DNS שלך.

בסיכומו של דבר, שגיאות SERVFAIL עשויות להיגרם על ידי הפסקות פעילות של שרתי השמות בסמכות העליונה שלך. כדאי לבדוק מה הם שרתי השמות שלך ברשומות ה־NS ולוודא שכל אחד מהשרתים האלו זמינים.

פקיעת זמן מוקצב

לפעמים הזמן המוקצב לשאילתות CAA פג. עשוי להתרחש אם שרת השמות בסמכות העליונה אף פעם לא עונה, אפילו אחרי מספר ניסיונות. בדרך כלל זה יכול לקרות כאשר לשרת השמות שלך יש לפניה חומת אש שאינה מוגדרת כראוי ומשמיטה שאילתות DNS מסוגי שאילתות (qtypes) בלתי ידועים. יש לפתוח קריאת תמיכה מול ספק ה־DNS שלך ולשאול אותם אם יש להם חומת אש שמוגדרת בצורה הזאת.