Defaults.Exposed › תיקונים › רשומות CAA

כיצד לתקן רשומות CAA

רשומת CAA היא הוראה קצרה בהגדרות הדומיין שלך שמציינת אילו חברות תעודות רשאיות להנפיק תעודת אבטחת 'המנעול' לאתר שלך. כשהיא מופעלת, אף חברה אחרת לא יכולה ליצור בשקט תעודה חוקית בשמך.

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

מה זה יכול לעלות לכם

• רמאי מקבל תעודה אמיתית עבור עותק של האתר שלך, כך שהוא מציג את המנעול הירוק ו-HTTPS — לקוחותיך לא רואים שום דבר שגוי, מקלידים את הסיסמאות ומספרי הכרטיס שלהם, ואתה גלה זאת רק כשמתחילים החיובים החוזרים והשיחות הכועסות.
• לקוחותיך נופלים קורבן לפישינג דרך עותק מדויק-לפיקסל של דף הכניסה שלך; ההשלכות — החזרים, עומס תמיכה, נזק מוניטין — נוחתות על המותג שלך גם שהשרתים האמיתיים שלך מעולם לא נגעו בהם.
• צוות האבטחה או הרכש של לקוח פוטנציאלי מריץ בדיקה מהירה על הדומיין שלך לפני החתימה, רואה שאין הגנת CAA, ומסמן אותך בשקט כ'חלש בבסיסיות' — מסכן עסקה על הגדרה שלוקחת חמש דקות להוסיף.
• אחת מחברות התעודות בעולם נפגעת (זה קרה שוב ושוב — DigiNotar, Comodo, Symantec), וכי מעולם לא אמרת מי מורשה לפעול בשמך, הדומיין שלך חשוף לאיזה שיהיה החוליה החלשה ביותר.

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

רשומות CAA, בשפה פשוטה

לכל אתר מאובטח יש תעודה — הדבר שמאחורי המנעול בדפדפן ו-”https” בחזית הכתובת שלך. תעודות אלה מחולקות ע”י חברות מומחיות הנקראות רשויות תעודות (CAs): שמות כמו Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. כשהדפדפן שלך רואה תעודה חוקית, הוא מציג את המנעול ואומר ללקוח שלך שהחיבור אמיתי ומאובטח.

הנה החלק שרוב בעלי העסקים מעולם לא נאמר להם: כברירת מחדל, מאות רשויות תעודות אלה ברחבי העולם כל אחת מורשית להנפיק תעודה עבור הדומיין שלך — בין שאי פעם שמעת עליהן ולא. רשומת CAA (Certification Authority Authorization) היא הערה בשורה אחת שאתה מוסיף להגדרות ה-DNS של הדומיין שלך שאומרת, למעשה, “רק ספקים אלה רשאים להנפיק תעודות בשבילי.” כל רשות תעודות לגיטימית מחויבת לפי כללי הענף לבדוק הערה זו לפני הנפקה — ולסרב אם הם לא ברשימה שלך.

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

מה זה יכול לעלות לך

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

• הזיוף המושלם. רמאי רושם כתובת דומה (או פוגע בנתיב ללקוחות שלך), מקבל תעודה אמיתית, ומקים שיבוט מושלם של דף הכניסה או הקופה שלך — מנעול וכל. לקוחות מזינים סיסמאות ומספרי כרטיס כרגיל. הדבר הראשון שאתה שומע עליו הוא גל של חיובים חוזרים, דיווחי הונאה, ושיחות טלפון כועסות.
• קמפיין הפישינג בשמך. תוקפים שולחים אימיילים “אנא אשר את חשבונך” שמקשרים לשיבוט המתועדת שלהם של האתר שלך. כיוון שהדף נראה מאובטח לחלוטין, יותר אנשים נופלים עליו. ניקוי המצב — הודעה ללקוחות, החזרים, שעות תמיכה, ההסבר הציבורי המביך — נוחת עליך, גם שהשרתים האמיתיים שלך מעולם לא נגעו בהם.
• העסקה שעוצרת ברשימת בדיקה. צוות האבטחה או הרכש של לקוח גדול יותר סורק את הדומיין שלך לפני החתימה. “אין רשומת CAA” מופיעה כפריט אדום או כתום ליד שמך. זה דבר קטן טכנית, אבל הוא קורא כ”לא מכסה את הבסיסיות,” וזה יכול לעכב או לשקע חוזה שאחרת היית זוכה בו.
• נתפס ע”י הפרצה של מישהו אחר. רשות תעודות שמעולם לא עסקת איתה נפגעת — זה לא היפותטי; ל-DigiNotar, Comodo ו-Symantec כולם היו אירועים חמורים. כיוון שמעולם לא הגבלת מי יכול לפעול בשמך, התוקף יכול לקבל תעודה חוקית לדומיין שלך דרך אותה CA חלשה. רשומת CAA הייתה מסרבת להם.
• נקודת העיוורון של ה-wildcard. אפילו עסקים שזהירים לגבי האתר הראשי שלהם לעתים קרובות שוכחים תתי-דומיינים. ללא כלל issuewild, תוקף שיכול לקבל תעודת wildcard מקבל בפועל מפתח לכל תת-דומיין שיהיה לך אי פעם בבת אחת.

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

