PKCS12, PEM או DER: מה לקוח VPN באמת צריך
האריזה קובעת אם הלקוח מייבא את הזהות, לא אם היא מהימנת. השוו בין PKCS12, PEM ו-DER, ואז אמתו.
בדיוני תעודות מסתובבות שתי טענות. הראשונה היא שקובץ .p12 הוא האפשרות החזקה ו-.pem הוא הרפויה; השנייה היא שקובץ טקסט חייב להיות בטוח לשליחה כי אפשר לקרוא אותו. אף אחת מהן לא שורדת דקה של בדיקה.
PKCS12, PEM ו-DER מתארים כיצד אובייקטי תעודה נארזים ומקודדים. הם לא קובעים מי הצד השני, אם המנפיק מהימן או אם הקובץ דורש סיסמה.
מה שהלקוח מקבל הוא שאלת תאימות. מה שהקובץ מכיל הוא שאלת זהות. הפרידו בין השניים ורוב שגיאות הייבוא יפסיקו להיות מסתוריות.
שלושה מכילים, מודל אובייקט אחד
התחילו במה שבאמת יש לכם. תעודה היא הצהרה חתומה על מפתח ציבורי. המפתח הפרטי הוא חומר נפרד שמוכיח שאתם שולטים במפתח הזה. שרשרת היא קבוצת המנפיקים שמקשרים את התעודה שלכם לשורש שהלקוח סומך עליו. שלושתם קיימים ללא תלות באריזה.
קובץ PKCS12, בדרך כלל .p12 או .pfx, הוא מכיל המוגדר ב-RFC 7292 שיכול לשאת מפתח פרטי, תעודה אחת או יותר והשרשרת בגוש אחד מוגן בסיסמה, עם כינוי שמשם את הזהות. קובץ PEM הוא מסגרת טקסט המוגדרת ב-RFC 7468: גוף base64 בין שורות BEGIN ו-END, וקובץ אחד יכול להחזיק כמה גושים ברצף. DER הוא הקידוד הבינארי של אותן מבני ASN.1, וגוף PEM הוא פשוטו כמשמעו DER עטוף ב-base64.
המשפט האחרון שווה לזכור. המרת PEM ל-DER כותבת מחדש את המסגרת, לא את התוכן, וההמרה חזרה מחזירה את הבתים המקוריים.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
קידוד אינו הצפנה
base64 הוא אלפבית הובלה. הוא לא מסתיר דבר, וכל אחד יכול לפענח גוש PEM במעטפת. קובץ DER הוא בינארי וציבורי באותה מידה. אף אחת מהתכונות אינה הגנה, ואף אחת מהן לא מרמזת שקיימת סיסמה.
ההגנה האמיתית נמצאת בחומר המפתח. חבילת PKCS12 יכולה להצפין את תוכנה תחת מפתח הנגזר מסיסמה. מפתח PEM פרטי יכול להיות מוצפן בגוש כותרת ישן או להישמר ב-PKCS#8 EncryptedPrivateKeyInfo. תעודה לבדה אינה מחזיקה דבר סודי, ולכן ייצוא שהפיק רק תעודה משאיר את הלקוח בלי יכולת לבצע אימות, בכל פורמט שתעטפו אותו.
הסיומת היא רמז, לא חוזה. קבצים המסתיימים ב-.cer וב-.crt מופיעים בשני הקידודים, והתקנים מייצאים תעודות DER תחת שמות .pem לעתים קרובות מספיק כדי שניחוש לפי הסיומת יעלה אחר צהריים. קראו את הבתים הראשונים במקום: קובץ PEM נפתח בשורת BEGIN, בעוד DER מתחיל ב-0x30 כי המבנה החיצוני הוא SEQUENCE.
למה הייבוא באמת נכשל
הודעות השגיאה של הלקוח דוחסות כמה בעיות שונות למשפט אחד על תעודה לא חוקית, אז הפרידו אותן לפי סיבה. הנפוצה ביותר היא אי-התאמת קידוד: לקוח שמנתח PEM מחזיר שגיאת ניתוח על קובץ DER, והתיקון הוא המרה ולא תעודה חדשה. השנייה היא מפתח חסר, שבה התעודה תקינה והזהות אינה ניתנת להוכחה. השלישית היא השרשרת, שבה חבילה בלי התעודה הביניים נראית נכונה בתיבת הייבוא ונכשלת במהלך לחיצת היד.
פרמטרי הצפנה גורמים לרביעית, והיא נראית בדיוק כמו סיסמה שגויה. התקנים ישנים ייצאו קבצי PKCS12 עם RC2-40 ו-3DES, ש-OpenSSL 3 דוחה אלא אם ספק ה-legacy נטען. ייצוא מחדש מהתקן עם AES-256-CBC ו-PBKDF2 הוא התיקון העמיד. השארת צפנים ישנים פעילים תמידית במחשב לקוח בגלל קובץ אחד היא עסקה גרועה.
החמישית היא עמימות. מכיל עם שני מפתחות ושתי תעודות, או קובץ PEM עם שלושה גושי CERTIFICATE, מכריח את הלקוח לבחור, ובחירתו היא לעתים קרובות פשוט הפריט הראשון. כשמנהרה עולה עם הזהות הלא נכונה, זו בדרך כלל הסיבה.
בדקו לפני ההמרה
קראו את המבנה בלי להדפיס סודות. openssl pkcs12 -in bundle.p12 -info -noout מדווח על אלגוריתמי ההצפנה ועל הכינויים תוך דיכוי פלט המפתח והתעודה, ו מדריך openssl-pkcs12 מתעד את הדגלים. הסרת -noout והוספת -nodes נועדה להפקת קבצים שאתם מתכוונים לשמור, לא להצצה מהירה, כי היא כותבת את המפתח הפרטי בגלוי.
עבור תעודה, openssl x509 -in cert.pem -noout -subject -issuer -dates עונה על מה שתיבת ייבוא לא תענה, והוספת -ext subjectAltName מציגה את השמות שהתעודה באמת תקפה עבורם. אם הקובץ הוא DER, הוסיפו -inform DER; הדגל האחד הזה פותר את רוב שגיאות unable-to-load.
התאמת מפתח לתעודה היא פעולה מכנית, וכדאי לעשותה לפני כל ייבוא:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
תמצומות זהות פירושן שהזוג שייך יחד. תמצומות שונות פירושן שיש לכם את המפתח הלא נכון, ושום המרת פורמט לא תשנה זאת.
מה שהפורמט אף פעם לא משנה
החלטות אמון מתקבלות מעל המכיל. הלקוח עובר את השרשרת עד לשורש במאגר שלו, בודק את חלון התוקף, בודק שימוש מורחב במפתח לאימות לקוח, ובצד השרת בודק שהשם שאליו חייג מופיע בתעודה. אף אחד מהשלבים האלה לא קורא סיומת קובץ.
לכן שינוי שם קובץ עד להיעלמות שגיאה הוא דרך כל כך אמינה לבזבז זמן. הייבוא מצליח, הזהות עדיין שגויה, והכשל חוזר במהלך לחיצת היד שם ההודעה פחות מועילה. זו גם הסיבה שחבילה שיוצאה לפני שנתיים מיובאת נקי ועדיין נדחית: תאריך התפוגה נסע בתוך התעודה, לא בשם הקובץ.
סדר שמונע עבודה מחדש
שאלו את התיעוד של הלקוח אילו קידודים הוא מקבל ואיזה מכיל הוא מצפה לו עבור זהות לקוח, ואז הסתכלו במה שקיבלתם. אם הלקוח רוצה זהות אחת ניתנת לייבוא ויש לכם קבצי PEM נפרדים, בנו את החבילה פעם אחת עם סיסמה שאתם שולטים בה ושמרו את המקורות. אם הוא רוצה PEM, חלצו את המפתח והשרשרת, ואז הסירו את קבצי הביניים באמצעות תהליך טיפול באישורים שהצוות שלכם כבר משתמש בו.
אחרי הייבוא, אמתו את הזהות ולא את תיבת הדו-שיח: נושא, מנפיק, תפוגה והשם שהלקוח יציג. שם ידידותי ברשימה הוא תווית, לא זהות מאומתת. אם המנהרה נכשלת אחר כך, אתם מאתרים תקלות באימות או בניתוב במקום באריזה, וזו שיחה קצרה בהרבה.