Skip to content

איך פועל פרוטוקול ACME: מדריך מלא לקבלת תעודות אוטומטית

תאריכים והערת עריכה: המקור פורסם ב־. התרגום והבדיקה הטכנית עודכנו ב־. נשמר מלוא מבנה המאמר, עם תיקוני דיוק מתועדים. פקודות ותצורות לא הורצו; יש להתאים אותן לסביבה ולגרסה לפני שימוש.

מקור המאמר: לקריאת הגרסה המקורית באנגלית.

🔐

פרוטוקול ACME

סביבה אוטומטית לניהול תעודות — כך האינטרנט ממכן את ההנפקה והחידוש של תעודות SSL/TLS

RFC 8555 Let's Encrypt תשתית מפתח ציבורי ללא מגע יד אוטומציה של TLS

מהו פרוטוקול ACME?

פרוטוקול הסביבה האוטומטית לניהול תעודות — Automatic Certificate Management Environment ‏(ACME), שתוקנן ב־RFC 8555 במרץ 2019, הוא תקן פתוח המאפשר למכן קבלה, חידוש וביטול של תעודות TLS/SSL מרשות אישורים (CA). יש להגדיר מראש את הלקוח, ההרשאות והאינטגרציה עם השרת.

בעבר קבלת תעודה כללה בדרך כלל יצירת בקשה לחתימת תעודה (CSR), הגשתה לרשות, אימות, הורדה והתקנה ידניים. ACME ממכן את שלבי ההרשאה וההנפקה, ולקוחות יכולים לשלב גם התקנה וחידוש. תעודות ל־90 יום הן דוגמה מוכרת, אך ACME אינו מחייב משך תוקף מסוים; הוא תלוי ברשות ובפרופיל התעודה.

כיום ACME הוא הבסיס לפעילותה של Let's Encrypt, רשות אישורים חינמית. תומכים בו גם ספקים מסחריים כגון DigiCert ו־Sectigo, ולקוחות כגון Certbot. תצורת השירות והזכאות משתנות בין ספקים.

ניהול ידני לעומת ACME: שינוי הגישה

ניהול תעודות ידני לעומת אוטומציה באמצעות ACME

מושגי היסוד ב־ACME

לפני שנבחן את התהליך, חשוב להכיר את המשתתפים ואת מבני הנתונים המרכזיים במערכת ACME:

מערכת ACME: הרכיבים המרכזיים

תהליך קבלת תעודה באמצעות ACME

פרוטוקול ACME פועל בתהליך מוגדר הכולל קבלת נקודות קצה, רישום חשבון, הזמנה, אימות והנפקה. בקשות POST של הלקוח נעטפות ב־JSON Web Signature ‏(JWS) — מבנה חתום קריפטוגרפית, ונשלחות דרך HTTPS. קריאות למדריך ולמשאב nonce ותגובות השרת אינן כולן JWS. הנה פירוט השלבים:

התהליך המלא לקבלת תעודה באמצעות ACME

סוגי אתגרים ב־ACME: הוכחת שליטה בדומיין

השלב הקריטי ביותר ב־ACME הוא אימות הדומיין. רשות האישורים צריכה לוודא שלמבקש יש שליטה הנדרשת באימות. שלוש שיטות נפוצות הן HTTP-01 ו־DNS-01 מתוך RFC 8555, ו־TLS-ALPN-01 מההרחבה שב־RFC 8737.

סוגי אתגרים לאימות דומיין ב־ACME

אבטחה: חתימות JSON וערכים חד־פעמיים

בקשות POST של לקוח ACME משתמשות בחתימה מסוג JSON Web Signature ‏(JWS), כפי שמוגדר ב־RFC 7515. המעטפת הקריפטוגרפית הזאת מבטיחה:

  • אימות מפתח: בדיקת החתימה מאמתת שהבקשה נחתמה במפתח המתאים — בדרך כלל מפתח החשבון. אין בכך אימות עצמאי של זהות האדם שמחזיק במפתח.
  • שלמות: תוכן ההודעה לא שונה בדרך.
  • מניעת שידור חוזר: כל בקשה כוללת nonce — אסימון חד־פעמי שהתקבל מהשרת.
בקשת ACME: מבנה JWS — חתימת JSON

קריאת התרשים: שלושת הרכיבים מוצגים בנפרד לצורך הסבר. בפועל ACME שולח JWS ב־Flattened JSON Serialization, עם השדות protected, payload ו־signature; אין לשלוח את שלושתם כמחרוזת נקודות בפורמט הקומפקטי. הנקודה בנוסחת החתימה מפרידה בין קידודי הכותרת והתוכן שעליהם חותמים.

מחזור חיי התעודה וחידוש אוטומטי

