תיעוד 22

אימות TLS הדדי (Mutual TLS)

עודכן לאחרונה: 10 בספטמבר 2026.

#זמינות

Access mTLS זמין בתוכניות Enterprise ובתוכניות pay-as-you-go של Zero Trust. הוא אינו כלול בתוכנית Free. לקוחות בתוכנית Free יכולים להשתמש ב-טוקני שירות (service tokens) כדי לאמת מערכות אוטומטיות.

דף זה מכסה את Access mTLS עבור מדיניות Service Auth. התכונה Zone-level mTLS היא תכונה נפרדת עם זמינות תוכניות שונה.

אימות Mutual TLS (mTLS) דורש הן מהלקוח והן מהשרת להציג תעודות במהלך לחיצת היד של TLS (TLS handshake). במימוש של Cloudflare Access, ה-CA שאתה מעלה משמש לאימות תעודת הלקוח (אימות תעודת השרת מנוהל על ידי TLS סטנדרטי). הפיצ'ר Access mTLS משרת שתי מטרות:

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

כאשר אתה מעלה רשות אישורים ראשית (root CA) אל Access, רק בקשות מהתקנים בעלי תעודת לקוח תואמת מורשות לעבור. כאשר בקשה מגיעה אל היישום, Access מבקש מהלקוח להציג תעודה. אם הלקוח אינו יכול להציג תעודה תקפה, הבקשה נחסמת. אם הלקוח מציג תעודה תקפה, Access משלים החלפת מפתחות (key exchange) לצורך אימות.

תרשים לחיצת יד של mTLS

חשוב: תעודת ה-mTLS משמשת אך ורק לאימות תעודת הלקוח. היא אינה קובעת את תעודת ה-SSL המוצגת במהלך server hello.

#אכיפת אימות mTLS

#דרישות מוקדמות

יישום Access עבור שם המארח (hostname) שברצונך לאבטח באמצעות mTLS.
גורם מנפיק תעודות (CA) שמנפיק תעודות לקוח עבור ההתקנים שלך:
- תעודת ה-CA יכולה להיות מ-CA מהימן ציבורית או בחתימה עצמית (self-signed).
- בתוך Basic Constraints של התעודה, המאפיין CA חייב להיות מוגדר כ-TRUE.
- התעודה חייבת להשתמש באחד מאלגוריתמי החתימה המפורטים להלן:
אלגוריתמי חתימה מורשים:
- x509.SHA1WithRSA
- x509.SHA256WithRSA
- x509.SHA384WithRSA
- x509.SHA512WithRSA
- x509.ECDSAWithSHA1
- x509.ECDSAWithSHA256
- x509.ECDSAWithSHA384
- x509.ECDSAWithSHA512

#הוספת mTLS ליישום ה-Access שלך

ב-לוח הבקרה של Cloudflare, עבור אל Zero Trust > Access controls > Service credentials > Mutual TLS.
בחר Add mTLS Certificate.
הזן שם כלשהו עבור ה-root CA.
תחת Certificate content, הדבק את התוכן של ה-root CA שלך.
אם תעודת הלקוח נחתמה ישירות על ידי ה-root CA, עליך להעלות רק את ה-root. אם תעודת הלקוח נחתמה על ידי תעודת ביניים (intermediate certificate), עליך להעלות את כל שרשרת ה-CA (ביניים ו-root). לדוגמה:

-----BEGIN CERTIFICATE-----  
<intermediate.pem>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----  
<rootCA.pem>
-----END CERTIFICATE-----

אל תכלול תעודות שרת של SSL/TLS, Access משתמש בשרשרת ה-CA אך ורק כדי לאמת את החיבור בין התקן המשתמש לבין Cloudflare. 5. תחת Associated hostnames, הזן את שמות הדומיין המלאים (FQDN) שישתמשו בתעודה זו.
שמות FQDN אלה יהיו שמות המארח המשמשים עבור המשאבים המוגנים ב-מדיניות Access. עליך לשייך את ה-Root CA לשם ה-FQDN שבו משתמש היישום המוגן. 6. שמור את המדיניות. 7. עבור אל Access controls > Policies. 8. צור מדיניות Access באמצעות אחד מ-הבוררים (selectors) הבאים:

Valid Certificate: כל תעודת לקוח שיכולה לעבור אימות מול ה-Root CA תורשה להמשיך.
Common Name: רק תעודות לקוח עם Common Name ספציפי יורשו להמשיך.

אם מדובר בלקוח שאינו צריך להתחבר דרך IdP, הגדר את ה-Action של המדיניות ל-Service Auth.

דוגמה למדיניות mTLS

Action	Rule type	Selector	Value
Service Auth	Include	Common Name	John Doe

שמור את המדיניות, ולאחר מכן עבור אל Access controls > Applications.
בחר את היישום שעליו ברצונך לאכוף mTLS ובחר Configure. היישום חייב להיכלל ברשימת Associated hostnames משלב 5.
בלשונית Policies, הוסף את מדיניות ה-mTLS שלך.
שמור את היישום.

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

#בדיקת mTLS

#בדיקה באמצעות cURL

כדי לבדוק את היישום המוגן על ידי מדיניות mTLS:

ראשית, נסה להפעיל curl לאתר ללא תעודת לקוח. דוגמת פקודת curl זו מיועדת לאתר example.com שמוגדרים עבורו יישום ומדיניות Access עבור https://auth.example.com:

curl -sv https://auth.example.com

ללא תעודת לקוח בבקשה, מוצגת תגובת 403 forbidden ולא ניתן לגשת לאתר. 2. כעת, הוסף את תעודת הלקוח ואת המפתח שלך לבקשה:

curl -sv https://auth.example.com --cert example.pem --key key.pem

כאשר תהליך האימות מסתיים בהצלחה, כותרת CF_Authorization Set-Cookie מוחזרת בתגובה.

זהירות: Cloudflare Gateway אינו יכול לבדוק תעבורה אל דומיינים המוגנים באמצעות mTLS. אם בהתקן מופעל Cloudflare One Client והוא מעביר בקשות HTTP דרך Gateway, הגישה תיחסם אלא אם תבצע מעקף לבדיקת HTTP (bypass HTTP inspection) עבור הדומיין.

#בדיקה בדפדפן

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

הדוגמה הבאה מדגימה כיצד להוסיף תעודת לקוח ל-keychain של מערכת macOS:

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

נווט אל הספרייה המכילה את תעודת הלקוח ואת המפתח.
1. פתח את הקובץ client.pem ב-Keychain Access. אם תתבקש, הזן את הסיסמה המקומית שלך.
2. תחת Keychain, בחר באפשרות הגישה המתאימה לצרכיך ובחר Add.
3. ברשימת התעודות, אתר את התעודה שהותקנה זה עתה. Keychain Access יסמן תעודה זו כלא מהימנה. לחץ לחיצה ימנית על התעודה ובחר Get Info.
4. בחר Trust. תחת When using this certificate, בחר Always Trust.

בהנחה שהדפדפן שלך משתמש במאגר המערכת של macOS, כעת תוכל להתחבר ליישום ה-mTLS דרך הדפדפן.

#יצירת תעודות mTLS

ניתן להשתמש בכלי תשתית מפתח ציבורי (PKI) בקוד פתוח כדי ליצור תעודות לבדיקת תכונת ה-mTLS ב-Cloudflare Access.

#OpenSSL

סעיף זה מכסה כיצד להשתמש ב-OpenSSL כדי ליצור תעודת root ותעודת ביניים (intermediate), ולאחר מכן להנפיק תעודות לקוח שיכולות לבצע אימות מול שרשרת ה-CA.

#יצירת ה-root CA

צור את המפתח הפרטי של ה-root CA:

openssl genrsa -aes256 -out rootCA.key 4096

כאשר תתבקש, הזן סיסמה לשימוש עם rootCA.key. 2. צור תעודת root בעלת חתימה עצמית בשם rootCA.pem:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem

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

#יצירת תעודת ביניים

צור את המפתח הפרטי של ה-intermediate CA:

openssl genrsa -aes256 -out intermediate.key 4096

