لنگرهای اعتماد (Trust Anchors)

به‌طور کلی، بر اساس RFC 4158 و RFC 5280، یک لنگر اعتماد هر کلید عمومی و نام متمایز موضوعی (DN) مربوط به آن است که به دلیلی مورد اعتماد دانسته می‌شود و در نتیجه به عنوان ریشه زنجیره‌ای از گواهی‌نامه‌ها قابل پذیرش است.

در عمل، لنگرهای اعتماد در قالب گواهی‌نامه‌ها ارائه می‌شوند که فیلدهای اساسی آن‌ها کلید عمومی و DN موضوع است. افزون بر الزامات RFC 5280، برنامه OpenSSL دوره اعتبار چنین گواهی‌نامه‌هایی را بررسی کرده و از برخی فیلدهای دیگر نیز استفاده می‌کند. به‌ویژه، افزونه شناسه کلید موضوع، در صورت وجود، برای تطبیق لنگرهای اعتماد هنگام ساخت زنجیره به کار می‌رود.

در ساده‌ترین و رایج‌ترین حالت، لنگرهای اعتماد به‌طور پیش‌فرض همگی گواهی‌نامه‌های خودامضاشده مرجع صدور گواهی (CA) «ریشه» هستند که در مخزن اعتماد قرار دارند؛ مخزن اعتماد مجموعه‌ای از گواهی‌نامه‌هاست که برای کاربردهای خاصی مورد اعتماد هستند. این مشابه سازوکاری است که در مخازن اعتماد موزیلا فایرفاکس، یا مخازن گواهی‌نامه اپل و مایکروسافت به کار می‌رود.

از دیدگاه OpenSSL، یک لنگر اعتماد گواهی‌نامه‌ای است که باید با مشخص کردن صریح این که برای کدام کاربردهای یک گواهی‌نامه هدف می‌تواند نقش لنگر اعتماد را داشته باشد، تکمیل شود. در کدگذاری PEM، این موضوع با رشته "TRUSTED CERTIFICATE" مشخص می‌شود. چنین مشخصه‌ای مجموعه‌ای از صفات اعتماد مثبت (بیان صریح اعتماد برای اهداف ذکرشده) و/یا مجموعه‌ای از صفات اعتماد منفی (رد صریح استفاده برای اهداف ذکرشده) را فراهم می‌آورد. این اهداف با استفاده از مقادیر تعریف‌شده برای کاربردهای کلید گسترش‌یافته (EKU) که ممکن است در افزونه‌های X.509 گواهی‌نامه‌های نهاد نهایی ارائه شوند، کدگذاری می‌شوند. همچنین بخش «کاربرد کلید گسترش‌یافته» را در ادامه ببینید.

کاربردهایی که در حال حاضر شناخته شده‌اند عبارتند از: clientAuth (کاربرد کلاینت SSL)، serverAuth (کاربرد سرور SSL)، emailProtection (کاربرد ایمیل S/MIME)، codeSigning (کاربرد امضاکننده شیء)، OCSPSigning (کاربرد پاسخ‌دهنده OCSP)، OCSP (کاربرد درخواست OCSP)، timeStamping (کاربرد سرور TSA) و anyExtendedKeyUsage. از نسخه OpenSSL 1.1.0، مورد آخر در صورت رد شدن، تمام کاربردها را مسدود کرده و در صورت مورد اعتماد بودن، تمام کاربردها را فعال می‌کند.

یک گواهی‌نامه، که ممکن است گواهی‌نامه CA یا گواهی‌نامه نهاد نهایی باشد، فقط و فقط در صورتی به عنوان یک لنگر اعتماد برای کاربرد داده‌شده در نظر گرفته می‌شود که تمامی شرایط زیر برقرار باشند:

• عضوی از مخزن اعتماد باشد.
• فاقد صفت اعتماد منفی برای رد کاربرد داده‌شده باشد.
• دارای صفت اعتماد مثبت برای پذیرش کاربرد داده‌شده باشد یا (به‌طور پیش‌فرض) یکی از شرایط سازگاری زیر صدق کند: خودامضاشده باشد یا گزینه -partial_chain داده شده باشد (که متناظر با تنظیم پرچم X509_V_FLAG_PARTIAL_CHAIN است).

ساخت مسیر گواهی‌نامه (Certification Path Building)

ابتدا، یک زنجیره گواهی‌نامه از گواهی‌نامه هدف آغاز شده و به یک لنگر اعتماد ختم می‌شود.

