SoftEther ServerCertSet: ייבוא השרשרת המחודשת עם vpncmd

Certbot מדווח על חידוש מוצלח, הקבצים בדיסק נושאים תאריכים חדשים, והלקוחות עדיין פוגשים את הזהות הישנה. SoftEther מחזיק את תעודת ה-SSL של השרת בקונפיגורציה שלו ברמת השרת, ולכן קובץ חדש בדיסק אינו משנה דבר עד שהעלה והמפתח שלה מיובאים. הרצף שלהלן מכסה ייבוא ידני אחד, עטיפה שרצה לאחר כל חידוש, ובדיקה שקוראת מה המאזין מציג בפועל. כל שלב משאיר ראיות שאפשר להשוות לאחר החידוש הבא.

קובץ מחודש אינו משנה את זהות השרת

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

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

בחרו את האתגר שמתאים למאזין

התעודה חייבת למנות את המארח שהלקוחות מאמתים, לכן השתמשו בשם ה-DNS הציבורי ולא בתווית פנימית או בכתובת. HTTP-01 דורש מענה לאתגר בפורט 80 לרגע, וזהו מאזין זמני ולעולם אינו סיבה להזיז את הפורט של SoftEther עצמו. DNS-01 מוכיח שליטה דרך רשומה ואינו זקוק ל-HTTP נכנס כלל.

חידוש ללא השגחה פירושו אינטגרציית DNS אוטומטית עם פרטי גישה המוגבלים לאזור אחד, ולא רשומת TXT שנכתבת ביד כל חודשיים. תו כללי משנה את סוג האתגר, לא את הצורך באוטומציה הזו. החליטו על כך לפני שהתעודה הראשונה קיימת, כי החלפת סוג אתגר מאוחר יותר פירושה לגעת בקונפיגורציית הלקוח ובחומת האש יחד.

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

ייבאו את השרשרת ברמת השרת

גבו את קונפיגורציית השרת ואשרו שעדיין אפשר להגיע לממשק הניהול לפני שנוגעים בתעודה. התחברו כמנהל שרת ולא כמנהל Virtual Hub, כי התעודה שייכת לאובייקט השרת. לאחר מכן טענו את השרשרת והמפתח בנתיב מוחלט, מקבצים שהחשבון שמריץ את הפקודה יכול לקרוא. שימו לב שהנתיבים מוחלטים כי הפקודה פותרת אותם מתיקיית העבודה של התהליך שהריץ את vpncmd:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

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

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

חברו את הפריסה, לא את החידוש

לאחר שהייבוא הידני עובד, שימו בדיוק את השלבים האלה בעטיפה קטנה וקראו לה מלקוח ACME לאחר חידוש מוצלח. Certbot מגדיר את RENEWED_LINEAGE ואת RENEWED_DOMAINS עבור ה-hook, כך שהעטיפה יכולה לפעול על תעודה אחת במכונה שמנהלת כמה. סננו לפי השושלת במקום להגיב לכל חידוש במארח. העטיפה היא קוד פריסה שרץ בהרשאות השרת, לכן סקרו אותה כמו כל סקריפט אחר בתפקיד הזה.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

Hook שרץ ללא השגחה זקוק למאגר פרטי גישה מוגן משלו ולסימן כשל שמגיע לאדם. אם ההנפקה מצליחה והייבוא נכשל, נסו שוב את הייבוא במקום לבקש תעודה נוספת, כי בקשה שנייה מסתירה את פגם הפריסה מאחורי קובץ חדש. תיעוד החידוש של Certbot מבהיר שהרצה שאינה מעדכנת דבר היא תוצאה רגילה, ולכן ה-hook הוא מה שמבדיל בין השניים.

השוו את השרשרת המוצגת לקובץ

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

לאחר מכן צרו חיבור לקוח חדש, כי הפעלות שהוקמו לפני הייבוא אומתו מול הזהות הקודמת ואינן מוכיחות דבר על החדשה. אם הלקוחות מצמידים את העלה הישן, הם זקוקים לעדכון מתואם גם כשהשרשרת הציבורית תקפה, והמשימה הזו שייכת לאותו runbook של החידוש. פרוקסי הפוך לפני השירות יכול להציג תעודה טובה בעוד המאזין של VPN עדיין מחזיק בישנה, ולכן הבדיקה חייבת למנות את הפורט שאליו הלקוחות מגיעים בפועל. רשמו את טביעת האצבע לצד תאריך החידוש, כדי שההשוואה הבאה תהיה בדיקה ולא מעשה של זיכרון.