در رمزنگاری، گواهی دیجیتال یا گواهی کلید عمومی سندی الکترونیکی است که یک امضای دیجیتال را به کار می‌برد تا یک کلید عمومی را به یک هویت مثل نام شخص یا سازمان و آدرس و اطلاعاتی از این دست، نسبت دهد.


انواع مختلف گواهی
    * گواهی های کلید عمومی X.۵۰۹
    * گواهی های زیرساخت کلید عمومی ساده SPKI یا (Simple Public Key Infrastructure)
    * گواهی های کلید عمومی مخفی کردن نسبتا خوب PGP یا (Pretty Good Privacy)
    * گواهی اختیاری (Attribute Certificate)

این گواهی ها فرمتهای متفاوتی دارند. در برخی موارد، ممکن است یک نوع گواهی نسخه های گوناگونی داشته باشد، و از یک نسخه واحد به روشهای گوناگونی نمونه تهیه شود. برای مثال ۳ نسخه از گواهی کلید عمومی X.۵۰۹ موجود است. نسخه ۱ زیرمجموعه نسخه ۲ و نسخه ۲ زیرمجموعه نسخه ۳ می‌باشد. زیرا یک کلید عمومی نسخه ۳ شامل ضمائم متعدد انتخابی است که بنا به کاربرد می‌تواند در نمونه‌های مختلفی تهیه شود. برای مثال، گواهی های انتقال الکترونیکی امن (SET)، همان گواهی های کلید عمومی نسخه ۳ از X.۵۰۹ هستند که ضمائم آن منحصرا برای تبادلات SET تعریف شده اند. در اینجا منظور از گواهی همان گواهی کلید عمومی نسخه ۳ از X.۵۰۹ است. حال به ساختار و محتوای این گواهی می پردازیم.


انواع کلاسهای گواهی دیجیتال
    * گواهی کلاس۱: مخصوص امضا الکترونیکی و رمزنگاری پست الکترونیک
    * گواهی کلاس۲: مخصوص امضا الکترونیکی و رمزنگاری فایل های الکترونیکی ونرم‏افزارها
    * گواهی کلاس۳: مخصوص تولید گواهی برای مراجع گواهی دیگر
    * گواهی کلاس SSL: مخصوص تأمین امنیت سرورهای سازمان‏ها و مراکزی که وب‌گاه دارند و یا خدمات تحت وب ارائه می نمایند. این گواهی در سه شکل مخصوص سرور و مخصوص کاربر و هردو صادر می‌گردد.


معناشناسی و ساختار گواهی

در ژانویه ۱۹۹۹ IETF استانداردی تحت عنوان RFC۲۴۵۹ برای کلید عمومی X.۵۰۹ (PKIX) ارائه نموده است. در سال ۲۰۰۲ استاندارد RFC۳۲۸۰ جایگزین استاندارد قبلی شد. اگرچه RFC۳۲۸۰ به منظور کاربردهای اینترنتی تدوین شده بود، اما تعدادی از توصیه‌های آن می‌توانند در محیط سازمان و به طبع هر جای دیگر به کار برده شوند. شکل زیر ساختار کلی یک گواهی X.۵۰۹ نسخه ۳ را نشان می‌دهد. فیلدهای موجود در گواهی در زیر آمده است.





    * نسخه (Version): نشاندهنده نسخه گواهی است (۱، ۲ یا ۳)
    * شماره سریال (Serial Number): شناسه‌ای یکتاست که هویت صادرکننده را تعیین می‌کند.
    * الگوریتم امضا (Signature): نوع الگوریتمی که با آن گواهی تولید و صادر شده است. امضا نماینگر شناسه الگوریتمی است (که شامل شناسه عنصر یا OID، و پارامترهای مربوط به آن می‌باشد) که برای محاسبه امضای دیجیتالی روی گواهی به کار برده می‌شود.

