14.4.4. אישורים חתומים-CA (מהימנים ציבורית)

אישורים עצמי-חתומים עובדים כשאתה שולט בשני הקצוות. אם במקום זאת לקוחות שרירותיים (דפדפנים, טלפונים, תוכנה של צד שלישי) חייבים להתחבר למצלמה מבלי שיורו להם לסמוך על אישור מותאם אישית, האישור חייב להיות חתום על ידי רשות אישורים (CA) ציבורית שאותם לקוחות כבר סומכים עליה. קוד ה-TLS על המצלמה זהה למקרה העצמי-חתום – load_cert_chain עם אישור ומפתח בצורת DER – רק האופן שבו אתה משיג את האישור הזה משתנה.

הנקודה החשובה ביותר: אתה מייצר את המפתח הפרטי בעצמך והוא לעולם אינו עוזב את המחשב שלך. ה-CA לעולם אינה רואה אותו. מה שאתה שולח ל-CA הוא בקשת חתימה על אישור (CSR) – קובץ קטן המכיל את המפתח הציבורי שלך ואת שם הדומיין שלך – ומה שאתה מקבל בחזרה הוא אישור (המפתח הציבורי והשם שלך, חתומים על ידי ה-CA). המפתח והאישור הם שני קבצים נפרדים המופקים בשני שלבים נפרדים; ה-CA מטפלת אי-פעם רק במחצית הציבורית.

הזרימה הכללית, כולה מתבצעת על מכונה רגילה (לעולם לא על המצלמה):

1. השג שם דומיין. רשויות CA ציבוריות מאשרות שם DNS שאתה שולט בו (למשל cam.example.com); הן לא ינפיקו עבור כתובת IP חשופה או שם מקומי-בלבד כמו mycam.

2. ייצר מפתח ו-CSR. פקודת OpenSSL אחת מפיקה את המפתח הפרטי ואת ה-CSR התואם. השתמש באותו סוג מפתח שהיית משתמש בו עבור אישור עצמי-חתום (ראה מושגים: אמון, מפתחות ופורמט קבצים); מומלץ ECDSA P-256.

   ECDSA P-256 – מומלץ:

   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
       -nodes -keyout domain.key -out domain.csr \
       -subj "/CN=cam.example.com" \
       -addext "subjectAltName=DNS:cam.example.com"
   

   ECDSA P-384 – חזק יותר, גדול/איטי יותר:

   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
       -nodes -keyout domain.key -out domain.csr \
       -subj "/CN=cam.example.com" \
       -addext "subjectAltName=DNS:cam.example.com"
   

   RSA-2048 – תאימות מרבית:

   openssl req -new -newkey rsa:2048 \
       -nodes -keyout domain.key -out domain.csr \
       -subj "/CN=cam.example.com" \
       -addext "subjectAltName=DNS:cam.example.com"
   

   שמור את domain.key בסוד – זהו קובץ המפתח שתשים בסופו של דבר על המצלמה. domain.csr הוא הקובץ שאתה מוסר ל-CA; הוא אינו מכיל סודות.

3. הגש את ה-CSR והוכח שאתה שולט בדומיין. כאן נבדלים שני המסלולים הנפוצים:

   • CA אוטומטית מסוג ACME כמו Let’s Encrypt, המופעלת על ידי כלי כמו certbot או acme.sh, מבצעת עבורך את שלבים 2 ו-3: היא מייצרת את המפתח, בונה את ה-CSR, עונה על האתגר באופן אוטומטי (HTTP-01: הגשת אסימון דרך פורט 80 בדומיין, או DNS-01: פרסום רשומת TXT ב-DNS שלו) וכותבת את הקבצים המוגמרים.

   • CA מסחרית (נרכשת ישירות או דרך מתווך דומיינים/אירוח): אתה מדביק את הטקסט של domain.csr בטופס אינטרנט, ואז מוכיח שליטה על ידי תגובה לאימייל אימות, פרסום רשומת DNS, או הצבת קובץ על שרת אינטרנט עבור אותו דומיין. לאחר האימות אתה מוריד את הקבצים שהונפקו.

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

   • המפתח הפרטי שלך (משלב 2). ה-CA מעולם לא החזיקה בו; הוא נשאר על המכונה שלך והוא המפתח שתשים בסופו של דבר על המצלמה.

   • אישור העלה – הנקרא גם אישור הישות-קצה או השרת. זהו האישור עבור הדומיין הספציפי שלך (cam.example.com): הוא מכיל את המפתח הציבורי שלך ואת השם שלך, וחתום על ידי הביניים של ה-CA. זהו האישור שהמצלמה מציגה כדי לזהות את עצמה.

   • אישור CA ביניים אחד או יותר (ה“שרשרת“ או ”חבילת ה-CA“). CA אינה חותמת על העלה שלך עם השורש שלה ישירות – מפתח השורש נשמר במצב לא-מקוון ומוגן בכבדות – ולכן היא חותמת עם ביניים, אשר בעצמו חתום על ידי השורש. הביניים הוא החוליה שמחברת את העלה שלך כלפי מעלה אל השורש.

   אישור השורש הוא עוגן האמון: אישור עצמי-חתום השייך ל-CA היושב בראש השרשרת. אינך מקבל אותו ולעולם אינך פורס אותו, מכיוון שלכל לקוח כבר יש אותו – מערכות הפעלה, דפדפנים, טלפונים וסביבות ריצה של שפות מגיעים עם ”מאגר אמון“ מובנה של אישורי שורש. לקוח סומך על העלה שלך על ידי מעבר לאורך השרשרת: הוא כבר סומך על השורש, השורש ערב לביניים, והביניים ערב לעלה שלך. (זו בדיוק העבודה שעושים ה-server.der / cafile היחידים שלך במקרה העצמי-חתום – שם אתה השורש של עצמך.)

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

   שמות קבצים שתראה בפועל: כלי ACME כמו certbot כותב privkey.pem (המפתח שלך), cert.pem (העלה לבד), chain.pem (הביניים(ים) לבד) ו-fullchain.pem (עלה + ביניים(ים)). CA מסחרית בדרך כלל נותנת לך .crt עבור העלה ו-.ca-bundle עבור הביניים(ים), כאשר ה-.key הוא זה שייצרת בעצמך.

5. המר והעתק. המר את המפתח הפרטי ואת אישור העלה ל-DER והעתק אותם למצלמה בדיוק כמו ב-תעודות חתומות-עצמית. המצלמה אז מציגה אותם כאישור השרת שלה ולקוחות סטנדרטיים מקבלים את החיבור אוטומטית, מכיוון שהם כבר סומכים על ה-CA – אין צורך בתצורה בצד הלקוח.

טיפ

בפועל, כשהמצלמה מציגה רק את העלה (ולעולם לא את הביניים), זה מתנהל כך:

• לקוחות שכבר יש להם את הביניים של ה-CA במטמון – דפדפנים מרכזיים וספריות HTTPS בדרך כלל כן – משלימים את השרשרת בעצמם ומתחברים בסדר.

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

אם כל לקוח אפשרי חייב להצליח, אל תסיים TLS ציבורי על המצלמה ישירות. הצב שער / reverse proxy לפניה שמגיש את השרשרת המלאה לעולם החיצוני, וגרום ל-proxy להגיע למצלמה דרך הזרימה העצמי-חתומה שתוארה למעלה.