מה זה בעצם, ומה נראה “טוב”

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

• issue — מציין רשות תעודות שרשאית להנפיק תעודות רגילות לדומיין שלך. יכולים להיות לך כמה, אחד לכל ספק שאתה משתמש בו לגיטימית.
• issuewild — שולט בתעודות wildcard (תעודה אחת שמכסה כל תת-דומיין, כמו *.example.com). אם אינך משתמש ב-wildcards, ההגדרה המומלצת חוסמת אותם לחלוטין.
• iodef — כתובת יצירת קשר אופציונלית שבה תקבל הודעה אם רשות תעודות דחתה בקשה בגלל מדיניות ה-CAA שלך. זוהי האזהרה המוקדמת שמישהו ניסה.

מה נראה “טוב”: לפחות רשומה אחת issue (או issuewild) קיימת, שמציינת את הספקים שאתה משתמש בהם בפועל, עם wildcards מוגבלים לספק ספציפי או חסומים. זה הסרגל שבדיקה זו מודדת — היא מחפשת את רשומות ה-CAA של הדומיין שלך על פני כמה resolvers עצמאיים ועוברת כשהיא מוצאת מדיניות issue או issuewild אמיתית. דומיין ללא רשומות CAA כלל מטופל כהדלת הפתוחה שהוא.

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

כיצד לתקן (חינם, ~5 דקות)

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

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

• Let’s Encrypt — בשימוש ע”י מארחים רבים ולוחות בקרה (cPanel, Plesk) → letsencrypt.org
• Cloudflare (אם הוא מנפיק את תעודת הקצה שלך) → letsencrypt.org, digicert.com, comodoca.com, pki.goog, ו-ssl.com (Cloudflare משתמש ב-CAs מרובות מאחורי הקלעים; רשום את אלה שהלוח שלו מציג, או כולם, כדי שחידושים לא ישברו)
• Google Workspace / Google Trust Services → pki.goog
• DigiCert → digicert.com
• Sectigo / Comodo → sectigo.com (ו-comodoca.com)
• Microsoft 365 / Azure — Microsoft משתמש בדרך כלל ב-DigiCert לתעודות מנוהלות → digicert.com (אשר בפורטל שלך)

אם לא בטוח, הסתכל על התעודה הנוכחית שלך בדפדפן (לחץ על המנעול → פרטי תעודה → “הונפקה ע”י”) כדי לראות מי הנפיק אותה.

שלב 2 — התחבר לספק ה-DNS שלך. זה המקום שבו הרשומות של הדומיין שלך חיות — בדרך כלל הרשם שלך, מארח האינטרנט שלך, או Cloudflare. מצא את חלק רשומות ה-DNS ובחר להוסיף רשומה חדשה מסוג CAA (חלק מממשקים מכנים אותה סוג 257).

שלב 3 — הוסף רשומת issue לכל ספק שאתה משתמש בו. עבור Let’s Encrypt, לדוגמה:

example.com.   CAA   0 issue "letsencrypt.org"

הוסף שורת issue אחת לכל ספק לגיטימי. רוב לוחות ה-DNS נותנים לך תיבות נפרדות עבור הדגל (0), התג (issue), והערך (הדומיין של ה-CA) כך שאינך מקליד את השורה כולה ביד.

שלב 4 — שלוט בתעודות wildcard. אם אינך משתמש ב-wildcards, חסום אותם לחלוטין כך שאף אחד לא יכול לקבל אחד בשקט:

example.com.   CAA   0 issuewild ";"

אם אתה כן משתמש ב-wildcards, ציין את הספק במקום: 0 issuewild "letsencrypt.org".

שלב 5 — (מומלץ) הוסף כתובת הודעה. כדי שתקבל הודעה בכל פעם שCA דוחה ניסיון — האזהרה המוקדמת שמישהו ניסה:

example.com.   CAA   0 iodef "mailto:[email protected]"

שלב 6 — שמור ואמת. הרץ dig CAA example.com (או השתמש בכל כלי בדיקת DNS מקוון) ואשר שהרשומות שלך מופיעות. שינויים יכולים לקחת בין כמה דקות לכמה שעות להתפשט באינטרנט. התעודה הקיימת שלך וכל חידוש ממשיכים לעבוד לאורך כל התהליך — CAA שולטת רק בהנפקה חדשה.

הערות פלטפורמה מהירות: ב-Cloudflare, DNS → Records → Add record → סוג CAA. ב-Google Workspace, אתה מנהל DNS ברשם שלך (או Cloud DNS אם אתה משתמש בו) — הוסף שם את רשומות CAA עם pki.goog. ב-Microsoft 365, CAA לא מוגדרת במרכז הניהול של M365; הוסף אותה היכן ש-DNS של הדומיין שלך מתארח, ציין את ה-CA של תעודת מנוהל שלך (בדרך כלל DigiCert). במארחים נפוצים (GoDaddy, Namecheap וכו’), זה בלוח ה-DNS שבו חיות רשומות ה-A וה-MX שלך.

