📘 תיעוד 86

העברת תעודה לשרת

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

#הוספת כותרות Client-Cert ו-Client-Cert-Chain (RFC 9440)

RFC 9440 מגדיר את שדות כותרות ה-HTTP Client-Cert ו-Client-Cert-Chain להעברת מידע על תעודת לקוח לשרתי המקור. אפשר לבנות את הכותרות האלה באמצעות כללי שינוי כותרות בקשה עם שדות Ruleset Engine הבאים:

• cf.tls_client_auth.cert_rfc9440: תעודת העלה של הלקוח מקודדת בעיצוב RFC 9440 (ראו את ההפניה).
• cf.tls_client_auth.cert_chain_rfc9440: שרשרת התעודות (בלי תעודת העלה) מקודדת בעיצוב RFC 9440 (ראו את ההפניה).

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

#שיקולי אבטחה

חשוב

לפני בניית כותרות Client-Cert או Client-Cert-Chain, יש לטפל בחששות האבטחה הבאים. אי טיפול בהם עלול לחשוף את שרת המקור לנתוני תעודה מזויפים או שלא אומתו.

השדות cert_rfc9440 ו-cert_chain_rfc9440 מאוכלסים בלי קשר לתוצאת אימות התעודה. המשמעות היא שלקוח יכול להציג תעודה לא תקינה, שפג תוקפה, או בחתימה עצמית, והשדות עדיין יכילו את נתוני התעודה המקודדים. תמיד יש לבדוק את השדות הבאים לפני שמסתמכים על הערכים:

• cf.tls_client_auth.cert_verified: מחזיר true כאשר תעודת הלקוח תקינה.
• cf.tls_client_auth.cert_revoked: מחזיר true כאשר תעודת הלקוח בוטלה.

לקוח יכול גם לכלול כותרות Client-Cert או Client-Cert-Chain משלו בבקשה כדי להזריק ערכים שרירותיים. כמתואר בשיקולי האבטחה של RFC 9440, יש להסיר ללא תנאי כל כותרות Client-Cert ו-Client-Cert-Chain קיימות מבקשות נכנסות, בלי קשר לתקינות התעודה. זה מונע מלקוח להזריק נתוני תעודה מזויפים ששרת המקור יסמוך עליהם.

ראו הפעלת mTLS לפרטים על הגדרת mTLS ואימות תעודות.

#מגבלות גודל

תעודת העלה המקודדת מוגבלת ל-10 KiB, והשרשרת המקודדת מוגבלת ל-16 KiB. אם הערך המקודד חורג מהמגבלה, השדה המתאים מכיל מחרוזת ריקה. השתמשו בשדות הבאים כדי לבדוק מצב זה:

• cf.tls_client_auth.cert_rfc9440_too_large: מחזיר true כאשר התעודה המקודדת חורגת מ-10 KiB.
• cf.tls_client_auth.cert_chain_rfc9440_too_large: מחזיר true כאשר השרשרת המקודדת חורגת מ-16 KiB.

#דוגמה לכללי Transform

כאן מוצגת דוגמה לשימוש מאובטח בשדות האלה כדי לבנות כותרות Client-Cert ו-Client-Cert-Chain מהימנות שיועברו לשרת המקור. שרת המקור יכול אז להסתמך על נוכחות הכותרות כדי להיות בטוח שהלקוח הציג תעודה תקינה. הערה: אפשר להשמיט את כותרת Client-Cert-Chain כאשר הלקוח לא הציג תעודות ביניים (רק תעודת עלה).

צריך ליצור את כללי שינוי כותרות הבקשה הבאים. כללי ה-Remove חייבים להיות לפני כללי ה-Set dynamic, כדי שכותרות שהוזרקו על ידי הלקוח יוסרו בכל בקשה לפני שערכי האימות נקבעים.

#כלל 1: הסרת כותרת Client-Cert

הכלל הזה מסיר ללא תנאי כל כותרת Client-Cert שנשלחה על ידי הלקוח.

טקסט ב-Expression Editor:

true

הפעולה שנבחרה תחת Modify request header: Remove

Header name: Client-Cert

#כלל 2: הסרת כותרת Client-Cert-Chain

הכלל הזה מסיר ללא תנאי כל כותרת Client-Cert-Chain שנשלחה על ידי הלקוח.