אחת היכולות החזקות ביותר של ACME היא חידוש אוטומטי. מועד החידוש תלוי בלקוח, ברשות, במשך התוקף ובתמיכה ב־ACME Renewal Information ‏(ARI). ציר הזמן להלן מדגים תעודה ל־90 יום וחידוש בסביבות יום 60 בלבד; הוא אינו כלל מחייב או תיאור מדויק של כל גרסת Certbot.

דוגמה בלבד: תעודה התקפה ל־90 יום

לקוחות ACME ומימוש שרת לדוגמה

קיימים לקוחות ACME בשלים במגוון פלטפורמות ושפות. הטבלה כוללת גם את Boulder, שהוא מימוש של שרת רשות אישורים ולא לקוח. התמיכה באתגרים תלויה בגרסה ובתוספים המותקנים; לדוגמה, אימות DNS עשוי לדרוש מודול מתאים והרשאות מוגבלות לספק:

מימוש שפה מתאים במיוחד ל־ אתגרים נתמכים
Certbot Python Apache או Nginx ב־Linux HTTP-01, DNS-01
acme.sh סקריפט Shell סביבות מינימליות ו־Docker HTTP-01, DNS-01, TLS-ALPN-01
win-acme .NET / C# Windows / IIS HTTP-01, DNS-01, TLS-ALPN-01
Caddy Go שרת אינטרנט עם ACME מובנה HTTP-01, TLS-ALPN-01, DNS-01
Traefik Go Kubernetes או Docker HTTP-01, DNS-01, TLS-ALPN-01
cert-manager Go שילוב טבעי ב־Kubernetes HTTP-01, DNS-01
Boulder Go שרת רשות אישורים — Let's Encrypt מימוש בצד השרת

שיקולי אבטחה ושיטות עבודה מומלצות

✅ שיטות מומלצות

  • שמרו את המפתח הפרטי של החשבון במקום מאובטח; לעולם אל תכניסו אותו למערכת ניהול גרסאות.
  • השתמשו ב־DNS-01 לתעודות wildcard, המכסות תתי־דומיינים.
  • נטרו את מועדי פקיעת התעודות והגדירו התראות.
  • שקלו הפעלת HSTS לאחר בדיקת פריסת HTTPS ותוכנית התאוששות; אל תכללו תתי־דומיינים לפני שווידאתם שגם הם זמינים בחיבור מאובטח.
  • התאימו את משך התוקף למדיניות הרשות והפעילו חידוש אוטומטי עם ניטור.
  • התאימו בדיקות ביטול לרשות וללקוח: Let’s Encrypt הפסיקה את שירות OCSP ב־2025 ומשתמשת ב־CRL. אין להמליץ על OCSP stapling עבור תעודותיה החדשות.

⚠️ מכשולים נפוצים

  • הגעה למגבלות הקצב של הרשות; בדקו את המגבלות העדכניות ואת החריגים לחידושים לפני תכנון ההנפקה.
  • אי־ביצוע בדיקות בסביבת staging תחילה.
  • חומת אש החוסמת את פורט 80 לאתגרי HTTP-01.
  • עיכובים בהפצת DNS הגורמים לכישלון אתגרי DNS-01.
  • רשומות CAA החוסמות את רשות האישורים שנבחרה.
  • אי־אוטומציה של החידוש, המאפשרת לתעודות לפקוע.

ביטול תעודות באמצעות ACME

ACME מטפל גם בביטול תעודות באמצעות נקודת הקצה /revokeCert. המבקש חייב להיות מורשה לבטל את התעודה לפי התקן, למשל באמצעות חשבון מתאים או מפתח התעודה. הבקשה כוללת תעודה בקידוד DER שעברה base64url וקוד סיבה אופציונלי, למשל keyCompromise = 1.

סיכום

פרוטוקול ACME מאפשר למכן את ניהול תעודות ה־TLS ברשת. רישום חשבון, אימות שליטה בדומיין, הנפקה וחידוש נעשים בפרוטוקול מאובטח; התקנה והפעלה מחדש של שירותים תלויות ביכולות הלקוח ובתצורת השרת. אוטומציה מפחיתה עבודה ידנית, אך עדיין דורשת ניטור, הגנה על מפתחות ובדיקת שחזור.

בין שאתם מפעילים בלוג יחיד ב־Nginx עם Certbot, אשכול מיקרו־שירותים עם cert-manager, או בונים תשתית רשות אישורים משלכם עם Boulder, ‏ACME הוא הפרוטוקול התקני המאפשר את האינטרנט המוצפן המודרני.

תגיות:

ACME RFC 8555 TLS/SSL Let's Encrypt PKI אוטומציה של תעודות אבטחת אתרים Certbot DevOps

מקורות להבהרות ולעדכונים

התרגום כולל תיקוני דיוק והבהרות על בסיס המקורות הרשמיים הבאים, שנבדקו ב־25 באוקטובר 2026.

אישור רשמי לסיום שירות OCSP באוגוסט 2025; הסבר רשות האישורים על סוגי האתגרים.

Post a Comment

Previous Post Next Post