این زنجیره به‌صورت تکرارشونده و با جستجوی نوبتی برای گواهی‌نامه‌ای با کاربرد کلید مناسب که مطابق با توضیحات زیر با صادرکننده گواهی‌نامه «موضوع» فعلی مطابقت داشته باشد، ساخته می‌شود. اگر چنین گواهی‌نامه‌ای وجود داشته باشد، نخستین گواهی‌نامه معتبرِ یافت‌شده انتخاب می‌شود، در غیر این صورت گواهی‌نامه‌ای که در میان تمام این گواهی‌نامه‌ها اخیراً منقضی شده انتخاب خواهد شد. به منظور افزایش کارایی، هیچ بازگشت به عقبی انجام نمی‌شود، بنابراین هرگونه گواهی‌نامه صادرکننده نامزد دیگری که تطابق یکسانی داشته باشد نادیده گرفته می‌شود.

هنگامی که یک گواهی‌نامه خودامضاشده به زنجیره اضافه شود، ساخت زنجیره متوقف می‌گردد. در این حالت، این گواهی‌نامه باید کاملاً با یک لنگر اعتماد مطابقت داشته باشد، در غیر این صورت ساخت زنجیره با شکست مواجه می‌شود.

یک گواهی‌نامه صادرکننده نامزد در صورتی با یک گواهی‌نامه موضوع مطابقت دارد که تمامی شرایط زیر برقرار باشند:

• نام موضوع آن با نام صادرکننده گواهی‌نامه موضوع مطابقت داشته باشد.
• اگر گواهی‌نامه موضوع دارای افزونه شناسه کلید مرجع باشد، هر یک از زیرفیلدهای آن با شناسه کلید موضوع، شماره سریال و فیلد صادرکننده متناظر در گواهی‌نامه صادرکننده نامزد، تا جایی که فیلدهای مربوطه در هر دو گواهی‌نامه وجود داشته باشند، برابر باشد.
• الگوریتم امضای گواهی‌نامه که برای امضای گواهی‌نامه موضوع استفاده شده، پشتیبانی شود و با الگوریتم کلید عمومی گواهی‌نامه صادرکننده نامزد یکسان باشد.

فرآیند جستجو ابتدا گواهی‌نامه‌های صادرکننده را در مخزن اعتماد بررسی می‌کند. اگر تطابقی در آنجا پیدا نکند، در صورت ارائه‌شدن، به فهرست گواهی‌نامه‌های غیرقابل‌اعتماد (CAهای «واسط») مراجعه می‌نماید. اگر یک گواهی‌نامه صادرکننده در مخزن اعتماد پیدا شود، دیگر برای یافتن گواهی‌نامه‌های صادرکننده بعدی به فهرست گواهی‌نامه‌های غیرقابل‌اعتماد مراجعه نخواهد شد. از این رو، در صورتی که X509_V_FLAG_PARTIAL_CHAIN فعال نباشد، برای اعتبارسنجی موفق باید یا فقط گواهی‌نامه ریشه یا یک زنجیره پیوسته تا گواهی‌نامه ریشه در مخزن اعتماد ارائه شده باشد.

اعتبارسنجی مسیر گواهی‌نامه (Certification Path Validation)

هنگامی که فرآیند ساخت زنجیره گواهی‌نامه با موفقیت انجام شد، اجزای زنجیره و پیوندهای میان آن‌ها به طور کامل بررسی می‌شوند.

گام نخست، بررسی ساختار صحیح (well-formed بودن) هر گواهی‌نامه است. بخشی از این بررسی‌ها تنها در صورتی فعال می‌شوند که گزینه -x509_strict داده شده باشد.

گام دوم، بررسی افزونه‌های X.509v3 هر گواهی‌نامه از نظر همخوانی با هدف خاص مورد نظر (در صورت وجود) است. اگر گزینه -purpose مشخص نشده باشد، چنین بررسی‌هایی انجام نمی‌شوند، به جز در بررسی امضای CMS که به‌طور پیش‌فرض "smimesign" بررسی می‌شود، و برقراری اتصال SSL/(D)TLS که به‌طور پیش‌فرض "sslserver" یا "sslclient" بررسی می‌شوند. افزونه‌های X.509v3 گواهی‌نامه هدف یا «برگ» (leaf) باید با هدف مشخص‌شده سازگار باشند. سایر گواهی‌نامه‌های طول زنجیره به عنوان گواهی‌نامه‌های معتبر CA بررسی می‌شوند و ممکن است بررسی‌های غیر استاندارد دیگری نیز انجام گیرد. افزونه‌های دقیق مورد نیاز با جزئیات در بخش «افزونه‌های گواهی‌نامه» در زیر تشریح شده‌اند.

گام سوم، بررسی تنظیمات اعتماد روی آخرین گواهی‌نامه (که معمولاً یک گواهی‌نامه ریشه خودامضاشده CA است) است. این گواهی‌نامه باید برای کاربرد مربوطه مورد اعتماد باشد. به جهت سازگاری با نسخه‌های پیشین OpenSSL، یک گواهی‌نامه خودامضاشده بدون هیچ صفت اعتمادی، برای تمام کاربردها معتبر در نظر گرفته می‌شود.

گام چهارم و نهایی، بررسی اعتبار زنجیره گواهی‌نامه است. برای هر عضو از زنجیره، شامل گواهی‌نامه ریشه CA، دوره اعتبار طبق فیلدهای "notBefore" و "notAfter" در برابر زمان جاری سیستم ارزیابی می‌شود. گزینه -attime می‌تواند برای تعیین زمان مبنایی غیر از «اکنون» استفاده شود. امضای گواهی‌نامه نیز بررسی می‌شود (به استثنای امضای گواهی‌نامه ریشه CA که معمولاً خودامضاست و تنها در صورتی تأیید می‌شود که گزینه -check_ss_sig داده شده باشد). هنگام اعتبارسنجی امضای گواهی‌نامه، افزونه keyUsage (در صورت وجود) در گواهی‌نامه صادرکننده نامزد بررسی می‌شود تا برای امضای گواهی‌نامه‌های پروکسی مجوز digitalSignature یا برای امضای سایر گواهی‌نامه‌ها مجوز keyCertSign را مجاز دانسته باشد. اگر تمامی این عملیات با موفقیت انجام شوند، گواهی‌نامه معتبر تلقی می‌شود؛ در غیر این صورت، نامعتبر خواهد بود.

گزینه‌های گواهی‌نامه مورد اعتماد (Trusted Certificate Options)

گزینه‌های زیر نحوه ارائه گواهی‌نامه‌هایی را مشخص می‌کنند که می‌توانند به عنوان لنگرهای اعتماد برای کاربردهای معین استفاده شوند. همان‌طور که اشاره شد، مجموعه‌ای از چنین گواهی‌نامه‌هایی مخزن اعتماد نامیده می‌شود.

توجه داشته باشید که OpenSSL مجموعه پیش‌فرضی از لنگرهای اعتماد را فراهم نمی‌کند. بسیاری از توزیع‌های لینوکس یک پیش‌فرض سیستمی دارند و OpenSSL را طوری پیکربندی می‌کنند که به آن اشاره کند. موزیلا یک مخزن اعتماد شناخته‌شده را نگهداری می‌کند که در نشانی زیر در دسترس است: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs

گواهی‌نامه‌هایی که باید به مخزن اعتماد افزوده شوند را می‌توان با گزینه‌های زیر مشخص کرد:

-CAfile file

فایل مشخص‌شده را که شامل یک گواهی‌نامه مورد اعتماد در قالب DER، یا در صورت PEM بودن ورودی، احتمالاً چندین گواهی‌نامه است، بارگذاری می‌کند. گواهی‌نامه‌های کدگذاری‌شده با PEM ممکن است دارای صفات اعتماد تنظیم‌شده نیز باشند.

-no-CAfile

عدم بارگذاری فایل پیش‌فرض گواهی‌نامه‌های مورد اعتماد.

-CApath dir

استفاده از پوشه مشخص‌شده به عنوان مجموعه‌ای از گواهی‌نامه‌های مورد اعتماد (یعنی مخزن اعتماد). فایل‌ها باید با مقدار هش SubjectName مربوط به X.509 هر گواهی‌نامه نام‌گذاری شده باشند. این کار به کتابخانه اجازه می‌دهد IssuerName را استخراج کند، هش آن را محاسبه نماید و برای به‌دست‌آوردن گواهی‌نامه صادرکننده مستقیماً فایل مربوطه را جستجو کند. برای کسب اطلاعات درباره ساخت چنین دایرکتوری‌ای به openssl-rehash(1) مراجعه کنید.

-no-CApath

عدم استفاده از دایرکتوری پیش‌فرض گواهی‌نامه‌های مورد اعتماد.

-CAstore uri

استفاده از uri به عنوان مخزن گواهی‌نامه‌های CA. این شناسه URI می‌تواند به یک گواهی‌نامه منفرد و یا مجموعه‌ای از آن‌ها اشاره کند. در شناسه‌های URI با طرحواره "file:"، این گزینه بسته به این که URI به یک فایل یا یک پوشه اشاره دارد، مانند -CAfile یا -CApath رفتار می‌کند. برای اطلاعات بیشتر در خصوص طرحواره "file:" به ossl_store-file(7) مراجعه نمایید.

این گواهی‌نامه‌ها همچنین هنگام ساخت زنجیره گواهی‌نامه سرور (برای نمونه با openssl-s_server(1)) یا زنجیره گواهی‌نامه کلاینت (برای نمونه با openssl-s_time(1)) استفاده می‌شوند.

-no-CAstore

عدم استفاده از مخزن پیش‌فرض گواهی‌نامه‌های قابل اعتماد CA.

گزینه‌های اعتبارسنجی (Verification Options)

اعتبارسنجی گواهی‌نامه می‌تواند با پرچم‌های زیر تنظیم دقیق شود:

-verbose

چاپ اطلاعات بیشتر درباره عملیات در حال انجام.

-attime timestamp