טקסט ב-Expression Editor:

true

הפעולה שנבחרה תחת Modify request header: Remove

Header name: Client-Cert-Chain

#כלל 3: הגדרת כותרת Client-Cert

הכלל הזה מגדיר את כותרת Client-Cert רק כאשר הלקוח הציג תעודה תקינה, שלא בוטלה, ובתוך מגבלת הגודל.

טקסט ב-Expression Editor:

cf.tls_client_auth.cert_verified
and not cf.tls_client_auth.cert_revoked
and not cf.tls_client_auth.cert_rfc9440_too_large

הפעולה שנבחרה תחת Modify request header: Set dynamic

Header name: Client-Cert

Value: cf.tls_client_auth.cert_rfc9440

#כלל 4: הגדרת כותרת Client-Cert-Chain

הכלל הזה מגדיר את כותרת Client-Cert-Chain רק כאשר הלקוח הציג תעודה תקינה ושלא בוטלה, והשרשרת אינה ריקה ובתוך מגבלת הגודל.

טקסט ב-Expression Editor:

cf.tls_client_auth.cert_verified
and not cf.tls_client_auth.cert_revoked
and cf.tls_client_auth.cert_chain_rfc9440 ne ""
and not cf.tls_client_auth.cert_chain_rfc9440_too_large

הפעולה שנבחרה תחת Modify request header: Set dynamic

Header name: Client-Cert-Chain

Value: cf.tls_client_auth.cert_chain_rfc9440

#Cloudflare Workers

אפשר גם לבנות כותרות RFC 9440 ב-Cloudflare Worker באמצעות מאפייני tlsClientAuth בבקשה הנכנסת.

אותם שיקולי אבטחה שצוינו למעלה חלים גם כאן.

#העברת תעודת לקוח (legacy)

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

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

זהירות

תהליך זה זמין רק בחשבונות עם Cloudflare Access.

#Cloudflare API

הגישה הנפוצה ביותר להעברת תעודה היא שימוש ב-Cloudflare API כדי לעדכן את הגדרות שם המארח של תעודת mTLS.

הרשאות אסימון API נדרשות

נדרשת לפחות אחת מההרשאות האסימון הבאות:

• Access: Mutual TLS Certificates Write

עדכון הגדרות שם המארח של תעודת mTLS, bash

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/certificates/settings" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"settings": [
				{
						"hostname": "<HOSTNAME>",
						"china_network": false,
						"client_certificate_forwarding": true
				}
		]
	}'

לאחר ש-client_certificate_forwarding מוגדר ל-true, כל בקשה בתוך חיבור mTLS תכלול כעת את הכותרות הבאות:

• Cf-Client-Cert-Der-Base64
• Cf-Client-Cert-Sha256

הערה

הכותרות Cf-Client-Cert-Der-Base64 ו-Cf-Client-Cert-Sha256 הן מנגנון קנייני של Cloudflare. לגישה תקנית, השתמשו בכותרות Client-Cert ו-Client-Cert-Chain של RFC 9440.

#Managed Transforms

אפשר גם לשנות כותרות תגובת HTTP באמצעות Managed Transforms כדי להעביר כותרות TLS client auth.

#Cloudflare Workers

בנוסף, Workers יכולים לספק פרטים על תעודת הלקוח.

const tlsHeaders = {
	"X-CERT-ISSUER-DN": request.cf.tlsClientAuth.certIssuerDN,
	"X-CERT-SUBJECT-DN": request.cf.tlsClientAuth.certSubjectDN,
	"X-CERT-ISSUER-DN-L": request.cf.tlsClientAuth.certIssuerDNLegacy,
	"X-CERT-SUBJECT-DN-L": request.cf.tlsClientAuth.certSubjectDNLegacy,
	"X-CERT-SERIAL": request.cf.tlsClientAuth.certSerial,
	"X-CERT-FINGER": request.cf.tlsClientAuth.certFingerprintSHA1,
	"X-CERT-VERIFY": request.cf.tlsClientAuth.certVerify,
	"X-CERT-NOTBE": request.cf.tlsClientAuth.certNotBefore,
	"X-CERT-NOTAF": request.cf.tlsClientAuth.certNotAfter,
};