היסטורית , ה שמות מכובדים בתעודות (שצוינו על ידי X.500) נועדו לייעד ישות בתוך ה ספרייה, שהיא המאגר העולמי, העולמי, בעל מבנה עצים לנתוני ניהול זהות. ניתן לחשוב על המדריך כשרת LDAP ענק עם האצלה לשרתי משנה, באופן דומה במקצת ל DNS. במציאות, עם זאת, המדריך מעולם לא היה קיים, ו- LDAP היא קבוצת משנה מעשית של פרוטוקול הגישה לספריות . ובכל זאת, עקרונות השמות נותרו בתוקף.

DN הוא רצף מסודר של אלמנטים שהוקלדו בשם, אשר עבור הספריה צריכים להגיע לפי הסדר: מדינה, מדינה או מחוז, ארגון, ארגוני. יחידה (אולי כמה), ואז שם נפוץ. X.500 הוא פתוח למדי וסידורים אחרים אפשריים (והפורמט תומך בהצבת מספר אלמנטים של שם באותה רמה), אך הרעיון הגס הוא שהשם המשותף הוא הרמה הנמוכה ביותר של ההיררכיה. לפיכך, השם המשותף לישות, כלשהו ישות, הוא רכיב השמות המדויק ביותר.

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

• הקידוד חייב להתאים למפרט X.509 ASN.1: השם המשותף מוגבל ל -64 תווים (64 נקודות נקודות אם אתה משתמש ב UTF8String , כפי שאתה אמור לעשות, לפי התקן).
• IssuerDN של אישור חייב להיות שווה ל- SubjectDN של מנפיקו. תיאורטית כללי השוויון אינם רגישים לאותיות רישיות, אך הכללים יכולים להיות מורכבים ליישום בעולם יוניקוד מלא, לכן כדאי שתוודא שיש לך שוויון בתים לבית, שיעבוד כהלכה בכל מקום.
• האישור של שרת SSL חייב להכיל את שם השרת כמצופה מהלקוח (אם משתמשים ב- HTTPS, שם זה יהיה זה בכתובת האתר). זה מצוין ב- RFC 2818. בדרך כלל משתמשים בתוסף נושא Alt Alt , אך השם המשותף משמש כגיבוי למקרה שחסר סיומת זו. מכיוון שלא תמיד יישומי לקוח SSL דבקו בקפדנות ב- RFC הרלוונטי, עדיף להימנע מבעיות, אם האישור של שרת ה- SSL מכיל שם ה- DNS של השרת כשם נפוץ (שם מוסמך לחלוטין, כמו ב- " security.stackexchange.com").
• כאשר "מוצג" אישור, או זהות המופקת מאישור, למשתמש אנושי, השם המשותף יופיע באופן בולט. לדוגמא, אם משתמשים בכניסה לכרטיס חכם במערכת Windows, אז מסך הכניסה יציג את השם הנפוץ באותיות גדולות כאשר מכניסים את הכרטיס החכם. לכן מוטב שיהפוך את השם המשותף למשמעותי עבור האדם הפשוט.

במקרה של שרת VPN, האישור מהלקוח נועד לשימוש השרת בלבד. השרת מפרש את תוכן האישור, כולל ה- DN בנושא והשם הנפוץ שלו, בכל דרך שהיא רואה לנכון, כולל התעלמות ממנה לחלוטין. למשל, בהקשר של Microsoft IIS + Active Directory, כאשר לקוח מאומת באמצעות אישור, השרת ישתמש ב שם ראשי המשתמש כפי שנמצא ב שם Alt נושא הרחבה, תחת OID ספציפי למיקרוסופט. השם הנפוץ עשוי להיות מוצג למשתמש האנושי, אם יש משתמש אנושי (למשל כחלק מקופץ לבחירת אישורים), אך הוא יתעלם ממנו לצורך אימות.

באופן כללי, אישורי הלקוח שלך יצטרכו להכיל את כל מה שנדרש על ידי מערכת האימות ששרת ה- VPN משתמש בה, ומכיוון שניתן להגדיר את זה מאוד, זה תלוי הרבה בהקשר המקומי. לדוגמא, שרת ה- VPN רשאי להעביר אימות לשרת RADIUS, ובמקרה זה מאפייני האישור (כולל השם המשותף) יתוארו על ידי תיעוד שרת RADIUS; עבור שרת ה- VPN, זו תהיה רק ​​כתם אטום.

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

בדרך כלל נתיב החתימה קובע אם האישור מותר, ואילו ה- CN קובע איזה האישור המותר.