איך ליצור מפתח לקוח של VPN ולשלוח CSR לחתימה

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

שלב 1: צרו את המפתח במקום שבו הוא יחיה

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

זרימת התוכנה נראית כך, כשהמפתח והבקשה נוצרים בסשן אחד:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

שלב 2: שימו את הזהות בבקשה, לא בדואר

החליטו מה ה-VPN מאמת באמת לפני שהבקשה נוצרת, כי התשובה הזו שייכת לתוך ה-CSR. OpenVPN קושר באופן מסורתי את זהות הלקוח לשם המשותף של התעודה, וכלים כמו strongSwan מתאימים מחרוזת זהות לנושא או לשם חלופי של הנושא. דואר שאומר ששמי alice אינו ראיה, ובקשה שהנושא שלה אומר את אותו דבר טובה רק במעט.

הוסיפו שם חלופי לנושא כשהמאמת שלכם בודק אחד, כי התאמה מודרנית מתעלמת לעתים קרובות מה-CN הישן:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

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

שלב 3: אמתו את הבקשה לפני שאתם חותמים עליה

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

החלק המכני הוא פקודה אחת, והיא אמורה להדפיס תוצאת אימות יחד עם הנושא:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

שלב 4: אשרו, ואז חתמו עם הרחבות מפורשות

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

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

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

שלב 5: התקינו אותו לצד המפתח המתאים והוכיחו את הזיווג

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

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

שני ה-digests חייבים להתאים. אז התחברו וודאו שהזהות שהשרת רושם היא זו שאישרתם, ולא רק שהמנהרה עלתה. אם המפתח אבד או המכשיר הוחלף, התשובה היא ביטול בתוספת בקשה חדשה מהמכשיר החדש; בקשה מהמנהל לשלוח בחזרה מפתח ממקום אחר לא משחזרת את המקור ושוברת בשקט את המודל שהפך את הבקשה לבטוחה.