انجام بررسی‌های اعتبارسنجی با استفاده از زمان مشخص‌شده توسط timestamp به جای زمان جاری سیستم. مقدار timestamp تعداد ثانیه‌های سپری‌شده از ۱ ژانویه ۱۹۷۰ (یعنی مبدأ زمانی یونیکس یا Unix Epoch) است.

-no_check_time

این گزینه بررسی دوره اعتبار گواهی‌نامه‌ها و CRLها را در برابر زمان جاری غیرفعال می‌کند. اگر از گزینه -attime برای تعیین زمان اعتبارسنجی استفاده شده باشد، بررسی متوقف نمی‌شود.

-x509_strict

راهکارهای دورزدن غیراستاندارد برای گواهی‌نامه‌های معیوب را غیرفعال می‌کند. بنابراین برای گواهی‌نامه‌هایی که با RFC 5280 سازگار نیستند، خطا ایجاد می‌شود.

هنگامی که این گزینه تنظیم شده باشد، در میان موارد دیگر، شرایط ساختاری صحیح بودن گواهی‌نامه بررسی می‌شوند:

-ignore_critical

معمولاً اگر یک افزونه بحرانیِ پردازش‌نشده وجود داشته باشد که توسط OpenSSL پشتیبانی نمی‌شود، گواهی‌نامه رد می‌گردد (طبق الزامات RFC 5280). اگر این گزینه تنظیم شده باشد، افزونه‌های بحرانی نادیده گرفته می‌شوند.

-issuer_checks

نادیده گرفته می‌شود.

-crl_check

اعتبار گواهی‌نامه نهاد نهایی را با تلاش برای یافتن یک CRL معتبر بررسی می‌کند. اگر CRL معتبری یافت نشود، خطایی رخ می‌دهد.

-crl_check_all

اعتبار تمامی گواهی‌نامه‌ها در زنجیره را با تلاش برای جستجوی CRLهای معتبر بررسی می‌کند.

-use_deltas

فعال‌سازی پشتیبانی از CRLهای دلتا.

-extended_crl

فعال‌سازی ویژگی‌های CRL گسترش‌یافته مانند CRLهای غیرمستقیم و کلیدهای امضای متناوب CRL.

-suiteB_128_only, -suiteB_128, -suiteB_192

فعال‌سازی عملکرد حالت Suite B به ترتیب در سطح امنیتی ۱۲۸ بیتی، ۱۲۸ بیتی یا ۱۹۲ بیتی، یا فقط سطح امنیتی ۱۹۲ بیتی. برای جزئیات به RFC 6460 مراجعه کنید. به‌طور خاص، الگوریتم‌های امضای پشتیبانی‌شده کاهش یافته و تنها از ECDSA و SHA256 یا SHA384 و فقط منحنی‌های بیضوی P-256 و P-384 پشتیبانی می‌شود.

-auth_level level

تنظیم سطح امنیتی احراز هویت زنجیره گواهی‌نامه روی level. سطح امنیتی احراز هویت، استحکام امضا و کلید عمومی قابل قبول را هنگام اعتبارسنجی زنجیره‌های گواهی‌نامه تعیین می‌کند. برای معتبر شناخته شدن یک زنجیره گواهی‌نامه، کلیدهای عمومی تمامی گواهی‌نامه‌ها باید با سطح امنیتی مشخص‌شده (level) مطابقت داشته باشند. سطح امنیتی الگوریتم امضا برای تمام گواهی‌نامه‌های زنجیره اعمال می‌شود، به جز لنگر اعتماد زنجیره که یا مستقیماً مورد اعتماد است یا از طریقی غیر از امضایش اعتبارسنجی شده است. تعاریف سطوح در دسترس را در SSL_CTX_set_security_level(3) ببینید. سطح امنیتی پیش‌فرض -1 یا «تنظیم‌نشده» است. در سطح امنیتی 0 یا پایین‌تر، تمام الگوریتم‌ها قابل قبول هستند. سطح امنیتی 1 نیازمند حداقل امنیت معادل ۸۰ بیت است و قابلیت تعامل‌پذیری گسترده‌ای دارد، هرچند برای نمونه، امضاهای MD5 یا کلیدهای RSA کوتاه‌تر از ۱۰۲۴ بیت را رد می‌کند.

-partial_chain

اجازه می‌دهد اعتبارسنجی حتی در صورت ساخته شدن یک زنجیره ناقص موفق شود؛ یعنی زنجیره‌ای که به گواهی‌نامه‌ای ختم می‌شود که در حالت عادی مورد اعتماد نیست (زیرا فاقد صفات اعتماد مثبت منطبق بوده و خودامضاشده نیست) اما عنصری از مخزن اعتماد است. این گواهی‌نامه ممکن است خودصادرشده باشد یا به یک CA واسط تعلق داشته باشد.

-check_ss_sig

