📘 תיעוד 90

פתרון בעיות

אם השאילתה מחזירה שגיאה גם לאחר הגדרה והטמעה של תעודת SSL של לקוח, בדקו את ההגדרות הבאות.

הערה

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

#בדיקת לחיצת היד של SSL/TLS

בטרמינל, השתמשו בפקודה הבאה כדי לבדוק אם אפשר ליצור בהצלחה חיבור SSL/TLS בין הלקוח לנקודת הקצה של ה-API.

curl --verbose --cert /path/to/certificate.pem --key /path/to/key.pem https://your-api-endpoint.com

אם לא ניתן להשלים את לחיצת היד של SSL/TLS, בדקו אם התעודה והמפתח הפרטי נכונים. אם לחיצת היד הושלמה אבל הבקשות עדיין חסומות, אשרו ש-Cloudflare מאמת את תעודת הלקוח.

#בדיקת מארחי mTLS

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

#סקירת כללי mTLS

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

1. בלוח הבקרה של Cloudflare, עברו לעמוד Security rules. עברו אל Security rules ↗

2. בכלל מסוים, בחרו Edit.

3. באותו כלל, בדקו אם:

   • ה-Expression Preview נכון.

   • שם המארח, אם הוגדר, תואם לנקודת הקצה של ה-API שלכם. לדוגמה, עבור נקודת הקצה של ה-API api.trackers.ninja/time, הכלל אמור להיראות כך:

     העתק

     (http.host in {"api.trackers.ninja"} and not cf.tls_client_auth.cert_verified)

4. כדי לערוך את הכלל, השתמשו בממשק המשתמש או בחרו Edit expression.

#איתור באגים מתקדם

אפשר להשתמש ב-Cloudflare Workers כדי לאתר כשלים באימות תעודת לקוח.

זהירות

אל תפעילו את global_fetch_strictly_public עבור ה-Worker הזה. כשהאפשרות מופעלת, fetch(request) יכול להפעיל את ה-Worker שוב במקום להגיע ל-origin.

1. צרו Worker שרושם מאפייני cf של בקשה נכנסת ומעביר כל בקשה ל-origin שלכם:

   src/index.jsjs

   העתק

   export default {
       async fetch(request) {
           console.info({ message: JSON.stringify(request.cf, null, 2) });
           return fetch(request);
       },
   };

   src/index.tsts

   העתק

   export default {
     async fetch(request): Promise<Response> {
       console.info({ message: JSON.stringify(request.cf, null, 2) });
       return fetch(request);
     },
   } satisfies ExportedHandler;

2. שייכו את ה-Worker לשם המארח שבו mTLS מופעל באמצעות נתיב Worker.

3. שלחו בקשות לשם המארח ו/או לנתיב שהוגדרו, עם שליחת תעודת הלקוח של mTLS ובלי שליחה.

4. בלוח הבקרה של Observability, השוו את ערכי tlsClientAuth שנרשמו לערכים הצפויים. עברו אל Observability ↗

• תעודה תקינה

  העתק

  "tlsClientAuth": {
    "certPresented": "1",
    "certVerified": "SUCCESS",
  },

• תעודה לא תקינה (לדוגמה, תעודות בחתימה עצמית)

  העתק

  "tlsClientAuth": {
    "certPresented": "1",
    "certVerified": "FAILED:self signed certificate",
  },

• בלי תעודה

  העתק

  "tlsClientAuth": {
    "certPresented": "0",
    "certVerified": "NONE",
  },

#הגעתם למכסת התעודות

#CA בניהול Cloudflare

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

כדי להציג ולבטל תעודות, ראו את API של תעודות לקוח.

#הבאת CA משלכם (BYOCA)

כל חשבון Enterprise יכול להעלות עד חמש תעודות CA עבור BYOCA. המכסה הזו משותפת ל-API Shield, Workers mTLS ו-Cloudflare Gateway.

אם חורגים מהמגבלה הזו, ה-API מחזיר:

{
  "code": 1489,
  "message": "Hit maximum CA cert allocation."
}

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

הערה

רשויות CA שהועלו דרך Cloudflare Access משתמשות במכסה נפרדת. השגיאה 12130 ("maximum number of certificates has been reached") ב-Access מתייחסת למגבלת התעודות הייחודית ל-Access, ולא למכסת BYOCA המתוארת ב-הבאת CA משלכם (BYOCA).

#שגיאות בהעלאת תעודת BYOCA

בעת העלאת תעודת CA עבור הבאת CA משלכם (BYOCA), התעודה חייבת לעמוד בדרישות הבאות:

• תעודת ה-CA יכולה להיות מרשות CA מהימנה ציבורית או בחתימה עצמית.
• בתעודה, ב-Basic Constraints, המאפיין CA חייב להיות מוגדר כ-TRUE.
• התעודה חייבת להשתמש באחד מאלגוריתמי החתימה המפורטים להלן:

אלגוריתמי חתימה מותרים:

x509.SHA1WithRSA

x509.SHA256WithRSA

x509.SHA384WithRSA

x509.SHA512WithRSA

x509.ECDSAWithSHA1

x509.ECDSAWithSHA256

x509.ECDSAWithSHA384

x509.ECDSAWithSHA512

#העלו את תעודת ה-CA, לא תעודת עלה

התעודה שאתם מעלים חייבת להיות תעודת CA, כלומר חייבות להיות לה בהרחבות Basic Constraints: CA=TRUE. העלו את תעודות ה-CA בשרשרת של תעודות הלקוח, ולא את תעודת הלקוח עצמה.

סיבה נפוצה לכשל בהעלאה היא העלאת תעודת עלה (לקוח) במקום תעודת ה-CA. אם שרשרת התעודות שלכם היא Root CA → Intermediate CA → Client certificate, העלו את שרשרת ה-CA המלאה בקובץ PEM יחיד, כאשר ה-Intermediate CA מופיע ואחריו ה-Root CA.

אם מעלים רק את ה-Intermediate CA, אימות mTLS נכשל בכל בקשה, גם כאשר שם המארח משויך ל-CA. ביומני בקשות ה-HTTP, ClientMTLSAuthCertFingerprint תואם לתעודת הלקוח הצפויה, אבל ClientMTLSAuthStatus הוא unknown.

כדי לאשר שתעודה היא תעודת CA, הריצו את הפקודה הבאה על כל תעודה בשרשרת:

openssl x509 -in certificate.pem -noout -text | grep -A1 "Basic Constraints"

הפלט צריך לכלול CA:TRUE. אם מופיע CA:FALSE או שהשדה חסר, התעודה אינה תעודת CA ולא ניתן להעלות אותה.

#אלגוריתם חתימה לא נתמך

תעודת ה-CA חייבת להשתמש באחד מאלגוריתמי החתימה הבאים:

• SHA1WithRSA, SHA256WithRSA, SHA384WithRSA, SHA512WithRSA
• ECDSAWithSHA1, ECDSAWithSHA256, ECDSAWithSHA384, ECDSAWithSHA512

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

#תוכן PEM לא תקין

השדה certificates בבקשת ההעלאה חייב להכיל תוכן PEM תקין ועם תיחום נכון. ודאו שהתעודה מתחילה ב------BEGIN CERTIFICATE----- ומסתיימת ב------END CERTIFICATE-----. אל תכללו מפתחות פרטיים או בקשות לחתימת תעודה בשדה זה.