כאשר תתבקש, הזן סיסמה לשימוש עם intermediate.key. 2. צור בקשת חתימה על תעודה (CSR) עבור תעודת הביניים:

openssl req -new -sha256 -key intermediate.key -out intermediate.csr

תתבקש להזין את סיסמת המפתח הפרטי שלך ולמלא מספר שדות אופציונליים. למטרות בדיקה, ניתן להשאיר את השדות האופציונליים ריקים. 3. צור קובץ הרחבת CA בשם v3_intermediate_ca.ext. לדוגמה:

subjectKeyIdentifier = hash  
authorityKeyIdentifier = keyid:always,issuer  
basicConstraints = critical, CA:true  
keyUsage = critical, cRLSign, keyCertSign

ודא ש-basicConstraints כולל את המאפיין CA:true. מאפיין זה מאפשר לתעודת הביניים לפעול כ-CA ולחתום על תעודות לקוח. 4. חתום על תעודת הביניים באמצעות ה-root CA:

openssl x509 -req -in intermediate.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out intermediate.pem -days 1825 -sha256 -extfile v3_intermediate_ca.ext

#יצירת קובץ שרשרת CA

אחד את תעודת הביניים ותעודת ה-root לקובץ יחיד:

cat intermediate.pem rootCA.pem > ca-chain.pem

תעודת הביניים צריכה להיות בראש הקובץ, ולאחריה התעודה החותמת שלה. 2. העלה את התוכן של ca-chain.pem אל Cloudflare Access. להוראות, עיין בסעיף הוספת mTLS ליישום ה-Access שלך.

#יצירת תעודת לקוח

צור מפתח פרטי עבור הלקוח:

openssl genrsa -out client.key 2048

צור CSR עבור תעודת הלקוח:

openssl req -new -key client.key -out client.csr

תתבקש למלא מספר שדות אופציונליים. למטרות בדיקה, תוכל להגדיר את Common Name לערך כמו John Doe. 3. חתום על תעודת הלקוח באמצעות תעודת הביניים:

openssl x509 -req -in client.csr -CA intermediate.pem -CAkey intermediate.key -CAcreateserial -out client.pem -days 365 -sha256

אמת את תעודת הלקוח מול שרשרת התעודות:

openssl verify -CAfile ca-chain.pem client.pem

client.pem: OK

כעת תוכל להשתמש בתעודת הלקוח (client.pem) ובמפתח שלה (client.key) כדי לבחון את mTLS.

#Cloudflare PKI

מדריך זה משתמש ב-ערכת כלי ה-PKI של Cloudflare כדי ליצור root CA ותעודות לקוח מקובצי JSON.

#1. התקנת תלויות

התהליך דורש שתי חבילות מתוך ערכת כלי ה-PKI של Cloudflare:

cf-ssl
cfssljson

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

#2. יצירת ה-root CA

צור ספרייה חדשה לאחסון ה-root CA.

בתוך אותה ספרייה, צור שני קבצים חדשים:

CSR: צור קובץ בשם ca-csr.json והוסף את בלוק ה-JSON הבא, ולאחר מכן שמור את הקובץ:

{  
    "CN": "Access Testing CA",  
    "key": {  
        "algo": "rsa",  
        "size": 4096  
    },  
    "names": [  
        {  
            "C": "US",  
            "L": "Austin",  
            "O": "Access Testing",  
            "OU": "TX",  
            "ST": "Texas"  
        }  
    ]  
}

config: צור קובץ בשם ca-config.json והוסף את בלוק ה-JSON הבא, ולאחר מכן שמור את הקובץ:

{  
    "signing": {  
        "default": {  
            "expiry": "8760h"  
        },  
        "profiles": {  
            "server": {  
                "usages": ["signing", "key encipherment", "server auth"],  
                "expiry": "8760h"  
            },  
            "client": {  
                "usages": ["signing", "key encipherment", "client auth"],  
                "expiry": "8760h"  
            }  
        }  
    }  
}

כעת, הרץ את הפקודה הבאה כדי ליצור את ה-root CA עם קבצים אלה:

cfssl gencert -initca ca-csr.json | cfssljson -bare ca

