הוספת לקוח VPN בלי לבנות מחדש את ה-CA

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

מה בנייה מחדש באמת הורסת

אתחול מחדש של PKI מחליף את הספרייה במבנה ריק: מפתח ותעודת CA חדשים, מסד הנפקות ריק ומונה סדרות חדש. הלקוחות לא עוקבים מעצמם; הפרופילים שלהם מצמידים את ה-CA הישן, ולכן כל התקן צריך להירשם מחדש, והבלתי נגישים ידנית.

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

העתקת המפתח הפרטי של ה-CA לצד השרת הפעיל היא הקיצור האחר שכדאי לסרב לו: היא הופכת רשות חתימה שאמורה לשבת מחוץ לרשת לעוד קובץ במארח שמסיים תעבורה לא מהימנה.

תנאי ראשון: האם מצב המנפיק עדיין נגיש?

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

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

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

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

תנאי שני: מי מחזיק במפתח הפרטי החדש?

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

עם Easy-RSA 3 מול CA קיים, ייבוא וחתימה של בקשה הם שתי פקודות:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

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

תנאי שלישי: האם השרת צריך יותר מתעודה?

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

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

הנוהל המצטבר ומתי בנייה מחדש נכונה

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

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

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

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