تأیید امضای آخرین گواهی‌نامه در زنجیره در صورتی که آن گواهی‌نامه ظاهراً خودامضاشده باشد. اگر این گواهی‌نامه یک گواهی‌نامه CA ناسازگار باشد که محدودیت‌های کاربرد کلید آن شامل بیت keyCertSign نیست، این کار مجاز نبوده و منجر به بروز خطا می‌شود. این اعتبارسنجی به‌طور پیش‌فرض غیرفعال است زیرا هیچ امنیتی اضافه نمی‌کند.

-allow_proxy_certs

اجازه اعتبارسنجی گواهی‌نامه‌های پروکسی را می‌دهد.

-trusted_first

از نسخه OpenSSL 1.1.0 این گزینه به‌طور پیش‌فرض فعال است و نمی‌توان آن را غیرفعال کرد.

هنگام ساخت زنجیره گواهی‌نامه، گواهی‌نامه‌های مورد اعتمادی که از طریق -CAfile، -CApath، -CAstore یا -trusted مشخص شده‌اند همواره پیش از هر گواهی‌نامه‌ای که از طریق -untrusted مشخص شده است استفاده می‌شوند.

-no_alt_chains

از نسخه OpenSSL 1.1.0، با توجه به این که -trusted_first همیشه فعال است، این گزینه هیچ تأثیری ندارد.

-trusted file

فایل file را به عنوان مجموعه‌ای از یک یا چند گواهی‌نامه پردازش می‌کند. هر یک از آن‌ها در صورتی که دارای یک صفت اعتماد مثبت مناسب باشد، یا خودامضاشده باشد، یا گزینه -partial_chain مشخص شده باشد، به عنوان مورد اعتماد شناخته می‌شود. این گزینه تلویحاً گزینه‌های -no-CAfile، -no-CApath و -no-CAstore را فعال می‌کند و نمی‌تواند همزمان با گزینه‌های -CAfile، -CApath یا -CAstore استفاده شود، بنابراین تنها گواهی‌نامه‌های مشخص‌شده از طریق گزینه -trusted لنگرهای اعتماد خواهند بود. این گزینه می‌تواند چندین بار به کار رود.

-untrusted file

فایل file را به عنوان مجموعه‌ای از یک یا چند گواهی‌نامه پردازش می‌کند. تمام گواهی‌نامه‌ها (معمولاً متعلق به CAهای واسط) غیرقابل‌اعتماد در نظر گرفته می‌شوند و ممکن است برای ساخت زنجیره گواهی‌نامه از گواهی‌نامه هدف تا یک لنگر اعتماد استفاده شوند. این گزینه می‌تواند چندین بار به کار رود.

-policy arg

فعال‌سازی پردازش خط‌مشی و افزودن arg به user-initial-policy-set (به RFC 5280 مراجعه کنید). شناسه خط‌مشی arg می‌تواند نام یک شیء یا یک OID در قالب عددی باشد. این آرگومان می‌تواند بیش از یک بار ظاهر شود.

-explicit_policy

تنظیم متغیر خط‌مشی require-explicit-policy (به RFC 5280 مراجعه کنید).

-policy_check

پردازش خط‌مشی گواهی‌نامه را فعال می‌کند.

-policy_print

چاپ اطلاعات تشخیصی مربوط به پردازش خط‌مشی.

-inhibit_any

تنظیم متغیر خط‌مشی inhibit-any-policy (به RFC 5280 مراجعه کنید).

-inhibit_map

تنظیم متغیر خط‌مشی inhibit-policy-mapping (به RFC 5280 مراجعه کنید).

-purpose purpose

مشخصه‌ای سطح‌بالا از کاربرد در نظر گرفته شده برای گواهی‌نامه هدف. اهداف از پیش تعریف‌شده در حال حاضر عبارتند از: "sslclient"، "sslserver"، "nssslserver"، "smimesign"، "smimeencrypt"، "crlsign"، "ocsphelper"، "timestampsign"، "codesign" و "any". اگر اعتبارسنجی گواهی‌نامه طرف مقابل فعال باشد، به‌طور پیش‌فرض پیاده‌سازی TLS و در نتیجه دستورات openssl-s_client(1) و openssl-s_server(1) همخوانی با کاربرد سرور TLS ("sslserver") یا کلاینت TLS ("sslclient") را بررسی می‌کنند. به‌طور پیش‌فرض، اعتبارسنجی امضای CMS که می‌تواند از طریق openssl-cms(1) انجام شود، همخوانی با کاربرد امضای S/MIME ("smimesign") را بررسی می‌نماید.

اگرچه سند IETF RFC 5280 بیان می‌کند که id-kp-serverAuth و id-kp-clientAuth تنها برای کاربرد وب هستند، در عمل آن‌ها برای تمامی انواع کلاینت‌ها و سرورهای TLS به کار می‌روند و OpenSSL نیز چنین فرضی دارد.

-verify_depth num

