CertmPlatform — תשובות ארכיטקטוניות

גל · 2026-05-19

תשובה ברמת ארכיטקטורה — תפקידים, flows, ו"מי פונה למי". לא API, לא מבנה CSR, לא הפניות לקבצים בקוד. כל דיאגרמה היא Mermaid (טופולוגיה + UML).

1. איך עובדת הנפקת תעודה

שלוש שכבות, כל אחת בתפקיד אחד מובחן:

  1. היוזם שולח בקשה (משתמש בדפדפן · SCEP client · בעתיד PkiAgent על נקודת קצה).
  2. CertM Management מקבל את הבקשה, יוצר זוג מפתחות, בונה את ה־CSR, ובוחר את ה־CA. הוא לא חותם.
  3. Scanner משמש כצינור אל ה־CA כשה־CA נמצא ברשת שלו. גם הוא לא חותם.
  4. ה־CA חותם ומחזיר תעודה. Management אורז עם המפתח הפרטי ל־PFX ומחזיר ליוזם.
sequenceDiagram autonumber actor U as יוזם participant M as CertM Management participant A as Scanner participant CA as CA U->>M: בקשת תעודה Note over M: מפתחות + CSR M->>A: CSR A->>CA: בקשת חתימה CA-->>A: תעודה A-->>M: תעודה Note over M: אריזת PFX M-->>U: PFX

הנקודה הקריטית: המפתח הפרטי לא יוצא מ־Management. Scanner וה־CA רואים רק CSR — מפתח ציבורי. זה מה שמאפשר את כל מודל האבטחה.

2. מי יוזם, מי מבצע

שלושה תפקידים. תפקיד יחיד פר־רכיב:

תפקיד מי אחריות
יוזם משתמש · SCEP Client · PkiAgent (עתידי) שולח בקשה. לא יודע כלום על ה־CA.
מתאם (Orchestrator) CertM Management מקבל בקשה · מייצר מפתח+CSR · בוחר CA · אורז תוצאה · רושם הכל. לעולם לא חותם.
מבצע (Executor) Scanner / Direct call → CA מעביר ל־CA וחותם. Scanner מוקצה פר־CA, לא פר־פעולה.
flowchart RL I["יוזם
משתמש · SCEP · PkiAgent"] C["מתאם
CertM Management"] E["מבצע
Scanner / Direct"] CA["CA"] I -->|בקשה| C C -->|CSR| E E -->|חתימה| CA CA -->|תעודה| E E -->|תעודה| C C -->|PFX| I

שני חוקים שאוכפים את הפרדת התפקידים:

3. הארכיטקטורה הקיימת היום

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

flowchart TB Browser["משתמש
(דפדפן)"] SCEP["SCEP Client"] Mgmt["CertM Management
(orchestrator)"] Scanner["Scanner"] MSCA["MSCA"] EJBCA["EJBCA"] F5["F5 BIG-IP"] ACME["ACME"] Alteon["Alteon"] DB[("SQL Server")] Browser -->|HTTPS| Mgmt SCEP -.->|stub| Mgmt Mgmt -->|HTTP| Scanner Scanner -->|DCOM| MSCA Mgmt -->|ישיר| EJBCA Mgmt -->|ישיר| F5 Mgmt -.->|stub| ACME Mgmt -.->|stub| Alteon Mgmt --- DB classDef done fill:#dcfce7,stroke:#16a34a,color:#14532d classDef partial fill:#fef3c7,stroke:#d97706,color:#78350f classDef stub fill:#fee2e2,stroke:#dc2626,color:#7f1d1d class Mgmt,Scanner,MSCA done class EJBCA,F5 partial class SCEP,ACME,Alteon stub

מבט בקצרה

4. השוואה לציור שלך

הציור שלך מתאר את ה־target. בקופסאות למטה: ירוק = קיים, צהוב = חלקי, אדום = חסר.

flowchart TB subgraph Current["מה שיש היום"] c1["CertM Management"]:::done c2["Scanner (MSCA only)"]:::partial c3["F5 client (read)"]:::partial c4["EJBCA — direct"]:::partial end subgraph Target["מה שאתה מצייר"] t1["Scanner מטפל גם ב־EJBCA + CEP"]:::missing t2["PkiAgent — Windows"]:::missing t3["PkiAgent — Linux"]:::missing t4["NetApps × 8 (F5/NetScaler/Palo Alto/Imperva/FrontDoor/Reblaze/WebSphere/...)"]:::missing t5["ACME אמיתי"]:::missing t6["SCEP אמיתי"]:::missing end classDef done fill:#dcfce7,stroke:#16a34a,color:#14532d classDef partial fill:#fef3c7,stroke:#d97706,color:#78350f classDef missing fill:#fee2e2,stroke:#dc2626,color:#7f1d1d

הפערים, מפורט

בציור שלך סטטוס פער
Scanner מטפל ב־EJBCA (REST) ⚠ היום EJBCA יוצא ישיר מ־Management. אם זה ה־target, צריך לנתב דרך Scanner.
CEP מ־Scanner ל־MSCA ✗ היום כל MSCA הוא DCOM. CEP (HTTPS-based) לא ממומש בכלל.
PkiAgent — Windows ✗ PkiAgent חדש. אחראי על חידוש אוטומטי ועל ACME enrollment בנקודת הקצה עצמה.
PkiAgent — Linux ✗ אותו תפקיד, פלטפורמת Linux.
NetApps (F5 / NetScaler / Palo Alto / Imperva / Front Door / Reblaze / WebSphere / Dynamics) ⚠ רק F5 פעיל וגם הוא לקריאה בלבד. שאר הספקים — חסרים. "Dynamics" — דורש הבהרה ממך.
SCEP Client → Management ⚠ endpoint קיים, מימוש stub. צריך לבנות SCEP server אמיתי.
ACME — דרך PkiAgent ✗ כפול: גם ACME עצמו stub, וגם אין PkiAgent לעבור דרכו.

5. מה צריך לבנות

הפערים, מקובצים לארבעה תחומי בנייה:

flowchart TB subgraph A["1. PkiAgents (חדש)"] a1["PkiAgent — Windows"] a2["PkiAgent — Linux"] end subgraph B["2. פרוטוקולי CA"] b1["CEP/CES — ב־Scanner"] b2["ACME — אמיתי"] b3["SCEP — אמיתי"] b4["EJBCA — דרך Scanner"] end subgraph C["3. לקוחות NetApp"] c1["F5 — write/renew"] c2["Alteon — מימוש אמיתי"] c3["NetScaler · Palo Alto · Imperva"] c4["Front Door · Reblaze · WebSphere"] end subgraph D["4. תהליכים חוצים"] d1["חידוש אוטומטי (scheduler + agent)"] d2["Push אחרי Issue ל־NetApp"] end

היקף

סדר עבודה מוצע

  1. השלמת F5 (write/renew) + Alteon אמיתי — quick wins, אין תלות חדשה.
  2. ACME אמיתי + SCEP אמיתי — מודולים עצמאיים, לא דורשים PkiAgent.
  3. PkiAgent Windows — מבוסס על ACME מ־(2).
  4. CEP + ניתוב EJBCA דרך Scanner — שני שינויים דומים ב־routing.
  5. PkiAgent Linux + שאר NetApps — בסוף, אחרי שיש פלטפורמה יציבה.

6. תרחיש: חידוש תעודה ב־F5 מול MSCA

תרחיש קונקרטי. תעודה שמותקנת על F5 BIG-IP מתקרבת לפקיעה, ה־CA המנפיק הוא MSCA. הזרימה ברמת תפקידים:

  1. זיהוי — Scheduler מזהה תעודה ב־renewal window (לפי policy שמוגדרת על ה־CA / על התעודה).
  2. הנפקה — Management מייצר מפתח חדש + CSR (עם אותו Subject/SAN של התעודה הקיימת), שולח דרך Scanner ל־MSCA, מקבל תעודה חתומה.
  3. הפצה — Management מחליף את התעודה ב־F5: מעלה את ה־cert+key החדשים, מצביע את ה־SSL profile עליהם.
  4. סגירה — רישום ביומן, סימון התעודה הישנה כ־superseded, התראה אם משהו נכשל.
sequenceDiagram autonumber participant T as Scheduler participant M as CertM Management participant A as Scanner participant CA as MSCA participant F5 as F5 BIG-IP T->>M: תעודה לקראת פקיעה Note over M: מפתח + CSR M->>A: CSR A->>CA: בקשת חתימה CA-->>A: תעודה חדשה A-->>M: תעודה Note over M: הנפקה הסתיימה M->>F5: התקנה (cert + key) M->>F5: החלפת SSL profile F5-->>M: ack Note over M: רישום + סימון התעודה הישנה

שני שלבים מובחנים

סטטוס היום

שלב סטטוס הערה
זיהוי תעודות לקראת פקיעה ✗ אין scheduler אוטומטי לחידוש. היום זה ידני דרך ה־UI.
הנפקה מ־MSCA דרך Scanner ✓ פעיל. אותו path של הנפקה רגילה.
התקנה אוטומטית ב־F5 ✗ ה־F5 client היום read-only. צריך להוסיף upload + SSL-profile switch.
רישום + alerting ⚠ רישום ל־ActiveLog קיים להנפקות. alerting על כשל חידוש — חסר.

בשורה התחתונה: ה־flow המתואר כאן הוא ה־target. בפועל היום מבצעים את שלב 2 ידנית (UI), מורידים PFX, ומתקינים על F5 ידנית. שני הפערים — scheduler ו־F5 write — נמצאים בסעיף 5 ברשימת מה שצריך לבנות.

7. תרחיש: חידוש תעודה על תחנה עם PkiAgent

תרחיש קונקרטי. תעודה שמותקנת על תחנת קצה (שרת Windows / Linux) מתקרבת לפקיעה, ועל התחנה רץ PkiAgent. הזרימה ברמת תפקידים:

  1. זיהוי — PkiAgent סורק את ה־cert store המקומי ומזהה תעודה ב־renewal window (לפי policy שמתקבל מ־Management).
  2. הנפקה — PkiAgent מייצר מפתח חדש + CSR מקומית על התחנה, ושולח את ה־CSR ל־Management. Management מנתב ל־CA המתאים: MSCA → דרך Scanner, EJBCA → דרך Scanner (יעד), ACME → ישיר. ה־CA חותם, התעודה חוזרת ל־PkiAgent דרך Management.
  3. התקנה — PkiAgent מתקין את ה־cert+key במקום של התעודה הישנה (cert store / keystore / file), ומבצע bind מחדש על השירות שמשתמש בה אם נדרש.
  4. דיווח — PkiAgent מעדכן את Management: מספר סידורי חדש, תאריך פקיעה, סטטוס. ה־inventory ב־DB מתעדכן.
sequenceDiagram autonumber participant P as PkiAgent (תחנה) participant L as Local Store participant M as CertM Management participant A as Scanner participant CA as CA Note over P: זוהתה תעודה לקראת פקיעה P->>P: יצירת מפתח + CSR (מקומי) P->>M: בקשת חידוש + CSR M->>A: CSR A->>CA: בקשת חתימה CA-->>A: תעודה A-->>M: תעודה M-->>P: תעודה P->>L: התקנה (cert + key) P->>M: דיווח (thumbprint + status)

ההבדל המרכזי מתרחיש ה־F5

המפתח הפרטי נוצר ונשאר על התחנה. בניגוד לחידוש F5 (סעיף 6) שבו Management מייצר את המפתח ומעביר אותו ל־F5 — כאן ה־PkiAgent מייצר את המפתח אצלו, וה־CSR בלבד יוצא ממנו. גם Management וגם ה־CA לא רואים את המפתח הפרטי אף פעם.

מסלולים חלופיים (לפי הציור שלך)

סטטוס היום

PkiAgent לא קיים בקוד. כל התרחיש הזה הוא ה־target. היום חידוש על תחנת קצה הוא ידני לחלוטין — אדמין נכנס ל־UI, מנפיק תעודה חדשה, מוריד PFX, ומתקין על התחנה.

גל · 2026-05-19