📘 תיעוד 25

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

העברת פרטי תעודת לקוח לשרת המקור שלך.

עדכון אחרון: 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: תעודת העלה (leaf) של הלקוח, מקודדת בפורמט של 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. ההגדרה הזו עוזרת לעיתים קרובות לרישום בשרת (logging).

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

זהירות

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

#Cloudflare API

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

הרשאות נדרשות לטוקן API

נדרשת לפחות אחת מההרשאות הטוקן הבאות:

• Access: Mutual TLS Certificates Write

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 headers.

#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,
};