محدود کردن زنجیره گواهی‌نامه به num گواهی‌نامه CA واسط. زنجیره‌ای با بیشترین عمق می‌تواند تا num+2 گواهی‌نامه داشته باشد، زیرا نه گواهی‌نامه نهاد نهایی و نه گواهی‌نامه لنگر اعتماد جزو محدودیت -verify_depth به شمار نمی‌آیند.

-verify_email email

بررسی این که آیا email با نشانی ایمیل موجود در Subject Alternative Name یا ایمیل موجود در Distinguished Name موضوع مطابقت دارد یا خیر.

-verify_hostname hostname

بررسی این که آیا hostname با نام DNS موجود در Subject Alternative Name یا Common Name در گواهی‌نامه موضوع مطابقت دارد یا خیر.

-verify_ip ip

بررسی این که آیا ip با نشانی IP موجود در Subject Alternative Name در گواهی‌نامه موضوع مطابقت دارد یا خیر.

-verify_name name

استفاده از مجموعه‌ای از پارامترهای اعتبارسنجی، که تحت عنوان روش اعتبارسنجی نیز شناخته می‌شود، که توسط name شناسایی می‌گردد. روش‌های از پیش تعریف‌شده در حال حاضر عبارتند از: "ssl_client"، "ssl_server"، "smime_sign" با نام مستعار "pkcs7"، "code_sign" و "default". این روش‌ها ترکیبات هدف و تنظیمات اعتماد به کار رفته در SSL/(D)TLS، CMS/PKCS7 (شامل S/MIME) و امضای کد را تقلید می‌کنند.

پارامترهای اعتبارسنجی شامل مدل اعتماد، پرچم‌های گوناگونی که می‌توانند تا حدی از طریق دیگر گزینه‌های خط فرمان نیز تنظیم شوند، و هدف اعتبارسنجی هستند که به نوبه خود الزامات کاربرد کلید گواهی‌نامه و کاربرد گسترش‌یافته کلید را تعیین می‌کند.

مدل اعتماد تعیین می‌کند کدام OIDهای کمکی برای اعتماد یا رد، در اعتبارسنجی زنجیره گواهی‌نامه مربوطه اعمال شوند. این موارد را می‌توان با استفاده از گزینه‌های -addtrust و -addreject در openssl-x509(1) مشخص کرد.

گزینه‌های اعتبارسنجی گسترش‌یافته (Extended Verification Options)

گاهی اوقات ممکن است بیش از یک زنجیره گواهی‌نامه به یک گواهی‌نامه نهاد نهایی ختم شود. این حالت معمولاً زمانی رخ می‌دهد که یک CA ریشه یا واسط، گواهی‌نامه‌ای را برای CA دیگری در یک سازمان دیگر امضا کند. دلیل دیگر این است که یک CA ممکن است واسط‌هایی داشته باشد که از دو قالب امضای مختلف استفاده می‌کنند، مانند خلاصه پیام SHA-1 و SHA-256.

گزینه‌های زیر می‌توانند برای ارائه داده‌هایی استفاده شوند که به دستور OpenSSL اجازه تولید یک زنجیره جایگزین را می‌دهد:

-xkey infile, -xcert infile, -xchain

مشخص کردن گواهی‌نامه، کلید خصوصی و زنجیره گواهی‌نامه اضافی. این موارد رفتاری مشابه گزینه‌های -cert، -key و -cert_chain دارند. هنگام مشخص شدن، فراخوان برگرداننده نخستین زنجیره معتبر توسط کلاینت مورد استفاده قرار خواهد گرفت.

-xchain_build

تعیین این که آیا برنامه باید زنجیره گواهی‌نامه‌ای را که قرار است برای گواهی‌نامه‌های اضافی از طریق گزینه‌های -xkey، -xcert و -xchain به سرور ارائه شود بسازد یا خیر.

-xcertform DER|PEM|P12

قالب ورودی برای گواهی‌نامه اضافی. این گزینه هیچ اثری ندارد و صرفاً برای سازگاری با نسخه‌های قبلی حفظ شده است.

-xkeyform DER|PEM|P12

قالب ورودی برای کلید اضافی. این گزینه هیچ اثری ندارد و صرفاً برای سازگاری با نسخه‌های قبلی حفظ شده است.

افزونه‌های گواهی‌نامه (Certificate Extensions)

گزینه‌هایی مانند -purpose و -verify_name پردازش افزونه‌های خاص گواهی‌نامه را فعال می‌کنند که مشخص می‌سازد گواهی‌نامه‌ها برای چه مواردی قابل استفاده هستند.

محدودیت‌های پایه (Basic Constraints)

پرچم CA در افزونه basicConstraints برای تعیین این که آیا گواهی‌نامه می‌تواند به عنوان یک CA استفاده شود یا خیر به کار می‌رود. اگر پرچم CA روی true باشد آنگاه یک CA است، اگر پرچم CA روی false باشد آنگاه یک CA نیست. پرچم CA در تمامی CAها باید روی true تنظیم شده باشد.