טעויות נפוצות

• רישום ה-CA הלא נכון — או שכחת אחד. הסיכון הגדול ביותר בפועל אינו אבטחה, אלא חסימת החידושים שלך. אם אתה משתמש ביותר מספק אחד (כמו אחד לאתר הראשי ואחר מאחורי Cloudflare), רשום את כולם. כשמסופק, רשום כמה שאתה סומך עליהם ולא פחות מדי.
• הגדרת issue אבל התעלמות מ-wildcards. דומיין שמגביל תעודות רגילות אבל לא אומר שום דבר על wildcards עדיין משאיר את נתיב ה-wildcard החזק יותר פתוח. תמיד הגדר גם issuewild — למספק שלך או ל-";" לחסימתו.
• שים CAA בשם הלא נכון. CAA קוראים ע”י רשות התעודות עבור השם המדויק שמקבל תעודה, תוך עלייה במעלה העץ. הגדרתה בראש הדומיין שלך (ה-”apex”, כמו example.com) היא הפעולה הנכונה — היא מכסה תתי-דומיינים כברירת מחדל אלא אם תת-דומיין מגדיר משלו.
• הנחה שהפלטפורמה כבר עשתה זאת. Cloudflare, Google ו-Microsoft מנהלים תעודות אבל לא מוסיפים רשומות CAA עבורך. אלא אם הוספת אותן, הדומיין שלך עדיין פתוח.
• התייחסות לזה כחד-פעמי ללא ניטור. העברת DNS מאוחרת, שינוי רשם, או “סדר” של רשומות יכולים להוריד בשקט את הגנת ה-CAA שלך. כדאי לבדוק שהיא עדיין שם לאחר כל שינוי DNS.

השכבה הטכנית (מסור זאת לאיש ה-IT שלך)

CAA מוגדרת ב-RFC 8659 ואוכפת תחת דרישות הבסיס של ה-CA/Browser Forum — כל CA בעל אמון ציבורי נדרש לבדוק CAA בזמן הנפקה. רשומות לובשות צורה <flags> <tag> <value>, עם תגים issue, issuewild, ו-iodef. מדיניות issue או issuewild לא ריקה היא מה שמספק בדיקה זו; נוכחות iodef לבדה לא (היא דיווח, לא הרשאה).

בסיס טוב ב-apex:

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

הערות למיישם:

• עלייה בעץ CAA: CAs מעריכים CAA מה-FQDN המבוקש כלפי מעלה ל-apex, עוצרים בשם הראשון שיש לו קבוצת רשומות CAA. רשומה ב-apex לכן מגינה על כל תתי-הדומיינים אלא אם תת-דומיין מפרסם משלו, מה שהוא יכול — שימושי אם תת-דומיין ספציפי משתמש במנפיק שונה.
• הערך ; ב-issuewild אומר “שום CA לא רשאית להנפיק wildcards” — סירוב מפורש. השתמש בו בכל פעם שwildcards אינם חלק מהגדרתך.
• הדגל 0 הוא דגל קריטי-למנפיק; 0 (לא-קריטי) נכון לשימוש רגיל. הימנע מהגדרת הביט הקריטי אלא אם אתה מבין אותו לחלוטין, כי תג קריטי שאינו מובן יכול לגרום ל-CAs שמציתים לסרב להנפקה.
• מנפיקים מרובים: מספר רשומות issue מותרות ומצטברות — רשום כל CA שנמצא לגיטימית בסטאק שלך (כולל ה-CAs האחוריות שספק ה-CDN/קצה שלך משתמש בהם) כדי למנוע כשלי חידוש.
• אימות: dig CAA example.com +short, או בדוק דרך כלי בדיקת CAA של CA/Browser Forum. בדיקה זו עצמה מבצעת שאילתה ל-CAA על פני כמה resolvers עצמאיים (DNS מקומי, ואז Google, Cloudflare ו-Quad9 DNS-over-HTTPS כגיבוי) ומקבלת את התשובה הסמכותית הראשונה, כך שהפסקת resolver יחיד לא תייצר תוצאת “אין CAA” שגויה.
• זיווג עם DNSSEC: CAA אומרת ל-CAs מי רשאי להנפיק; DNSSEC עוצרת את תשובת ה-CAA עצמה מזיוף בזמן שידור. הן משלימות — לדומיינים בעלי ערך גבוה, הרץ את שתיהן.

הגדירו זאת אצל ספק האחסון שלכם

שלב אחר שלב עבור ספקים פופולריים:

• הגדירו CAA ב-GoDaddy
• הגדירו CAA ב-Namecheap
• הגדירו CAA ב-Cloudflare
• הגדירו CAA ב-AWS Route 53

שאלות נפוצות