OID، نمایشی منحصر به فرد از یک عنصر است. OID، دنباله‌ای از ارقام است که با ممیز اعشاری یا نقطه از هم جدا شده اند (مثل یک آدرس اینترنتی IP که در آن ارقام با نقطه از هم جدا شده اند). OID ها به طور طبیعی سلسله مراتبی هستند و در RA های بین المللی، ملی، یا سازمانی ثبت شده اند تا اطمینان حاصل شود که یک OID منحصر به فرد به هر عنصر نسبت داده شده است. برای متال OID برای SHA-۱ با RSA به این صورت می‌باشد: ۱٫۲.۸۴۰٫۱۱۳۵۴۹٫۱.۱٫۵.

    * صادر کننده (Issuer): نام متمایز (DN) یک مرجع صدور گواهی است که همیشه باید درج شده باشد.

DN یک نام گذاری سلسله مراتبی قراردادی است که در توصیه‌های X.۵۰۰ درج شده است. DN ها برای این طراحی شده اند تا مطمئن شویم که نامهای موجودیت ها یکتاست. DN ها تسلسلی از نام های متمایز وابسته (RDN) هستند که از نودِ سطح بالا یا ریشه تا آخرین نود نام گذازی شده اند. برای مثال "C=CA, O=ADGA OU=AEPOS Technologies, CN=Steve Lloyd " نمونه‌ای از یک DN است. دقت داشته باشید که هر RDN (C=CA یک RDN است، O=ADGA یک RDN است و...) باید در هر سطح منحصر به فرد باشد، در غیر اینصورت تضمینی برای یکتا بودن DN نخواهد بود.

    * اعتبار (Validity): بازه زمانی که در آن مدت گواهی معتبر بوده و پس از آن باید باطل گردد. شامل تاریخ شروع و خاتمه اعتبار است.
    * موضوع (Subject): DNِ دارنده گواهی است که نباید خالی باشد. مگر اینکه از فرمِ نام دیگر استفاده شود. (به فیلد ضمائم مراجعه کنید)
    * اطلاعات کلید عمومی دارنده گواهی (Subject Public Key Info): کلید عمومی (و الگوریتم معین کننده) مربوط به موضوع که باید همیشه درج شده باشد.
    * ID یکتای صادرکننده گواهی (Issuer Unique ID): یک شناسه اختیاری یکتا برای صادرکننده گواهی است که تنها در نسخه‌های ۲ و ۳ می‌آید. این فیلد به ندرت در عمل استفاده می‌شود و در RFC۳۲۸۰ نیز به آن توصیه نشده است.
    * ID یکتای موضوع (Subject Unique ID): یک شناسه اختیاری یکتا برای دارنده گواهی است که تنها در نسخه‌های ۲ و ۳ می‌آید. این فیلد به ندرت در عمل استفاده می‌شود و در RFC۳۲۸۰ نیز به آن توصیه نشده است.

یک نشانه اهمیت به هر ضمیمه گواهی نسبت داده شده است. در حالت کلی ضمائم می‌توانند مهم یا بی اهمیت باشند. ضمیمه‌ای که نشان با اهمیت دارد باید به کاربرده شود، در غیر اینصورت نباید از گواهی استفاده شود. اگر یک ضمیمه بی اهمیت شناخته شده باشد، می‌توان آنرا در نظر نگرفت و یا در صورت امکان آنرا به کار نگرفت.

 ساختارهای دیگر گواهی
همانطور که قبلا گفته شد، علاوه بر نسخه ۳ گواهی X.۵۰۹ انواع دیگر گواهی نیز وجود دارند. در زیر مختصری توضیح برای آنها آورده شده است.

SPKI
در مقابلِ IETF PKIX Working Group که بر موارد استفاده X.۵۰۹ در اینترنت تمرکز دارد، گروه کاری IETF دیگری با عنوان SPKI تشکیل گردید که بر زیرساخت ساده تری از کلید عمومی برای کاربرد اینترنت تمرکز داشت. پروانه IETF SPKI Working Grou در زیر آمده است: ساخت استاندارد اینترنتی برای ساختار گواهی کلید عمومی IETF، امضای مربوط به آن، ساختارهای دیگر آن، و پروتکل های دریافت کلید. ساختار گواهی کلید و پروتکل های مربوطه باید برای فهم، پیاده سازی و استفاده، آسان باشند. IETF SPKI Working Group تعدادی مستند فنی و اطلاعاتی تهیه کرده است:

 SPKI certificate format
SPKI certificate theory
SPKI requirements
  SPKI examples

که در آدرسِ http://www.ietf.org/html.charters/REMOVED/spki-charter.html موجود می‌باشند. از آنجا که تاکیید SPKI بیشتر بر اجازه است تا هویت، به آن گواهی اجازه نیز گفته می‌شود. هدف اصلی گواهی اجازه SPKI، تعیین دسترسی ها است. همچنین تواناییِ محول کردن دسترسی را نیز دارد. اگرچه گواهی اجازه SPKI اشتراک هایی با گواهی کلید عمومی X.۵۰۹ دارد (مثل صادرکننده و اعتبار)، اما syntax و معنای این فیلدها در بسیاری از موارد یکی نمی‌باشد. در حال حاضر تقاضای کمی برای این گواهی ها وجود دارد، و مشتریان CA و PKI تمایلی به پیاده سازی گواهی دیگری با syntax های متفاوت از گواهی های نسخه ۳ ازX.۵۰۹ ندارند.

PGP
PGP روشی برای امضا و رمزگذاری دیجیتالی فایلها و ایمیل ها می‌باشد. آخرین نسخه آن که OpenPGP خوانده می‌شود، یک استاندارد IETF به نام OpenPGP Message Format [RFC۲۴۴۰] است. PGP ساختار پکت هایی که پیام ها و فایلها را از جانب یک موجودیت برای موجودیت دیگر حمل می‌کنند مشخص می‌کند. همچنین PGP ساختار پکت هایی که کلیدهای PGP (گواهی های PGP) را بین موجودیت ها حمل می‌کنند را نیز مشخص می‌کند. اگرچه PGP کاربرد زیادی در سطح اینترنت دارد، اما گزینه مناسبی برا استفاده در سطح اینترانت سازمانی نیست. چونکه تصمیماتِ اعتماد به جای سازمان به افراد واگذار می‌شود. از آنجا که اکثر مشتریان CA و PKI تمرکز بر قلمرو سازمانی دارند، تمایلی بر خریدِ محصولاتِ OpenPGP ندارند.

SET
مشخصه‌های معاملات الکترونیکی امن SET، [SET۱; SET۲; SET۳] استانداردی برای پشتیبانی از پرداخت های کارتهای اعتباری در سطح شبکه‌های توزیعی مانند اینترنت را تعریف می‌کنند. SET پروتکل استاندارد پرداخت را تعریف می‌کند. SET از ساختار نسخه ۳ از گواهی X.۵۰۹ پیروی می‌کند و ضمیمه‌های خصوصی به آن می افزاید که تنها در زمینه SET معنا دارند. شکل زیر یک گواهی SET را نشان می‌دهد. البته تمام ضمائم در ان آوده نشده اند. مثلا ضمیمه Hashed Root Key که در یک گواهی SET root CA می‌آید را نشان نمی‌دهد

گواهی های اختیاری
نسخه ۲۰۰۰ از X.۵۰۹ مفهوم و کاربرد گواهی های اختیاری را به تفصیل شرح داده و حتی چارچوبی برای اساسِ ایجادِ زیرساخت های مدیریت ویژه PMIs ارائه می‌دهد. موضوع PMI بسیار گسترده است و می‌تواند عنوان یک کتاب باشد. در اینجا تنها کافی است بدانید که اگرچه گواهی هایاختیاری در توصیه‌های X.۵۰۹ تعریف شده اند، ولی گواهی های اختیاری گواهی های کلید عمومی نیستند. گواهی های اختیاری برای حمل ویژگی های یک موضوع طراحی شده اند تا مدیریت ویژه انعطاف پذیر و مقیاس پذیر را سهولت بخشند. گواهی اختیاری ممکن است برای تصدیق هویت دارنده گواهی اختیاری به یک گواهی کلید عمومی اشاره داشته باشد.