اگر افزونه basicConstraints وجود نداشته باشد، که شامل حالتی است که گواهی‌نامه از نوع X.509v1 باشد، آنگاه گواهی‌نامه به عنوان یک «CA احتمالی» در نظر گرفته می‌شود و سایر افزونه‌ها با توجه به کاربرد مورد نظر برای گواهی‌نامه بررسی می‌شوند. رفتار با گواهی‌نامه‌های فاقد basicConstraints به عنوان CA در حال حاضر پشتیبانی می‌شود، اما ممکن است در آینده تغییر کند.

کاربرد کلید (Key Usage)

اگر افزونه keyUsage وجود داشته باشد، محدودیت‌های بیشتری بر کاربردهای گواهی‌نامه اعمال می‌شود. در صورت وجود افزونه keyUsage، یک گواهی‌نامه CA باید بیت keyCertSign را فعال داشته باشد.

کاربرد کلید گسترش‌یافته (Extended Key Usage)

افزونه extKeyUsage (کوتاه‌شده EKU) محدودیت‌های بیشتری را بر کاربرد گواهی‌نامه اعمال می‌کند. اگر این افزونه (چه بحرانی باشد چه نباشد) در یک گواهی‌نامه نهاد نهایی وجود داشته باشد، کلید تنها برای کاربردهای مشخص‌شده مجاز است، در حالی که EKU ویژه anyExtendedKeyUsage اجازه تمامی کاربردها را می‌دهد.

توجه داشته باشید که طبق بخش 4.2.1.12 از RFC 5280، افزونه Extended Key Usage تنها در گواهی‌نامه‌های نهاد نهایی ظاهر می‌شود و در نتیجه اعتبارسنجی استاندارد مسیر صدور گواهی‌نامه که در بخش 6 آن شرح داده شده، شامل بررسی‌های EKU برای گواهی‌نامه‌های CA نمی‌شود. مجمع CA/Browser برای کاربرد سرور TLS، کاربرد S/MIME و امضای کد، وجود EKUهای مربوطه را در گواهی‌نامه‌های CA زیرمجموعه الزامی می‌داند (در حالی که آن‌ها را برای گواهی‌نامه‌های CA ریشه مستثنی می‌کند) و مفهوم اعتبار گواهی‌نامه و اعتبارسنجی مسیر گواهی‌نامه را از RFC 5280 برگرفته است.

به دلایل تاریخی، OpenSSL روش ویژه خود را برای تفسیر و بررسی افزونه‌های EKU در گواهی‌نامه‌های CA دارد که ممکن است در آینده تغییر کند. این کتابخانه وجود افزونه‌های EKU در گواهی‌نامه‌های CA را الزامی نمی‌داند، اما در صورتی که هدف اعتبارسنجی "sslclient"، "nssslserver"، "sslserver"، "smimesign" یا "smimeencrypt" باشد، بررسی می‌کند که هر افزونه EKU موجود (که شامل anyExtendedKeyUsage نباشد) حاوی EKU مربوطه باشد، همان‌طور که در زیر به تفصیل آمده است. علاوه بر این، این بررسی‌ها را حتی برای گواهی‌نامه‌های لنگر اعتماد نیز انجام می‌دهد.

بررسی‌های ناشی از خط‌مشی‌های خاص از پیش تعریف‌شده (Checks Implied by Specific Predefined Policies)

شرح مشخصی از هر بررسی در زیر ارائه شده است. نکات مربوط به basicConstraints و keyUsage و گواهی‌نامه‌های X.509v1 در بالا، برای تمامی گواهی‌نامه‌های CA صدق می‌کند.

(D)TLS Client ("sslclient")

هر افزونه کاربرد کلید گسترش‌یافته‌ای باید اجازه "clientAuth" («احراز هویت کلاینت TLS WWW») را بدهد.

برای گواهی‌نامه‌های هدف، کاربرد کلید باید اجازه "digitalSignature" و/یا "keyAgreement" را بدهد. نوع گواهی‌نامه نت‌اسکیپ باید وجود نداشته باشد یا بیت کلاینت SSL در آن فعال باشد.

برای تمامی گواهی‌نامه‌های دیگر، بررسی‌های معمول CA اعمال می‌شود. علاوه بر این، نوع گواهی‌نامه نت‌اسکیپ باید وجود نداشته باشد یا بیت CA برای SSL در آن فعال باشد. این موضوع به عنوان یک راهکار در صورت عدم وجود افزونه basicConstraints به کار می‌رود.

(D)TLS Server ("sslserver")

هر افزونه کاربرد کلید گسترش‌یافته‌ای باید اجازه "serverAuth" («احراز هویت سرور TLS WWW») را بدهد و/یا یکی از OIDهای SGC را شامل شود.