הפקודה תפיק תעודת root (ca.pem) ואת המפתח שלה (ca-key.pem).

ls

ca-config.json ca-csr.json ca-key.pem ca.csr  ca.pem

העלה את התוכן של ca.pem אל Cloudflare Access. להוראות, עיין בסעיף הוספת mTLS ליישום ה-Access שלך.

#3. יצירת תעודת לקוח

כדי ליצור תעודת לקוח שתבצע אימות מול ה-root CA שהועלה:

צור קובץ בשם client-csr.json והוסף את בלוק ה-JSON הבא:

{  
	"CN": "James Royal",  
	"hosts": [""],  
	"key": {  
		"algo": "rsa",  
		"size": 4096  
	},  
	"names": [  
		{  
			"C": "US",  
			"L": "Austin",  
			"O": "Access",  
			"OU": "Access Admins",  
			"ST": "Texas"  
		}  
	]  
}

כעת, השתמש בפקודה הבאה כדי ליצור תעודת לקוח עם ערכת כלי ה-PKI של Cloudflare:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem  -config=ca-config.json -profile=client client-csr.json | cfssljson -bare client

הפקודה תפיק קובץ תעודת לקוח (client.pem) ואת המפתח שלו (client-key.pem). כעת תוכל להשתמש בקבצים אלה כדי לבחון את mTLS.

#יצירת רשימת ביטול תעודות (CRL)

באפשרותך להשתמש בערכת כלי ה-PKI של Cloudflare גם כדי ליצור רשימת ביטול תעודות (CRL). רשימה זו תכיל תעודות לקוח שבוטלו.

קבל את המספר הסידורי מתוך תעודת הלקוח שנוצרה קודם לכן. הוסף מספר סידורי זה, או כל מספר אחר שברצונך לבטל, בפורמט הקסדצימלי (hex) בקובץ טקסט. דוגמה זו משתמשת בקובץ בשם serials.txt.
צור את ה-CRL באמצעות הפקודה הבאה:

cfssl gencrl serials.txt ../mtls-test/ca.pem ../mtls-test/ca-key.pem | base64 -D > ca.crl

תצטרך להוסיף את ה-CRL לשרת שלך או לאכוף את הביטול ב-Cloudflare Worker. סקריפט Worker לדוגמה ניתן למצוא ב-מאגר ה-GitHub של Cloudflare.

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

RFC 9440 מגדיר את שדות כותרות ה-HTTP בשם Client-Cert ו-Client-Cert-Chain עבור העברת מידע על תעודת הלקוח לשרתי המקור (origin servers). ניתן לבנות כותרות אלו באמצעות כללי שינוי כותרות בקשה (request header modification rules) עם שדות ה-Ruleset Engine הבאים:

cf.tls_client_auth.cert_rfc9440: תעודת העלה (leaf certificate) של הלקוח בקידוד פורמט 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 (Enable 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. תצורה זו מועילה לעיתים קרובות עבור רישום ביומנים של השרת (server logging).

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

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

#Cloudflare API

הגישה הנפוצה ביותר להעברת תעודה היא שימוש ב-Cloudflare API כדי לעדכן את הגדרות שם המארח של תעודת 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,
};

#מגבלות ידועות

mTLS אינו פועל כרגע עבור:

אתר Cloudflare Pages המוגש ב-דומיין מותאם אישית (custom domain)
דלי ציבורי (public bucket) של Cloudflare R2 המוגש ב-דומיין מותאם אישית (custom domain)

#התראות עבור תעודות Mutual TLS

Cloudflare תשלח את ההתראות הבאות לפני שתוקף תעודות ה-mutual TLS שלך יפוג:

התראת תפוגת תעודת Access mTLS (Access mTLS Certificate Expiration Alert)

למי זה מיועד?

לקוחות Access המשתמשים בתעודות לקוח עבור אימות mutual TLS. התראה זו תישלח 30 ו-14 ימים לפני תפוגת התעודה.

אפשרויות / מסננים נוספים

אין.

כלול עם

רכישת Access ו/או Cloudflare for SaaS.

מה עליך לעשות אם קיבלת התראה כזו?

העלה תעודה מחודשת.