תשובות לשאלות של אלכס — CertmPlatform

נכתב על־ידי גל · 2026-05-18 · מבוסס על הקוד בענף develop

שאלה 1 — איך עובדת ההנפקה של תעודות?

ההנפקה היא צינור (pipeline) של ארבעה שלבים. הדוגמה כאן היא של MSCA דרך Agent (המקרה הנפוץ):

1. בקשה מהדפדפן. ה־UI (React SPA) שולח POST /CertmPlatform/api/Ca/{server}/{name}/issue/{format}/{keySize} עם פרטי הסובייקט, SAN, EKU וכו'. אימות: Windows Negotiate/NTLM. הרשאה: ApiAuthorization(Roles = Management).
2. יצירת מפתח + CSR בצד CertmPlatform. ב־CaController.IssueFromFormInternal (Controllers/CaController.cs:561):
   1. CsrBuilder.GenerateKey(keySize) — יוצר זוג מפתחות RSA בזיכרון של ה־IIS process.
   2. CsrBuilder.BuildCsr(request, template) — בונה CSR וחותם אותו במפתח הפרטי שזה עתה נוצר.
   המפתח הפרטי לא יוצא מ־CertmPlatform עד שעוטפים אותו ל־PKCS#12 בסוף.
3. שליחת ה־CSR ל־CA. ICAService svc = GetCaService(server, name) מחזיר אינסטנס לפי סוג ה־CA:
   • MSCA — Microsoft CA (מקומי דרך COM, או דרך Agent).
   • EJBCA — REST + SOAP (Services/Clients/EjbcaClient.cs).
   • Acme — ACME (כרגע stub, לא יוצר תעודות אמיתיות).
   הקריאה svc.IssueCertificate(csr, template) מחזירה byte[] של התעודה ב־DER, או null אם נכשל.

   במסלול ה־MSCA Foreign (Services/CA_Modules/MSCA_Foreign.cs:121):

   CertmPlatform              CertmScanner (Agent)             Microsoft CA
   ─────────────              ────────────────────             ────────────
   MSCA.IssueCertificate
      └─ IssueCertificateForeign
           └─ CertmScannerClient.IssueAsync(ca, csr)
                  POST api/MsCa/{server\name}/issue   ─────►   MsCaLocal (COM)
                                                                 ICertRequest2
                                                                 └─ Submit(CSR)
                                                                 └─ GetCertificate()
                  ◄────────────── cert (DER bytes) ──────────
      ◄── byte[] cert
   

   הבחירה איזה Agent לפנות אליו מבוססת על השדה CA.agent בטבלת ה־CAs; הערך נשלף מהמילון scanners דרך Config.Get("scanners") (טבלת SQL Scanners, ראה Migration 4).
4. אריזה והחזרה. ב־CertmPlatform מאחדים את התעודה שחזרה עם המפתח הפרטי שנשמר משלב 2, ויוצרים PKCS#12 (.pfx) או PEM לפי הפורמט שביקש המשתמש. הקובץ זורם חזרה ל־UI ב־application/octet-stream. רישום ב־ActiveLog + SysLog עם שם המשתמש שביצע.

שאלה 2 — מי יוזם, מי מבצע?

נקודה חשובה: CertmPlatform אף פעם לא חותם תעודות בעצמו — הוא רק יוזם, מתאם ורושם. החתימה היא תמיד באחריות ה־CA. ה־Agent הוא רק שכבת תקשורת שמאפשרת ל־CertmPlatform לדבר עם CA שיושב במתחם אחר (בעיקר בגלל ש־MSCA דורש COM מקומי על מכונת ה־CA).

שאלה 3 — האם זה מתאים לארכיטקטורה ששלחת?

ברמת המאקרו הציור הגיוני וקרוב למה שקיים, אבל כשבודקים קופסה־קופסה יש כמה דברים בציור שעדיין לא ממומשים בקוד. התשובה הקצרה: הציור מתאר ארכיטקטורת יעד; היום ממומש בעיקר העמוד השדרה של CertM Management → Scanner → MSCA (DCOM) ו־EJBCA ישיר. הרחבה:

מה תואם בדיוק לקוד

• CertM Management ↔ CertmPlatform — המתאם המרכזי. ✓
• Scanner 1 ↔ CertmScanner (Agent) — נכון, סוכן נפרד אחד או יותר, נבחר פר CA דרך CA.agent. ✓
• Scanner 1 → MSCA (DCOM) — מדויק. CertmScanner/Services/MsCaLocal.cs משתמש ב־COM/DCOM של ICertRequest2. ✓
• SCEP Client → CertM Management — ה־routes קיימים (/api/scep/*), אבל המודול עצמו stub חלקי ולא מקבל בקשות SCEP אמיתיות (אין ScepLib, ראה DEPENDENCIES.md). ⚠
• קופסת F5/NetScaler/Dynamics/Palo Alto/imperva/front door/reblaze/websphere — מיוצגת ב־UI כטאב "NetApps". בקוד היום ממומש רק F5 BIG-IP (אמיתי, דרך iControl REST), Alteon (stub), והשאר לא קיימים. ⚠

מה לא תואם / חסר בקוד

1. Scanner 1 → EJBCA (REST API). בציור EJBCA יוצא מהסורק. בקוד EJBCA יוצא ישירות מ־CertmPlatform דרך Services/Clients/EjbcaClient.cs; הסוכן תומך רק ב־MSCA. אם זה ה־target — צריך לעטוף את EjbcaClient בצד הסוכן ולחשוף route ב־CertmScanner.
2. CEP (החץ המקווקו ל־MSCA). לא ממומש. כל מסלול MSCA הוא DCOM דרך הסוכן. אין תמיכה ב־Certificate Enrollment Policy/Service (HTTPS-based MSCA).
3. PKI Linux Agent Per OS and Version. לא קיים בקוד. אין סוכן Linux להפצה/חידוש תעודות בקצה.
4. PKI Agent (משמאל למטה). לא קיים. בציור זה סוכן צד־לקוח (endpoint) ש:
   • מדבר עם ACME Server ישירות,
   • מחדש תעודות מ־MSCA דרך Renew DCOM,
   • נרשם ל־CertM Management.
   בקוד היום ACME עובד דרך Services/CA_Modules/Acme.cs שהוא stub (לא מנפיק תעודות בפועל), וקריאת ACME אמורה לצאת ישירות מ־CertmPlatform — אין endpoint agent ביניהם.

בנוסף, יש שלושה פרטים שלא מופיעים בציור אבל קיימים בקוד וכדאי שיהיו במודל המנטלי:

• WebSocketHub — סוכנים פותחים WebSocket ל־/CertmPlatform/app?who=agent כדי להירשם ולקבל הודעות push. כל קריאות הבקרה הן Platform → Agent; אין REVERSE.
• MSCA Local — אם CertmPlatform רץ על אותה מכונה כמו ה־CA, הוא ניגש ל־COM ישירות בלי סוכן (path מתחיל ב־$). זה לא רלוונטי לפריסה החדשה אבל קיים בקוד.
• SQL Server (192.168.0.25\CTESQL) — לקוח יחיד הוא CertmPlatform. סוכנים לא ניגשים ל־DB.

הציור של מה שיש היום בקוד

לצורך השוואה ישירה — זו ארכיטקטורת המערכת כפי שהיא ממומשת היום (ענף develop):

┌──────────────┐       HTTPS (Negotiate/NTLM)        ┌──────────────────────────────────┐
│   Browser    │ ──────────────────────────────────► │   IIS  →  CertmPlatform          │
│ (React SPA)  │   /CertmPlatform/api/...            │   (ASP.NET Core, in-process)     │
└──────────────┘                                     │                                  │
                                                     │  • Negotiate auth + Permissions  │
┌──────────────┐   /CertmPlatform/api/scep/* (stub)  │  • CsrBuilder (key + CSR)        │
│ SCEP Client  │ ──────────────────────────────────► │  • CaManager dispatch            │
│   (⚠ stub)   │                                     │  • Acme.cs   (⚠ stub, in-proc)   │
└──────────────┘                                     │  • EF Core → SQL                 │
                                                     └──┬───────────────┬──────────────┘
                                                        │               │
                                                        │ WebSocket     │ EF Core
                                                        │ /app          │ TDS
                                                        ▼               ▼
                                                ┌──────────────┐  ┌──────────────────┐
                                                │ WebSocketHub │  │ SQL Server       │
                                                │ (agents      │  │ 192.168.0.25\    │
                                                │  register)   │  │  CTESQL · CertM  │
                                                └──────────────┘  └──────────────────┘

  CertmPlatform fan-out (every arrow below originates IN CertmPlatform, not in an agent):

       ┌─────────────────┬────────────────────┬─────────────────┬──────────────────┐
       │                 │                    │                 │                  │
       ▼ HTTP            ▼ REST + SOAP        ▼ iControl REST   ▼ (stub)           ▼ (stub)
 ┌─────────────┐    ┌────────────────┐   ┌────────────────┐  ┌────────────┐  ┌────────────┐
 │ CertmScanner│    │  EJBCA server  │   │  F5 BIG-IP     │  │  Alteon    │  │  ACME      │
 │  (Agent,    │    │  (direct from  │   │  (direct from  │  │ (no real   │  │ (no real   │
 │   HTTP/S)   │    │   Platform)    │   │   Platform)    │  │  call)     │  │  call)     │
 │ api/MsCa/...│    └────────────────┘   └────────────────┘  └────────────┘  └────────────┘
 └──────┬──────┘
        │ COM / DCOM
        ▼ ICertRequest2
 ┌─────────────┐
 │ Microsoft CA│
 └─────────────┘

NetApps not implemented today: NetScaler · Palo Alto · Dynamics · imperva · front door · reblaze · websphere
Agents not implemented today: PKI Agent (endpoint) · PKI Linux Agent
Protocols not implemented today: CEP/CES (MSCA over HTTPS) · real ACME · real SCEP

ההבדל הקריטי מול הציור של אלכס: בקוד היום, EJBCA, F5, Alteon ו־ACME יוצאים ישירות מ־CertmPlatform, לא דרך הסוכן. רק MSCA עובר דרך CertmScanner.

שאלה 4 — תעבור על הציור שלי ותגיד לי אם זה נכון

מעבר נקודה־נקודה על הקופסאות והחצים בציור מול הקוד. ✓ = תואם, ⚠ = תואם חלקית, ✗ = לא קיים בקוד היום.

סיכום ההפרשים

הציור שלך מתאר הרחבה בשלושה כיוונים מעבר למה שיש היום:

1. סוכן endpoint חדש (PKI Agent) — לחידוש אוטומטי על שרתי קצה (Windows) + לתקשורת מול ACME.
2. סוכן Linux מקביל — אותו תפקיד, פלטפורמה אחרת.
3. הרחבת NetApps — מ־F5 בלבד לחבילה של 7+ ספקי load-balancer/WAF/gateway.

שני שינויים נוספים שכדאי להתייעץ עליהם לפני שמסמנים את הציור כסופי:

• האם EJBCA → דרך Scanner זו דרישה אמיתית, או שזה כי בציור הוא צויר ליד MSCA? היום הוא יוצא ישירות מ־Platform וזה עובד; להוסיף קפיצה דרך הסוכן זה עוד hop למעבר.
• האם CEP ל־MSCA נחוץ כתחליף ל־DCOM, או רק במצבים מסוימים? CEP פותח אפשרות לסביבות בלי trust דומיין, אבל הוא עוד module שלם לפתח ולתחזק.

אם תאשר שזו אכן ארכיטקטורת היעד, אני אפתח issue/epic לכל פריט שמסומן ב־✗ ואצרף קישור ל־DEPENDENCIES.md.

שאלה 5 — מה צריך לתמוך בפרויקט? (נגזר מהציור של אלכס)

סיכום הפערים בין הציור של אלכס לקוד היום, כ־checklist של מה שצריך לממש. הלגנדה: ✓ = ממומש ועובד · ⚠ = ממומש חלקית/stub · ✗ = לא קיים.

1. שרתי CA (מקורות הנפקה)

2. סוכני קצה (Endpoint agents)

3. פרוטוקולי enrollment ללקוחות

4. NetApps — יעדי הפצה של תעודות

5. יכולות חוצות־מערכת (cross-cutting)

סיכום ההיקף

אם הציור של אלכס הוא ה־scope המלא, יש כאן רוב פרויקט נפרד:

• שני סוכנים חדשים (PKI Agent Windows + Linux) — projects חדשים בסולושן, לא הרחבה של CertmScanner.
• 4 מודולי CA חדשים/מורחבים — CEP, ACME אמיתי, SCEP אמיתי, EJBCA דרך Scanner.
• 7 לקוחות NetApp חדשים + השלמת F5/Alteon — כל אחד API שונה.
• 2 תהליכים חוצים — חידוש אוטומטי, Push אחרי Issue.

שווה לפצל את זה ל־epics ולתעדף לפני שמתחילים. אני מציע לאשר את הציור כ־target עם אלכס, אז לפתוח issue פר־שורה בטבלאות למעלה, ואז להחליט סדר עבודה (אולי קודם CEP+ACME, אז PKI Agent Windows, אז NetApps?).

קבצים רלוונטיים בקוד: Controllers/CaController.cs · Services/CAService.cs · Services/CA_Modules/MSCA.cs · Services/CA_Modules/MSCA_Foreign.cs · Services/Clients/CertmScannerClient.cs · CertmScanner/Services/MsCaLocal.cs