برای گواهی‌نامه‌های هدف، کاربرد کلید باید اجازه "digitalSignature"، "keyEncipherment" و/یا "keyAgreement" را بدهد. نوع گواهی‌نامه نت‌اسکیپ باید وجود نداشته باشد یا بیت سرور SSL در آن فعال باشد.

برای تمامی گواهی‌نامه‌های دیگر، بررسی‌های معمول CA اعمال می‌شود. علاوه بر این، نوع گواهی‌نامه نت‌اسکیپ باید وجود نداشته باشد یا بیت CA برای SSL در آن فعال باشد. این موضوع به عنوان یک راهکار در صورت عدم وجود افزونه basicConstraints به کار می‌رود.

Netscape SSL Server ("nssslserver")

علاوه بر مواردی که برای sslserver شرح داده شد، برای این که یک کلاینت Netscape SSL به یک سرور SSL متصل شود، در صورت وجود افزونه keyUsage، گواهی‌نامه EE آن باید بیت keyEncipherment را فعال داشته باشد. این موضوع همیشه معتبر نیست زیرا برخی از مجموعه‌های رمزنگاری از کلید برای امضای دیجیتال استفاده می‌کنند. در غیر این صورت، همانند یک سرور SSL معمولی است.

Common S/MIME Checks

هر افزونه کاربرد کلید گسترش‌یافته‌ای باید اجازه "emailProtection" را بدهد.

برای گواهی‌نامه‌های هدف، نوع گواهی‌نامه نت‌اسکیپ باید وجود نداشته باشد یا باید بیت S/MIME در آن فعال باشد. اگر بیت S/MIME در نوع گواهی‌نامه نت‌اسکیپ فعال نباشد، بیت کلاینت SSL به عنوان جایگزین پذیرفته می‌شود اما یک هشدار نمایش داده خواهد شد. این امر بدان دلیل است که برخی از گواهی‌نامه‌های Verisign بیت S/MIME را تنظیم نمی‌کنند.

برای تمامی گواهی‌نامه‌های دیگر، بررسی‌های معمول CA اعمال می‌شود. علاوه بر این، نوع گواهی‌نامه نت‌اسکیپ باید وجود نداشته باشد یا بیت CA برای S/MIME در آن فعال باشد. این موضوع به عنوان یک راهکار در صورت عدم وجود افزونه basicConstraints به کار می‌رود.

S/MIME Signing ("smimesign")

علاوه بر بررسی‌های مشترک S/MIME، برای گواهی‌نامه‌های هدف کاربرد کلید باید اجازه "digitalSignature" و/یا nonRepudiation (یا نام مستعار آن contentCommitment) را بدهد.

S/MIME Encryption ("smimeencrypt")

علاوه بر بررسی‌های مشترک S/MIME، برای گواهی‌نامه‌های هدف کاربرد کلید باید اجازه "keyEncipherment" را بدهد.

CRL Signing ("crlsign")

برای گواهی‌نامه‌های هدف، کاربرد کلید باید اجازه "cRLSign" را بدهد.

برای تمامی گواهی‌نامه‌های دیگر، بررسی‌های معمول CA اعمال می‌شود؛ به جز این که در این مورد خاص، افزونه basicConstraints باید حتماً وجود داشته باشد.

OCSP Helper ("ocsphelper")

برای گواهی‌نامه‌های هدف، در این مرحله هیچ بررسی خاصی انجام نمی‌شود، اما بررسی‌های ویژه‌ای اعمال می‌گردد؛ به OCSP_basic_verify(3) مراجعه کنید.

برای تمامی گواهی‌نامه‌های دیگر، بررسی‌های معمول CA اعمال می‌شود.

Timestamp Signing ("timestampsign")

برای گواهی‌نامه‌های هدف، در صورت وجود افزونه کاربرد کلید، باید شامل "digitalSignature" و/یا "nonRepudiation" (یا نام مستعار آن "contentCommitment") بوده و نباید شامل بیت‌های دیگر باشد. افزونه EKU باید وجود داشته باشد و تنها حاوی "timeStamping" باشد. علاوه بر این، باید به عنوان بحرانی علامت‌گذاری شده باشد.

برای تمامی گواهی‌نامه‌های دیگر، بررسی‌های معمول CA اعمال می‌شود.

Code Signing ("codesign")

برای گواهی‌نامه‌های هدف، افزونه کاربرد کلید باید وجود داشته باشد و به عنوان بحرانی علامت‌گذاری شده باشد و شامل "digitalSignature" باشد، اما نباید شامل "keyCertSign" یا "cRLSign" باشد. افزونه EKU باید وجود داشته باشد و حاوی "codeSign" باشد، اما نباید شامل "anyExtendedKeyUsage" یا "serverAuth" باشد.

برای تمامی گواهی‌نامه‌های دیگر، بررسی‌های معمول CA اعمال می‌شود.