📘 תיעוד 20

עדיפות תעודות ושמות מארח

עודכן לאחרונה: 16 באפריל 2026

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

---

#פריסת תעודה

עבור כל שם מארח (hostname) נתון, Cloudflare משתמשת בסדר הבא כדי לקבוע איזו תעודה (והגדרות TLS משויכות) להחיל על אותו שם מארח:

1. ספציפיות שם מארח (Hostname specificity): תעודת תת-דומיין ספציפית (www.example.com) תקבל קדימות על פני תעודת תו כללי (*.example.com) עבור בקשות אל www.example.com.

2. ספציפיות אזור (Zone specificity): תעודת תת-דומיין ספציפית (www.example.com) תקבל קדימות על פני תעודת שם מארח מותאם אישית (custom hostname) אם הדומיין פעיל כאזור (zone) ב-Cloudflare.

3. עדיפות תעודה (Certificate priority): אם שם המארח זהה, סוגים מסוימים של תעודות מקבלים קדימות על פני אחרים.

   עדיפות	סוג תעודה
   1	Keyless SSL
   2	Custom Legacy
   3	Custom Modern
   4	Custom Hostname (Cloudflare for SaaS)
   5	Advanced
   6	Advanced - Total TLS
   7	Universal

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

הערה:

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

---

#הגשת תעודה

Cloudflare משתמשת בסדר הבא כדי לקבוע את התעודה וההגדרות שבהן ייעשה שימוש במהלך לחיצת יד של TLS:

1. התאמת SNI (SNI match): תעודות והגדרות שתואמות לשם מארח ה-SNI במדויק מקבלות קדימות.
2. התאמת תו כללי ב-SNI (SNI wildcard match): אם אין התאמה מדויקת בין שם המארח לשם מארח ה-SNI, Cloudflare משתמשת בתעודות ובהגדרות שתואמות לתו כללי (wildcard) ב-SNI.
3. כתובת IP (IP address): אם לא מוצג SNI, Cloudflare משתמשת בתעודה בהתבסס על כתובת ה-IP (שם המארח יכול לתמוך בלחיצות יד של TLS שמתבצעות ללא SNI).

---

#עדיפות שמות מארח

כאשר קיימות מספר רשומות DNS עם פרוקסי (proxied) עבור שם מארח, במספר אזורים, בדרך כלל עקב Cloudflare for SaaS, רק רשומה אחת תשלוט בהגדרות האזור ובשרת המקור (origin server) המשויך.

Cloudflare קובעת עדיפות זו בסדר הבא, בהנחה שכל רשומה קיימת ומוגדרת עם פרוקסי (orange-clouded):

1. התאמה מדויקת של שם מארח (Exact hostname match):
   1. New custom hostname (שייך לספק SaaS)
   2. Legacy custom hostname (שייך לספק SaaS)
   3. DNS (שייך לאזור ה-DNS הלוגי)
2. התאמת תו כללי של שם מארח (Wildcard hostname match):
   1. DNS (שייך לאזור ה-DNS הלוגי)
   2. New custom hostname (שייך לספק SaaS)

אם רשומת משאב של שם מארח אינה מוגדרת עם פרוקסי (gray-clouded) עבור אזור ב-Cloudflare, הגדרות האזור הזה אינן מוחלות, ובמקומן מוחלות כל ההגדרות שהוגדרו במקור המשויך. מקור זה יכול להיות אזור אחר ב-Cloudflare או כל שרת אחר.

#תרחישים לדוגמה

#תרחיש 1

Customer1 משתמש ב-Cloudflare כ-DNS סמכותי (authoritative DNS) עבור האזור shop.example.com. Customer2 הוא ספק SaaS שיוצר ומאמת בהצלחה את ה-custom hostname החדש shop.example.com. לאחר מכן, התעבורה מתחילה להיות מנותבת דרך האזור של Customer2:

• אם Customer1 רוצה להחזיר לעצמו את השליטה באזור שלו, Customer1 יוצר קשר עם Customer2 ומבקש ממנו למחוק את רשומת ה-custom hostname. על Customer1 לוודא כי יעד הרשומה שלו מעודכן ליעד שאינו יעד ספק ה-SaaS, אחרת Customer1 יקבל שגיאת 1014.
• אם ל-Customer1 כבר יש רשומה עם פרוקסי עבור www.example.com כאשר Customer2 יוצר ומאמת custom hostname חדש www.example.com, חל O2O.
• אם ל-Customer1 כבר יש רשומה עם פרוקסי עבור www.example.com בהגדרת legacy custom hostname (עם ספק SaaS אחר, Customer3), ו-Customer2 יוצר ומאמת custom hostname חדש עם תו כללי עבור *.example.com, ה-legacy custom hostname בפלטפורמה של Customer3 מקבל קדימות בשל התאמה מדויקת של שם מארח.

#תרחיש 2

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

לקוח זה משתמש גם בספק SaaS שמשתמש ב-Cloudflare for SaaS. ספק ה-SaaS משתמש בתוכנית Cloudflare Enterprise.

אם הספק משתמש ב-custom hostname עם תו כללי (wildcard), אזי מגבלות התוכנית של הלקוח המקורי יקבלו קדימות על פני מגבלות התוכנית של הספק (Cloudflare תתייחס לאזור כאזור Free). כדי להחיל את מגבלות ה-Enterprise דרך Cloudflare for SaaS, האזור של הלקוח המקורי יצטרך להשתמש ברשומת DNS-only (DNS בלבד), או שספק ה-SaaS יצטרך להשתמש בהתאמה מדויקת של שם מארח.