مدیریت گواهی (Managing Certificates)
علاوه بر ذخیره گواهی ها، ابزارهای Administrator خدمات صدور، ابطال و انتشار CRL (Certificate Revocation List) و وارد و صادر کردن گواهی ها را ارائه می‌دهد. Administrator می‌تواند از این ابزارها برای مدیریت گواهی های خودشان و کاربران دیگر، یک کامپیوتر یا یک service دیگر استفاده کند.

صدور گواهی(Issuing Certificates)
وظایف مربوط به صدور گواهی:
    * پذیرفتن یک درخواست گواهی
    * صادر کردن یک درخواست گواهی
هنگامی که کاربر درخواست برای گواهی را در یک stand-alone CA ثبت می‌کند، درخواستِ او در وضعیتِ pending قرار می‌گیرد تا زمانیکه CA Administrator آن درخواست را قبول یا رد کند. کاربر همچنین به صفحات وب که خدمات گواهی را ارائه می‌کنند، دسترسی داشته و از وضعیت گواهی های خود مطلع می‌شود. این رویه تنها برای یک stand-alone CA به کار برده می‌شود. که در آن تنظیم شده هر درخواست جدید گواهی را در وضعیتِ pending قرار دهد.


ابطال گواهی(Revoking Certificates)
برای حفظ تمامیتِ (integrity) PKI در یک سازمان ممکن است لازم شود که CA administrator گواهی ها را قبل از تاریخ انقضاءشان باطل کند. برای مثال، اگر شخصی که برای او گواهی صادر شده سازمان را ترک کند، باید گواهی او باطل گردد. یا اینکه کلید خصوصیِ یک گواهی کشف شود، و یا یک حادثه امنیتی بر اعتبار یک گواهی تاثیر بگذارد. Administrator گواهی ها را در CA باطل می‌کند. پس از اینکه یک گواهی باطل شد، به پوشه گواهی های باطل شده منتقل می‌شود. و گواهی های باطل شده در نوبت بعدیِ انتشار CRL در لیست قرار می‌گیرد.


انتشار یک لیست از گواهی های باطل شده (Publishing a Certificate Revokation List)
یک CA به طور خودکار CRL را در فواصل زمانی که administrator تعریف کرده، به روز رسانی و انتشار می‌کند. می‌توان بنا به درخواست نیز CRL را با استفاده از CRL publishing wizard انتشار کرد. Clientهایی (سرویس گیرنده ای) که یک کپی از CRL انتشار شده قبلی را در حافظه خود دارند، تا زمانی که نوبت بعدی به روز رسانی نرسیده آنرا به کار می‌گیرند. اگرچه در این فاصله بنا به درخواست CRL جدیدی منتشر شده باشد.


وارد و صادر کردن گواهی (Importing and Exporting Certificates)
وظایف مربوطه:
    * بررسی ساختار فایل گواهی (Examining Certificate File Formats)
    * وارد کردن گواهی
    * صادر کردن گواهی
Snap-in گواهی ابزارهایی در اختیار administrator می گذارد تا بتوان گواهی ها را به همراه مسیرهای گواهی و کلیدهای خصوصی وارد یا خارج کند. می‌توان گواهی را از یک کاربر دیگر، کامپیوتر، یا CA دیگر وارد کرد. یا می‌توان گواهی را برای استفاده در کامپیوتر دیگر صادر نمود. گواهی ها را می‌توان با ساختار فایلهای استاندارد گوناگون دیگر وارد یا صادر کرد.


تنظیمات Active Directory برای گواهی ها (Configuring Active Directory for Certificates)
ممکن است لازم باشد سازمان صحت کاربران خارجی که در Active Directory حساب ندارند را، تصدیق کند. وظایفی که مربوط به تنظماتِ Active Directory برای گواهی ها می‌باشد:

    * کاربران خارجی باید یک گواهی داشته باشند
    * کاربران خارجی باید یک حساب کاربری (user account) داشته باشند
    * گواهی های کاربران خارجی باید توسط یک CA مورد اعتماد (trusted CA) صادر شوند
    * باید بین گواهی کاربر خارجی و حساب Active Directory نگاشت نامها (Name Mapping) وجود داشته باشد.

منبع:ویکی‌پدیا