گواهی دیجیتال
در رمزنگاری، گواهی دیجیتال یا گواهی کلید عمومی سندی الکترونیکی است که یک امضای دیجیتال را به کار می‌برد تا یک کلید عمومی را به یک هویت مثل نام شخص یا سازمان و آدرس و اطلاعاتی از این دست، نسبت دهد.
نوعاً در یک طرح زیرساخت کلید عمومی ، امضا از طرف مرجع صدور گواهی دیجیتال است. در یک طرح شبکه اعتماد، امضا یا از طرف خود کاربر یا کاربران است. در هر صورت، امضاها در یک گواهی از طرف یک امضاکننده رسمی است و مصداق این است که مشخصات هویت و کلید عمومی مربوط به هم می‌باشند.این گواهی‌ها فرمتهای متفاوتی دارند. در برخی موارد، ممکن است یک نوع گواهی نسخه‌های گوناگونی داشته باشد، و از یک نسخه واحد به روش‌های گوناگونی نمونه تهیه شود. برای مثال ۳ نسخه از گواهی کلید عمومی X.۵۰۹ موجود است. نسخه ۱ زیرمجموعه نسخه ۲ و نسخه ۲ زیرمجموعه نسخه ۳ می‌باشد. زیرا یک کلید عمومی نسخه ۳ شامل ضمائم متعدد انتخابی است که بنا به کاربرد می‌تواند در نمونه‌های مختلفی تهیه شود. برای مثال، گواهی‌های انتقال الکترونیکی امن (SET)، همان گواهی‌های کلید عمومی نسخه ۳ از X.۵۰۹ هستند که ضمائم آن منحصرا برای تبادلات SET تعریف شده‌اند.  در اینجا منظور از گواهی همان گواهی کلید عمومی نسخه ۳ از X.۵۰۹ است. حال به ساختار و محتوای این گواهی می پردازیم.در ژانویه ۱۹۹۹ IETF استانداردی تحت عنوان RFC۲۴۵۹ برای کلید عمومی X.۵۰۹ (PKIX) ارائه نموده‌است. در سال ۲۰۰۲ استاندارد RFC۳۲۸۰ جایگزین استاندارد قبلی شد. اگرچه RFC۳۲۸۰ به منظور کاربردهای اینترنتی تدوین شده بود، اما تعدادی از توصیه‌های آن می‌توانند در محیط سازمان و به طبع هر جای دیگر به کار برده شوند.  شکل زیر ساختار کلی یک گواهی X.۵۰۹ نسخه ۳ را نشان می‌دهد. فیلدهای موجود در گواهی در زیر آمده‌است.
OID، نمایشی منحصر به فرد از یک عنصر است. OID، دنباله‌ای از ارقام است که با ممیز اعشاری یا نقطه از هم جدا شده اند (مثل یک آدرس اینترنتی IP که در آن ارقام با نقطه از هم جدا شده اند). OID‌ها به‌طور طبیعی سلسله مراتبی هستند و در RA‌های بین‌المللی، ملی، یا سازمانی ثبت شده اند تا اطمینان حاصل شود که یک OID منحصر به فرد به هر عنصر نسبت داده شده‌است. برای متال OID برای SHA-۱ با RSA به این صورت می‌باشد: ۱٫۲.۸۴۰٫۱۱۳۵۴۹٫۱.۱٫۵. DN یک نام‌گذاری سلسله مراتبی قراردادی است که در توصیه‌های X.۵۰۰ درج شده‌است. DN‌ها برای این طراحی شده اند تا مطمئن شویم که نامهای موجودیت‌ها یکتاست. DN‌ها تسلسلی از نام‌های متمایز وابسته (RDN) هستند که از نودِ سطح بالا یا ریشه تا آخرین نود نام گذازی شده‌اند. برای مثال "C=CA, O=ADGA OU=AEPOS Technologies, CN=Steve Lloyd " نمونه‌ای از یک DN است. دقت داشته باشید که هر RDN (C=CA یک RDN است، O=ADGA یک RDN است و...) باید در هر سطح منحصر به فرد باشد، در غیر اینصورت تضمینی برای یکتا بودن DN نخواهد بود.
یک نشانه اهمیت به هر ضمیمه گواهی نسبت داده شده‌است. در حالت کلی ضمائم می‌توانند مهم یا بی اهمیت باشند. ضمیمه‌ای که نشان با اهمیت دارد باید به کاربرده شود، در غیر اینصورت نباید از گواهی استفاده شود. اگر یک ضمیمه بی اهمیت شناخته شده باشد، می‌توان آن را در نظر نگرفت یا در صورت امکان آن را به کار نگرفت.
همانطور که قبلاً گفته شد، علاوه بر نسخه ۳ گواهی X.۵۰۹ انواع دیگر گواهی نیز وجود دارند. در زیر مختصری توضیح برای آن‌ها آورده شده‌است.
در مقابلِ IETF PKIX Working Group که بر موارد استفاده X.۵۰۹ در اینترنت تمرکز دارد، گروه کاری IETF دیگری با عنوان SPKI تشکیل گردید که بر زیرساخت ساده‌تری از کلید عمومی برای کاربرد اینترنت تمرکز داشت. پروانه IETF SPKI Working Grou در زیر آمده‌است: ساخت استاندارد اینترنتی برای ساختار گواهی کلید عمومی IETF، امضای مربوط به آن، ساختارهای دیگر آن، و پروتکل‌های دریافت کلید. ساختار گواهی کلید و پروتکل‌های مربوطه باید برای فهم، پیاده‌سازی و استفاده، آسان باشند. IETF SPKI Working Group تعدادی مستند فنی و اطلاعاتی تهیه کرده‌است:
که در آدرسِ https://web.archive.org/web/20080324204135/http://www.ietf.org/html.charters/REMOVED/spki-charter.html موجود می‌باشند. از آنجا که تاکیید SPKI بیشتر بر اجازه است تا هویت، به آن گواهی اجازه نیز گفته می‌شود. هدف اصلی گواهی اجازه SPKI، تعیین دسترسی‌ها است. همچنین تواناییِ محول کردن دسترسی را نیز دارد. اگرچه گواهی اجازه SPKI اشتراک‌هایی با گواهی کلید عمومی X.۵۰۹ دارد (مثل صادرکننده و اعتبار)، اما syntax و معنای این فیلدها در بسیاری از موارد یکی نمی‌باشد. در حال حاضر تقاضای کمی برای این گواهی‌ها وجود دارد، و مشتریان CA و PKI تمایلی به پیاده‌سازی گواهی دیگری با syntax‌های متفاوت از گواهی‌های نسخه ۳ ازX.۵۰۹ ندارند.
PGP روشی برای امضا و رمزگذاری دیجیتالی فایلها و ایمیل‌ها می‌باشد. آخرین نسخه آن که OpenPGP خوانده می‌شود، یک استاندارد IETF به نام OpenPGP Message Format [RFC۲۴۴۰] است. PGP ساختار پکت‌هایی که پیام‌ها و فایلها را از جانب یک موجودیت برای موجودیت دیگر حمل می‌کنند مشخص می‌کند. همچنین PGP ساختار پکت‌هایی که کلیدهای PGP (گواهی‌های PGP) را بین موجودیت‌ها حمل می‌کنند را نیز مشخص می‌کند. اگرچه PGP کاربرد زیادی در سطح اینترنت دارد، اما گزینه مناسبی برای استفاده در سطح اینترانت سازمانی نیست. چونکه تصمیماتِ اعتماد به جای سازمان به افراد واگذار می‌شود. از آنجا که اکثر مشتریان CA و PKI تمرکز بر قلمرو سازمانی دارند، تمایلی بر خریدِ محصولاتِ OpenPGP ندارند.
مشخصه‌های معاملات الکترونیکی امن SET، [SET۱; SET۲; SET۳] استانداردی برای پشتیبانی از پرداخت‌های کارت‌های اعتباری در سطح شبکه‌های توزیعی مانند اینترنت را تعریف می‌کنند. SET پروتکل استاندارد پرداخت را تعریف می‌کند. SET از ساختار نسخه ۳ از گواهی X.۵۰۹ پیروی می‌کند و ضمیمه‌های خصوصی به آن می افزاید که تنها در زمینه SET معنا دارند. شکل زیر یک گواهی SET را نشان می‌دهد. البته تمام ضمائم در ان آوده نشده‌اند. مثلاً ضمیمه Hashed Root Key که در یک گواهی SET root CA می‌آید را نشان نمی‌دهد
نسخه ۲۰۰۰ از X.۵۰۹ مفهوم و کاربرد گواهی‌های اختیاری را به تفصیل شرح داده و حتی چارچوبی برای اساسِ ایجادِ زیرساخت‌های مدیریت ویژه PMIs ارائه می‌دهد. موضوع PMI بسیار گسترده است و می‌تواند عنوان یک کتاب باشد. در اینجا تنها کافی است بدانید که اگرچه گواهی هایاختیاری در توصیه‌های X.۵۰۹ تعریف شده اند، ولی گواهی‌های اختیاری گواهی‌های کلید عمومی نیستند. گواهی‌های اختیاری برای حمل ویژگی‌های یک موضوع طراحی شده اند تا مدیریت ویژه انعطاف پذیر و مقیاس پذیر را سهولت بخشند. گواهی اختیاری ممکن است برای تصدیق هویت دارنده گواهی اختیاری به یک گواهی کلید عمومی اشاره داشته باشد.
علاوه بر ذخیره گواهی ها، ابزارهای Administrator خدمات صدور، ابطال و انتشار CRL (Certificate Revocation List) و وارد و صادر کردن  گواهی‌ها را ارائه می‌دهد. Administrator می‌تواند از این ابزارها برای مدیریت گواهی‌های خودشان و کاربران دیگر، یک کامپیوتر یا یک service دیگر استفاده کند.
وظایف مربوط به صدور گواهی:هنگامی که کاربر درخواست برای گواهی را در یک stand-alone CA ثبت می‌کند، درخواستِ او در وضعیتِ pending قرار می‌گیرد تا زمانی‌که CA Administrator آن درخواست را قبول یا رد کند. کاربر همچنین به صفحات وب که خدمات گواهی را ارائه می‌کنند، دسترسی داشته و از وضعیت گواهی‌های خود مطلع می‌شود.  این رویه تنها برای یک stand-alone CA به کار برده می‌شود. که در آن تنظیم شده هر درخواست جدید گواهی را در وضعیتِ pending قرار دهد.
برای حفظ تمامیتِ (integrity) PKI در یک سازمان ممکن است لازم شود که CA administrator گواهی‌ها را قبل از تاریخ انقضاءشان باطل کند. برای مثال، اگر شخصی که برای او گواهی صادر شده سازمان را ترک کند، باید گواهی او باطل گردد. یا اینکه کلید خصوصیِ یک گواهی کشف شود، یا یک حادثه امنیتی بر اعتبار یک گواهی تأثیر بگذارد. Administrator گواهی‌ها را در CA باطل می‌کند. پس از اینکه یک گواهی باطل شد، به پوشه گواهی‌های باطل شده منتقل می‌شود. و گواهی‌های باطل شده در نوبت بعدیِ انتشار CRL در لیست قرار می‌گیرد.
یک CA به‌طور خودکار CRL را در فواصل زمانی که administrator تعریف کرده، به روز رسانی و انتشار می‌کند. می‌توان بنا به درخواست نیز CRL را با استفاده از CRL publishing wizard انتشار کرد. Clientهایی (سرویس گیرنده ای) که یک کپی از CRL انتشار شده قبلی را در حافظه خود دارند، تا زمانی که نوبت بعدی به روز رسانی نرسیده آن را به کار می‌گیرند. اگرچه در این فاصله بنا به درخواست CRL جدیدی منتشر شده باشد.
وظایف مربوطه:
Snap-in گواهی ابزارهایی در اختیار administrator می گذارد تا بتوان گواهی‌ها را به همراه مسیرهای گواهی و کلیدهای خصوصی وارد یا خارج کند. می‌توان گواهی را از یک کاربر دیگر، کامپیوتر، یا CA دیگر وارد کرد. یا می‌توان گواهی را برای استفاده در کامپیوتر دیگر صادر نمود. گواهی‌ها را می‌توان با ساختار فایلهای استاندارد گوناگون دیگر وارد یا صادر کرد.
ممکن است لازم باشد سازمان صحت کاربران خارجی که در Active Directory حساب ندارند را، تصدیق کند. وظایفی که مربوط به تنظیماتِ Active Directory برای گواهی‌ها می‌باشد: