תאריכים והערת עריכה: המקור פורסם ב־. התרגום והבדיקה הטכנית עודכנו ב־. נשמר מלוא מבנה המאמר, עם תיקוני דיוק מתועדים. פקודות ותצורות לא הורצו; יש להתאים אותן לסביבה ולגרסה לפני שימוש.
מקור המאמר: לקריאת הגרסה המקורית באנגלית.
מבוא: האתגר בקבלת תעודות
קבלת תעודה דיגיטלית אינה מסתכמת בבקשה מרשות אישורים (CA) לחתום על מפתח ציבורי. צריך לנהל מחזור חיים שלם: יצירת זוגות מפתחות, הוכחת שליטה בדומיין או אימות זהות, הגשת בקשות לחתימת תעודה (CSR), קבלת התעודה והתקנתה, חידוש וביטול בעת הצורך. פרוטוקולים לקבלת תעודות מגדירים את התקשורת הזאת כדי לאפשר אוטומציה ותאימות בין מערכות וספקים.
במהלך השנים התפתחו כמה פרוטוקולים: SCEP, CMP, CMC, EST ו־ACME. כל אחד משקף דרישות ותפיסות תכנון שונות. ACME נפוץ במיוחד בתעודות לרשת הציבורית; EST ו־CMP מתאימים גם לתרחישים ארגוניים ולהתקנים. הבנת ההבדלים עוזרת לבחור פרוטוקול לפי הצורך, התמיכה בפועל ומודל האמון.
סקירת פרוטוקולים לקבלת תעודות
SCEP: פרוטוקול פשוט לקבלת תעודות
רקע והיסטוריה
SCEP צמח מפרוטוקול שקידמה Cisco בסוף שנות ה־1990 לצורך קבלת תעודות לציוד רשת. לאחר שנים של שימוש בפועל הוא פורסם ב־2020 כ־RFC 8894 במעמד Informational, ולא כתקן במסלול Internet Standards Track. הוא זוכה לתמיכה במערכות ניהול התקנים ניידים (MDM), בציוד רשת ובמערכות ארגוניות; יש לבדוק את גרסאות הלקוח והשרת הרלוונטיות.
איך SCEP פועל
SCEP משתמש ב־HTTP להעברת הודעות ובמבני CMS, שנקראו בעבר PKCS#7, ובבקשות PKCS#10. הפעולות העיקריות כוללות:
- PKCSReq: שליחת בקשת PKCS#10 במעטפת חתומה ומוצפנת לפי תפקיד מפתחות הרשות והרישום והאישורים הזמינים ללקוח. לחידוש מוגדר גם RenewalReq.
- CertPoll: אם ההנפקה אינה מיידית, הלקוח בודק בהמשך אם התעודה מוכנה.
- GetCertInitial: שם היסטורי הקשור לבדיקת מצב בקשת רישום ראשונית; אין להציגו כמנגנון נפרד לחלוטין מ־CertPoll בלי להתייחס לגרסת המימוש.
- GetCert: קבלת תעודה קיימת לפי המנפיק והמספר הסידורי.
- GetCRL: קבלת רשימת תעודות מבוטלות — CRL.
אימות רישום ראשוני נעשה לעיתים באמצעות challengePassword, סוד משותף שנמסר בערוץ נפרד ומאובטח. בחידוש אפשר להשתמש בתעודה קיימת ובמפתח שלה בהתאם לפרוטוקול ולמדיניות הרשות. יש להבחין בין הוכחת החזקה במפתח ובין הרשאה לקבל תעודה עבור זהות מסוימת.
מגבלות SCEP
- השימוש ב־HTTP אינו מחייב כשלעצמו TLS; מעטפות CMS מגינות על הודעות מסוימות, אך עדיין נדרשת בחינה של ההעברה, המטא־נתונים ואמון הרשות.
- יש להפיץ ולנהל את סיסמת האתגר באופן מאובטח.
- קיימת בקשת RenewalReq במפרט; היכולת בפועל ומדיניות החידוש תלויות במימוש.
- הבדלים בין מימושי ספקים עלולים להגביל תאימות.
- אין מקבילה מלאה וגמישה לכל מנגנוני גילוי דרישות הבקשה שמציעים פרוטוקולים אחרים.
איפה עדיין משתמשים ב־SCEP
SCEP משולב במערכות MDM ובכלי ניהול ציוד רשת, ובסביבות Microsoft AD CS באמצעות תפקיד NDES. מוצרים כמו Intune, Jamf ופתרונות ניהול התקנים אחרים עשויים לתמוך בו בדרכים שונות. כאשר קיימת תשתית ותיקה, התמיכה הרחבה יכולה להיות יתרון; בדקו את מסלול האינטגרציה העדכני ולא רק את שם הפרוטוקול.
CMP: פרוטוקול לניהול תעודות
רקע והיסטוריה
CMP פותח במסגרת IETF PKIX. הוא הופיע ב־RFC 2510 ב־1999, ובהמשך ב־RFC 4210 וב־RFC 9480. ב־2025 פורסמו RFC 9810 ו־RFC 9811 המחליפים ומעדכנים את המפרטים הקודמים. CMP עוסק במחזור חיים רחב: אתחול, רישום, עדכון מפתח, ביטול ותעודות צולבות. הוא מופרד עקרונית משכבת ההעברה; התמיכה ב־HTTP או במיפויים אחרים תלויה בפרופיל ובמימוש.
מבנה הודעות CMP
CMP משתמש בהודעות PKIMessage המקודדות ב־ASN.1 DER. הן כוללות כותרת עם שולח, נמען, זמן ומזהי עסקה, וגוף המתאר את הפעולה. בין הפעולות:
- ir — בקשת אתחול: תעודה ראשונה לישות חדשה.
- cr — בקשת תעודה: בקשה לתעודות נוספות.
- kur — בקשת עדכון מפתח: קבלת תעודה עם זוג מפתחות חדש.
- rr — בקשת ביטול: בקשה לביטול תעודה.
- certConf — אישור קבלה: אישור שהתעודה שהונפקה התקבלה.
מנגנוני אימות והגנה ב־CMP
CMP תומך בכמה מנגנוני הגנה על הודעות ובכמה סוגי מפתחות:
- קוד אימות הודעה — MAC: הגנה המבוססת על סוד משותף ועל מנגנוני MAC המוגדרים בפרופיל, לרבות מנגנונים מבוססי סיסמה.
- חתימה דיגיטלית: שימוש במפתח ובתעודה קיימים בהתאם למדיניות הרישום או העדכון.
- תעודות עם מפתחות KEM: RFC 9810 מוסיף תמיכה בניהול תעודות עם מפתח ציבורי למנגנון כימוס מפתח (KEM). אין להסיק מכך שכל מימוש CMP או כל מנגנון האימות שלו עמיד לקוונטים.
מקרי שימוש ב־CMP
CMP מתאים לתשתיות מפתח ציבורי הדורשות ניהול מחזור חיים מקיף, לרבות תקשורת, תעשייה, מערכות התקנים וסביבות ממשלתיות. התאמה למפרט ענפי מסוים — כגון 3GPP או IEC — מחייבת לבדוק את הגרסה והפרופיל המדויקים. אין לראות ברשימת תחומים הוכחה לאימוץ בכל מוצר, ברכב או ברשת מסוימים.
דוגמת CMP: בקשת אתחול במבנה ASN.1 מפושט
PKIMessage {
header: PKIHeader {
pvno: cmp2000,
sender: [GeneralName - לקוח],
recipient: [GeneralName - רשות אישורים],
transactionID: [בתים אקראיים],
senderNonce: [בתים אקראיים]
},
body: PKIBody {
ir: CertReqMessages [
CertReqMsg {
certReq: CertRequest {
certReqId: 0,
certTemplate: CertTemplate {
subject: [DN],
publicKey: [נתוני המפתח הציבורי]
}
}
}
]
},
protection: [MAC או חתימה על הכותרת והגוף]
}
CMC: ניהול תעודות באמצעות CMS
רקע
CMC, המוגדר בין היתר ב־RFC 5272, 5273, 5274 ו־6402, הוא מסגרת לניהול תעודות בתוך מבני CMS — Cryptographic Message Syntax. הוא תומך ברישום פשוט וגם בתרחישים הכוללים כמה בקשות, פקדי ניהול ותשובות חתומות.
CMC רלוונטי גם לתשתיות ארגוניות וממשלתיות, לרבות סביבות אמריקאיות המשתמשות בכרטיסים חכמים. אין להסיק מהפרוטוקול לבדו מהו תהליך ההנפקה המחייב של PIV או CAC. יש לבדוק את מסמכי התוכנית והפרופיל הספציפיים; האזכור הוא להקשר האמריקאי ואינו קובע דרישות בישראל.
פעולות CMC
CMC מגדיר בקשות מסוג Full PKI Request ו־Simple PKI Request. המבנה המלא משתמש במעטפות CMS ויכול לתמוך, לפי הפרופיל והמימוש, בפעולות הבאות:
- כמה בקשות תעודה באותה הודעה.
- פקדים ומאפיינים לניהול בקשות ותשובות.
- תרחישים של ארכוב מפתחות פענוח וניהול שחזור, לפי הפרוטוקולים והמדיניות המתאימים.
- הוכחת החזקה במפתח — Proof of Possession — שאינה זהה לבדה להוכחת זהות.
- העברה במיפויים מתאימים, כגון HTTPS, דוא״ל או קבצים.
EST: קבלת תעודות על גבי תעבורה מאובטחת
רקע ומטרות התכנון
EST, שהוגדר ב־RFC 7030 ב־2013, מציע רישום תעודות על גבי TLS עם נקודות קצה של HTTP ובקשות PKCS#10. הוא תומך באימות לקוח בדרכים שונות ובהן תעודות לקוח. הפרוטוקול מתאים להתקני רשת ולמערכות IoT. מורכבות המימוש תלויה גם בניהול האמון, באתחול ההתקן ובדרישות הפרופיל, ולא רק במספר נקודות הקצה.
נקודות הקצה של EST
כתובות EST משתמשות בבסיס /.well-known/est, עם רכיב label אופציונלי לפני שם הפעולה. הפעולות כוללות:
GET /cacerts — קבלת תעודות רשות במבנה CMS certs-onlyPOST /simpleenroll — הגשת CSR וקבלת תעודהPOST /simplereenroll — רישום מחדש או חידושPOST /fullcmc — בקשת CMC מלאה, לפי תמיכת השרתPOST /serverkeygen — יצירת מפתח בשרת, אם נתמכתGET /csrattrs — קבלת דרישות למאפייני CSRאפשרויות אימות ב־EST
אפשרויות האימות תלויות בשרת ובפרופיל:
- אימות TLS הדדי: הלקוח מציג תעודה במסגרת לחיצת היד, למשל לצורך רישום מחדש.
- HTTP Basic: שם משתמש וסיסמה על גבי TLS, כאשר הרשות תומכת בכך לרישום הראשוני.
- HTTP Digest: אימות אתגר–תגובה מעל TLS, בהתאם לתמיכה ולהגדרות.
- אתחול באמצעות BRSKI (RFC 8995): שילוב שוברים ותהליך אתחול אמון להתקן חדש; זו הרחבה ותשתית נלוות ולא שיטת HTTP נוספת.
דוגמת רישום פשוט ב־EST עם .NET
זוהי דוגמת לימוד חלקית, לא לקוח מוכן לייצור. היא דורשת הפניה מתאימה ל־System.Security.Cryptography.Pkcs. לפי הבהרת הקידוד ב־RFC 8951, גוף ההודעות נשאר מקודד ב־base64, אך אין להסתמך על כותרת Content-Transfer-Encoding. הדוגמה לא קומפלה או הורצה במסגרת הבדיקה.
// דוגמה חלקית בלבד: ניהול אמון, זהות, מפתח ושחזור מחייבים תכנון נוסף.
// לעולם אל תבטלו אימות תעודת שרת. התקינו מראש עוגן אמון מאומת.
using System;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Security.Cryptography;
using System.Security.Cryptography.Pkcs;
using System.Security.Cryptography.X509Certificates;
using System.Text;
using var rsa = RSA.Create(2048);
var csr = new CertificateRequest("CN=mydevice,O=MyCompany", rsa,
HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
var csrBase64 = Convert.ToBase64String(csr.CreateSigningRequest());
// תצורת אימות הלקוח חייבת להתאים לשרת. אל תקודדו סוד בקוד מקור.
using var handler = new HttpClientHandler();
using var client = new HttpClient(handler);
// הגדירו כאן תעודת לקוח או אישורים ממנגנון סודות מורשה.
using var content = new StringContent(csrBase64, Encoding.ASCII);
content.Headers.ContentType = new MediaTypeHeaderValue("application/pkcs10");
// לפי RFC 8951 גוף הבקשה מקודד ב־base64 ללא כותרת Content-Transfer-Encoding.
using var response = await client.PostAsync(
"https://ca-server/.well-known/est/simpleenroll", content);
if (response.StatusCode == HttpStatusCode.Accepted)
throw new InvalidOperationException("יש להמתין לפי Retry-After ולנסות שוב את אותה בקשה");
response.EnsureSuccessStatusCode();
if (response.Content.Headers.ContentType?.MediaType != "application/pkcs7-mime")
throw new InvalidOperationException("סוג תשובה לא צפוי");
var cmsBytes = Convert.FromBase64String(await response.Content.ReadAsStringAsync());
var cms = new SignedCms();
cms.Decode(cmsBytes);
// זו מעטפת certs-only; עצם הפענוח אינו מאמת את התעודה או את השרשרת.
// בדקו זהות, מפתח ציבורי, ייעוד, שרשרת אמון ומדיניות לפני התקנה.
// שמרו את המפתח הפרטי באופן מאובטח; הדוגמה אינה לקוח EST מלא.
Console.WriteLine($"מספר תעודות בתשובה: {cms.Certificates.Count}");
מגבלות EST
- יצירת מפתח בצד השרת אינה ארכוב מפתחות; אין ב־EST מנגנון ארכוב כללי מקביל למערכת ניהול מפתחות מלאה.
- EST אינו פרוטוקול כללי לביטול תעודות; יש לשלב מנגנוני ביטול ופרסום מצב נפרדים לפי התשתית.
- אתחול אוטומטי מסוג BRSKI דורש את רכיבי האמון וההרחבות שלו; הוא אינו נובע מ־EST לבדו.
ACME: סביבה אוטומטית לניהול תעודות
רקע והיסטוריה
ACME, שהוגדר ב־RFC 8555 ב־2019, התפתח בשיתוף קהילת IETF וגורמים ובהם ISRG, מפעילת Let's Encrypt. הוא נועד למכן אימות שליטה במזהים והנפקת תעודות. הוא משתמש ב־HTTPS ובבקשות POST עם חתימות JSON Web Signature (JWS); עצם השימוש בו אינו מבטיח שהשירות או התעודה חינמיים.
הרעיון המרכזי בתעודות אימות דומיין (DV) הוא שאפשר למכן הוכחת שליטה: מענה מתאים לאתגר HTTP או פרסום רשומת DNS מאפשרים לאמת שליטה לצורך ההנפקה. זו אינה הוכחת זהות ארגונית או בעלות משפטית. ACME מגדיר את האתגרים ואת תהליך קבלת התעודה באופן שמכונות יכולות לבצע.
סוגי אתגרים ב־ACME
- HTTP-01: פרסום תשובת keyAuthorization בנתיב http://[domain]/.well-known/acme-challenge/[token]. נקודת האימות צריכה להיות נגישה בפורט 80.
- DNS-01: פרסום ערך base64url של גיבוב SHA-256 של keyAuthorization ברשומת TXT תחת _acme-challenge.[domain]. מתאים גם לתעודות wildcard ולשרתים שאינם נגישים ב־HTTP.
- TLS-ALPN-01: לפי RFC 8737: משא ומתן על ALPN בערך acme-tls/1 והצגת תעודת אימות עם הרחבת acmeIdentifier מתאימה. השיטה פועלת בפורט 443.
תהליך העבודה של ACME
זרימת הנפקה ב־ACME
ACME ב־.NET: דוגמה עם Certes
using System;
using System.Linq;
using Certes;
using Certes.Acme;
// אתחול מול סביבת הבדיקות של Let's Encrypt — לא סביבת ייצור
var acme = new AcmeContext(WellKnownServers.LetsEncryptStagingV2);
// יצירת חשבון לאחר בדיקת תנאי השירות והסכמה מפורשת של בעל החשבון
bool termsReviewedAndAccepted = false; // עדכנו רק לאחר הסכמה אמיתית, לא אוטומטית
if (!termsReviewedAndAccepted)
throw new InvalidOperationException("נדרשת הסכמה לתנאי הרשות לפני יצירת חשבון");
var account = await acme.NewAccount("admin@example.com", termsOfServiceAgreed: termsReviewedAndAccepted);
// בקשת תעודה לדומיין שבשליטתכם
var order = await acme.NewOrder(new[] { "example.com" });
// קבלת אתגר HTTP
var authz = (await order.Authorizations()).First();
var httpChallenge = await authz.Http();
// פרסמו את קובץ האתגר בכתובת: http://example.com/.well-known/acme-challenge/{httpChallenge.Token}
// תוכן הקובץ צריך להיות: httpChallenge.KeyAuthz
Console.WriteLine($"אסימון: {httpChallenge.Token}");
Console.WriteLine($"תשובת האתגר: {httpChallenge.KeyAuthz}");
// לאחר פרסום הקובץ בקשו אימות; המתינו למצב valid לפני השלמה
await httpChallenge.Validate();
// בדוגמת לימוד זו עוצרים כאן עד להשלמת בדיקת המצב.
// לקוח מלא חייב לבצע polling, לטפל ב־pending/invalid ובתקלות, ורק אז להשלים.
throw new InvalidOperationException("נדרש מימוש בדיקת מצב האתגר ושמירת מפתחות לפני המשך");
// יצירת מפתח ו־CSR והשלמת הזמנה רק לאחר אימות; שמרו את המפתח מאובטח
// example.com הוא מציין מקום; השתמשו רק בשם שבשליטתכם ובמדיניות שהרשות מתירה.
var privateKey = KeyFactory.NewKey(KeyAlgorithm.ES256);
var cert = await order.Generate(new CsrInfo { CommonName = "example.com" }, privateKey);
// ייצוא התעודה
var certPem = cert.ToPem();
השוואה מקיפה בין הפרוטוקולים
| מאפיין | SCEP | CMP | CMC | EST | ACME |
|---|---|---|---|---|---|
| העברה | HTTP | לפי פרופיל; נפוץ HTTP | HTTPS או מיפויים אחרים | HTTPS | HTTPS |
| פורמט הודעות | PKCS#7 | ASN.1/DER | CMS/PKCS#7 | PKCS#10+MIME | JSON/JWS |
| אימות והגנת הודעות | סוד אתגר או תעודה קיימת | MAC או חתימה; תמיכת מפתחות לפי פרופיל | חתימות CMS ומנגנוני הפרופיל | TLS ואימות HTTP לפי הפרופיל | JWS, בדרך כלל עם מפתח החשבון |
| חידוש תעודה | RenewalReq לפי המימוש | הודעות עדכון, לרבות kur | בקשות ופקדים לפי הפרופיל | /simplereenroll | הזמנה חדשה |
| ביטול ומידע על ביטול | קבלת CRL; לא בקשת ביטול כללית | בקשת rr | פקדי ביטול לפי CMC והפרופיל | מנגנונים חיצוניים ל־EST | נקודת הקצה revokeCert |
| ארכוב מפתחות | לא מנגנון מובנה כללי | לפי הפרופיל והמערכת | לפי הפרופיל והמערכת | serverkeygen אינו ארכוב | לא מנגנון מובנה כללי |
| התאמה להתקנים ול־IoT | לפי המימוש והאינטגרציה | ניהול מחזור חיים רחב | לפי המימוש והפרופיל | מתאים לרישום התקנים | אפשרי לפי הרחבות ודרישות |
| אוטומציית אימות דומיין | לא אתגרי DV בסגנון ACME | לא אתגרי DV בסגנון ACME | לא אתגרי DV בסגנון ACME | לא אתגרי DV בסגנון ACME | כן, למשל HTTP ו־DNS |
| מורכבות המימוש | בינונית ותלויה בתשתית | גבוהה יחסית | גבוהה יחסית | בינונית ותלויה באתחול האמון | נוחה עם לקוח בשל; תלויה בסביבה |
| תמיכה פוסט־קוונטית | תלויה באלגוריתמים ובמימוש | הרחבות KEM ב־RFC 9810; בדקו מימוש | תלויה בפרופיל ובאלגוריתמים | תלויה ב־TLS, ב־CSR ובמימוש | תלויה באלגוריתמים ובמימוש |
| שימושים אופייניים | MDM וציוד רשת | תקשורת ותעשייה | תשתיות ארגוניות וכרטיסים חכמים | התקנים ארגוניים ו־IoT | תעודות DV לאינטרנט |
מדריך לבחירת פרוטוקול
בחרו ACME כאשר...
- דרושות תעודות DV לשרתי אינטרנט.
- רשות התומכת ב־ACME מתאימה למדיניות שלכם.
- חידוש אוטומטי הוא יעד מרכזי.
- אפשר לענות לאתגר HTTP/TLS או לנהל DNS; אין חובה לפתוח פורטים אם משתמשים ב־DNS-01.
בחרו EST כאשר...
- רושמים התקנים ארגוניים או חומרת IoT.
- נדרשת רשות פרטית התומכת ב־EST.
- מחפשים ממשק רישום מודרני עם תמיכת התקנים מתאימה.
- משלבים BRSKI לאתחול אמון אוטומטי בהתקנים.
בחרו CMP כאשר...
- נדרש ניהול רחב של מחזור חיי תעודות.
- הפרופיל בתחום התקשורת, התעשייה או ההתקנים דורש זאת.
- נדרשים סוגי מפתחות מתקדמים, לאחר אימות התמיכה בתקן ובמימוש.
- נדרשים תהליכי ביטול ועדכון מורכבים.
בחרו SCEP כאשר...
- נדרשת אינטגרציה עם מערכת MDM התומכת בו.
- ציוד רשת ותיק מחייב או תומך במסלול הזה.
- כבר קיימת תשתית SCEP מתוחזקת.
- נדרשת תאימות למימושי לקוח ורשות ותיקים, בלי לוותר על בדיקות אבטחה.
BRSKI: אתחול אמון מאובטח ללא הגדרה ידנית לכל התקן
BRSKI, ראשי תיבות של Bootstrapping Remote Secure Key Infrastructure (RFC 8995), משלב תהליך אתחול אמון עם EST. התקן חדש, המכונה pledge, משתמש בזהות יצרן IDevID ובקשר עם Registrar. רכיב MASA — רשות חתימה המורשית בידי היצרן — מסייע באמצעות שובר לקשור את ההתקן לדומיין המיועד; לאחר מכן אפשר לקבל תעודה מקומית LDevID דרך EST. האוטומציה תלויה בתשתית היצרן, במדיניות הבעלות ובתמיכה במימוש, ולא מבטלת את הצורך בעיגון אמון.
סיכום
אין פרוטוקול אחד שמתאים לכל תרחיש. ACME מתאים במיוחד לאוטומציה של תעודות אימות דומיין; EST מספק מסלול רישום להתקנים על גבי TLS; CMP מציע ניהול מחזור חיים רחב; SCEP חשוב בתשתיות קיימות; ו־CMC משמש למסגרות ניהול המבוססות על CMS. בפרויקט חדש בדקו את הפרופיל, התמיכה בשני הצדדים, מנגנון האתחול, ההגנה על המפתחות, החידוש והביטול. שם הפרוטוקול לבדו אינו מבטיח אבטחה או עמידות פוסט־קוונטית.
מקורות להבהרות ולעדכונים
התרגום כולל תיקוני דיוק והבהרות על בסיס המקורות הרשמיים הבאים, שנבדקו ב־25 באוקטובר 2026.