OPENSSL-CMP(1SSL) OpenSSL OPENSSL-CMP(1SSL)

openssl-cmp - کلاینت پروتکل مدیریت گواهی (CMP)

openssl cmp [-help] [-config filename] [-section names] [-verbosity level]

گزینه‌های عمومی پیام:

[-cmd ir|cr|kur|p10cr|rr|genm] [-infotype name] [-profile name] [-geninfo values] [-template filename] [-keyspec filename]

گزینه‌های ثبت‌نام گواهی:

[-newkey filename|uri] [-newkeypass arg] [-centralkeygen [-newkeyout filename] [-subject name] [-days number] [-reqexts name] [-sans spec] [-san_nodefault] [-policies name] [-policy_oids names] [-policy_oids_critical] [-popo number] [-csr filename] [-out_trusted filenames|uris] [-implicit_confirm] [-disable_confirm] [-certout filename] [-chainout filename]

گزینه‌های ثبت‌نام و ابطال گواهی:

[-oldcert filename|uri] [-issuer name] [-serial number] [-revreason number]

گزینه‌های انتقال پیام:

[-server [http[s]://][userinfo@]host[:port][/path][?query][#fragment]] [-proxy [http[s]://][userinfo@]host[:port][/path][?query][#fragment]] [-no_proxy addresses] [-recipient name] [-path remote_path] [-keep_alive value] [-msg_timeout seconds] [-total_timeout seconds]

گزینه‌های احراز هویت سرور:

[-trusted filenames|uris] [-untrusted filenames|uris] [-srvcert filename|uri] [-expect_sender name] [-ignore_keyusage] [-unprotected_errors] [-no_cache_extracerts] [-srvcertout filename] [-extracertsout filename] [-cacertsout filename] [-oldwithold filename] [-newwithnew filename] [-newwithold filename] [-oldwithnew filename] [-crlcert filename] [-oldcrl filename] [-crlout filename]

گزینه‌های احراز هویت و حفاظت کلاینت:

[-ref value] [-secret arg] [-cert filename|uri] [-own_trusted filenames|uris] [-key filename|uri] [-keypass arg] [-digest name] [-mac name] [-extracerts filenames|uris] [-unprotected_requests]

گزینه‌های قالب اطلاعات هویتی:

[-certform PEM|DER] [-crlform PEM|DER] [-keyform PEM|DER|P12|ENGINE] [-otherpass arg] [-engine id] [-provider name] [-provider-path path] [-provparam [name:]key=value] [-propquery propq]

گزینه‌های وضعیت تصادفی:

[-rand files] [-writerand file]

گزینه‌های اتصال TLS:

[-tls_used] [-tls_cert filename|uri] [-tls_key filename|uri] [-tls_keypass arg] [-tls_extra filenames|uris] [-tls_trusted filenames|uris] [-tls_host name]

گزینه‌های اشکال‌زدایی سمت کلاینت:

[-batch] [-repeat number] [-reqin filenames] [-reqin_new_tid] [-reqout filenames] [-reqout_only filename] [-rspin filenames] [-rspout filenames] [-use_mock_srv]

گزینه‌های سرور ماک (آزمایشی):

[-port number] [-max_msgs number] [-srv_ref value] [-srv_secret arg] [-srv_cert filename|uri] [-srv_key filename|uri] [-srv_keypass arg] [-srv_trusted filenames|uris] [-srv_untrusted filenames|uris] [-ref_cert filename|uri] [-rsp_cert filename|uri] [-rsp_key filename|uri] [-rsp_keypass filename|uri] [-rsp_crl filename|uri] [-rsp_extracerts filenames|uris] [-rsp_capubs filenames|uris] [-rsp_newwithnew filename|uri] [-rsp_newwithold filename|uri] [-rsp_oldwithnew filename|uri] [-poll_count number] [-check_after number] [-grant_implicitconf] [-pkistatus number] [-failure number] [-failurebits number] [-statusstring arg] [-send_error] [-send_unprotected] [-send_unprot_err] [-accept_unprotected] [-accept_unprot_err] [-accept_raverified]

گزینه‌های اعتبارسنجی گواهی، هم برای CMP و هم برای TLS:

[-allow_proxy_certs] [-attime timestamp] [-no_check_time] [-check_ss_sig] [-crl_check] [-crl_check_all] [-explicit_policy] [-extended_crl] [-ignore_critical] [-inhibit_any] [-inhibit_map] [-partial_chain] [-policy arg] [-policy_check] [-policy_print] [-purpose purpose] [-suiteB_128] [-suiteB_128_only] [-suiteB_192] [-trusted_first] [-no_alt_chains] [-use_deltas] [-auth_level num] [-verify_depth num] [-verify_email email] [-verify_hostname hostname] [-verify_ip ip] [-verify_name name] [-x509_strict] [-issuer_checks]

دستور cmp یک پیاده‌سازی کلاینت برای پروتکل مدیریت گواهی (CMP) طبق تعاریف RFC 9810 و انتقال HTTP(S) آن طبق تعریف RFC 9811 است. از این دستور می‌توان برای درخواست گواهی از یک سرور CA، به‌روزرسانی گواهی‌ها، درخواست ابطال گواهی‌ها و اجرای سایر انواع درخواست‌های CMP استفاده کرد.

نمایش خلاصه‌ای از تمامی گزینه‌ها.
فایل پیکربندی مورد استفاده. رشته خالی "" به معنای هیچ است. نام فایل پیش‌فرض از متغیر محیطی "OPENSSL_CONF" گرفته می‌شود.
بخش یا بخش‌هایی از فایل پیکربندی که گزینه‌های CMP را تعریف می‌کنند. رشته خالی "" به معنای عدم انتخاب بخش خاصی است. پیش‌فرض "cmp" است.

می‌توان نام چند بخش را با کاما و/یا فاصله از یکدیگر جدا کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). محتوای بخش‌هایی که دیرتر ذکر شوند ممکن است محتوای بخش‌های پیشین را بازنویسی کند. در هر حال، طبق معمول بخش "[default]" و در نهایت بخش بدون نام (در صورت وجود) می‌توانند مقادیر جایگزین (fallback) را برای هر گزینه فراهم سازند.

سطح جزئیات (verbosity) برای لاگ‌گیری، خروجی خطا و غیره. 0 = EMERG، 1 = ALERT، 2 = CRIT، 3 = ERR، 4 = WARN، 5 = NOTE، 6 = INFO، 7 = DEBUG، 8 = TRACE. پیش‌فرض 6 = INFO است.

دستور CMP برای اجرا. دستوراتی که در حال حاضر پیاده‌سازی شده‌اند عبارتند از:

ir با صدور نخستین گواهی، درخواست مقداردهی اولیه یک موجودیت نهایی (end entity) را در ساختار سلسله‌مراتبی PKI ثبت می‌کند.

cr درخواست صدور یک گواهی اضافی برای یک موجودیت نهایی که از قبل در سلسله‌مراتب PKI مقداردهی اولیه شده است را ثبت می‌کند.

p10cr مشابه با cr درخواست صدور یک گواهی اضافی را ارسال می‌کند اما از قالب قدیمی PKCS#10 CSR استفاده می‌نماید.

kur درخواست یک به‌روزرسانی (کلید) را برای یک گواهی موجود ثبت می‌کند.

rr درخواست ابطال یک گواهی موجود را ثبت می‌کند.

genm با استفاده از یک پیام عمومی درخواست اطلاعات می‌کند، که در آن می‌توان از InfoTypeAndValueهای اختیاری برای تعیین اطلاعات مورد نظر استفاده کرد. پس از دریافت پاسخ عمومی (General Response)، اطلاعات مربوط به تمامی infoTypeهای ITAV دریافت‌شده در خروجی استاندارد چاپ می‌شود.

تنظیم نام InfoType برای درخواست اطلاعات خاص در genm، برای نمونه "signKeyPairTypes". پشتیبانی خاصی برای "caCerts"، "rootCaCert"، "certReqTemplate" و "crlStatusList" (بازیابی به‌روزرسانی CRL) وجود دارد.
نام یک نمایه گواهی (certificate profile) برای قرارگیری در فیلد generalInfo هدر PKIHeader پیام‌های درخواست.
فهرستی جداشده با کاما از InfoTypeAndValue برای قرارگیری در فیلد generalInfo هدر PKIHeader پیام‌های درخواست. هر InfoTypeAndValue یک OID و یک مقدار صحیح یا رشته‌ای به فرمت OID:int:number یا OID:str:text تعیین می‌کند، مانند '1.2.3.4:int:56789, id-kp:str:name'.
فایلی برای ذخیره هرگونه certTemplate از نوع CRMF در قالب DER که در یک پیام genp همراه با id-it-certReqTemplate دریافت شده باشد.
اختیاری است و برای تعیین فایلی جهت ذخیره هرگونه keySpec موجود در یک پیام genp با id-it-keyGenParameters استفاده می‌شود.

نکته: هرگونه محتوای فیلد keySpec دریافت‌شده به عنوان INFO لاگ می‌شود.

منبع کلید خصوصی یا عمومی برای گواهی در حال درخواست. پیش‌فرض آن کلید عمومی موجود در PKCS#10 CSR ارائه‌شده با گزینه -csr، کلید عمومی گواهی مرجع، یا کلید فعلی کلاینت است.

بخش عمومی کلید در درخواست صدور گواهی قرار می‌گیرد.

مگر در حالتی که -cmd p10cr، -popo -1 یا -popo 0 داده شده باشد، کلید خصوصی نیز برای ارائه اثبات مالکیت (POPO) لازم خواهد بود، که در این صورت گزینه -key می‌تواند یک جایگزین (fallback) فراهم کند.

منبع عبارت عبور برای کلید مشخص‌شده با گزینه -newkey. اگر در اینجا مشخص نشود، در صورت نیاز رمز عبور درخواست خواهد شد.

برای اطلاعات بیشتر درباره قالب arg به openssl-passphrase-options(1) مراجعه کنید.

درخواست تولید متمرکز کلید برای ثبت‌نام گواهی. این گزینه برای -cmd ir|cr|kur|p10cr کاربرد دارد.
فایل ذخیره‌سازی کلید خصوصی تولیدشده به صورت متمرکز، در قالب PEM.
نام متمایز (DN) مربوط به X.509 جهت استفاده به عنوان فیلد موضوع (subject) در الگوی گواهی درخواستی در پیام‌های IR/CR/KUR. اگر مقدار NULL-DN ("/") داده شود، هیچ موضوعی در الگو قرار نمی‌گیرد. پیش‌فرض، DN موضوع هرگونه PKCS#10 CSR داده‌شده با گزینه -csr است. برای KUR، یک جایگزین بعدی DN موضوع گواهی مرجع است (به -oldcert مراجعه کنید) در صورتی که ارائه شده باشد. این جایگزین برای IR و CR تنها زمانی استفاده می‌شود که هیچ SAN تنظیم نشده باشد.

در صورت ارائه و عدم تعیین هیچ‌یک از گزینه‌های -cert، -oldcert یا -csr، DN موضوع به عنوان فرستنده جایگزین پیام‌های خروجی CMP استفاده می‌شود.

آرگومان باید به صورت /type0=value0/type1=value1/type2=... قالب‌بندی شود. کاراکترهای ویژه را می‌توان با "\" (بک‌اسلش) اسکیپ کرد؛ فاصله‌های خالی حفظ می‌شوند. مقادیر خالی مجاز هستند، اما نوع متناظر درج نخواهد شد. ارائه یک "/" تنها منجر به توالی خالی از RDNها (یک NULL-DN) می‌شود. RDNهای چندمقداری را می‌توان با قرار دادن کاراکتر "+" به جای "/" بین AttributeValueAssertionها (AVAها) که اعضای مجموعه را مشخص می‌کنند، تشکیل داد. مثال:

"/DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe"

تعداد روزهایی که گواهی جدید درخواست می‌شود معتبر باشد، شمارش‌شده از زمان فعلی میزبان. همچنین این گزینه درخواست صریح مبنی بر شروع دوره اعتبار از زمان فعلی (از دید میزبان) را فعال می‌کند.
نام بخش در فایل پیکربندی OpenSSL که افزونه‌های درخواست گواهی را تعریف می‌کند. اگر گزینه -csr وجود داشته باشد، این افزونه‌ها افزونه‌های موجود در PKCS#10 CSR ارائه‌شده را تکمیل کرده و هرگونه افزونه با OID یکسان را بازنویسی می‌کنند.
یک یا چند آدرس IP، آدرس ایمیل، نام DNS یا URI جداشده با کاما یا فاصله (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد) برای افزودن به عنوان افزونه نام جایگزین موضوع (SAN) در درخواست گواهی. اگر عنصر ویژه "critical" داده شود، SANها بحرانی علامت‌گذاری می‌شوند. در صورت تنظیم هرگونه افزونه نام جایگزین موضوع از طریق -reqexts نمی‌توان از این گزینه استفاده کرد.
هنگامی که نام‌های جایگزین موضوع نه از طریق -sans ارائه شده باشند و نه از طریق -reqexts تعریف شده باشند، به طور پیش‌فرض از گواهی مرجع کپی می‌شوند (به -oldcert مراجعه کنید). این رفتار را می‌توان با ارائه گزینه -san_nodefault غیرفعال کرد.
نام بخش در فایل پیکربندی OpenSSL که سیاست‌های لازم برای تنظیم به عنوان افزونه درخواست گواهی را تعریف می‌کند. این گزینه نمی‌تواند همزمان با -policy_oids استفاده شود.
یک یا چند OID، جداشده با کاما و/یا فاصله (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد) برای افزودن به عنوان افزونه سیاست‌های گواهی در درخواست. این گزینه نمی‌تواند همراه با -policies استفاده شود.
علامت‌گذاری سیاست‌های ارائه‌شده با -policy_oids به عنوان بحرانی (critical).
روش اثبات مالکیت (POPO) مورد استفاده برای IR/CR/KUR؛ مقادیر: -1..2 که در آن -1 = NONE (که متضمن تولید متمرکز کلید است)، 0 = RAVERIFIED، 1 = SIGNATURE (پیش‌فرض)، 2 = KEYENC.

توجه داشته باشید که POPO مبتنی بر امضا تنها در صورتی می‌تواند تولید شود که یک کلید خصوصی از طریق گزینه‌های -newkey یا -key فراهم شده باشد.

یک PKCS#10 CSR در قالب PEM یا DER شامل یک درخواست گواهی. همراه با -cmd p10cr مستقیماً در یک پیام قدیمی P10CR استفاده می‌شود.

هنگامی که با -cmd ir، cr یا kur استفاده شود، به درخواست استاندارد CMP مربوطه تبدیل می‌گردد. در این حالت، باید یک کلید خصوصی (با -newkey یا -key) برای اثبات مالکیت فراهم شود (مگر اینکه -popo -1 یا -popo 0 استفاده شود) و کلید عمومی مربوطه در درخواست صدور گواهی قرار می‌گیرد (به جای برداشتن کلید عمومی موجود در PKCS#10 CSR).

ورودی PKCS#10 CSR همچنین می‌تواند با -cmd rr جهت تعیین گواهی مورد نظر برای ابطال از طریق نام موضوع و کلید عمومی موجود در آن استفاده شود. در صورتی که -cert و -oldcert داده نشده باشند، موضوع آن به عنوان فرستنده جایگزین در هدر پیام‌های CMP استفاده می‌شود.

گواهی(های) معتمد مورد استفاده برای اعتبارسنجی گواهی تازه ثبت‌نام‌شده. در طول این اعتبارسنجی، هرگونه بررسی وضعیت گواهی غیرفعال است.

می‌توان چندین منبع را جداشده با کاما و/یا فاصله مشخص کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). هر منبع ممکن است حاوی چندین گواهی باشد.

گزینه‌های اعتبارسنجی گواهی -verify_hostname، -verify_ip و -verify_email تنها بر اعتبارسنجی گواهی فعال‌شده از طریق این گزینه تأثیر می‌گذارند.

درخواست تایید ضمنی (implicit confirmation) برای گواهی‌های تازه ثبت‌نام‌شده.
عدم ارسال پیام تایید گواهی برای گواهی تازه ثبت‌نام‌شده بدون درخواست تایید ضمنی، جهت کنار آمدن با سرورهای معیوبی که به درستی از تایید ضمنی پشتیبانی نمی‌کنند. هشدار: این کار منجر به رفتاری مغایر با RFC 9810 می‌شود.
فایلی که هرگونه گواهی تازه ثبت‌نام‌شده باید در آن ذخیره شود.
فایلی که زنجیره هرگونه گواهی تازه ثبت‌نام‌شده باید در آن ذخیره شود. این زنجیره شامل گواهی برگ (leaf)، یعنی خود گواهی تازه ثبت‌نام‌شده نمی‌شود. همچنین لنگر اعتماد (گواهی ریشه) نیز گنجانده نمی‌شود.

اگر گزینه -certout نیز با آرگومان filename یکسان داده شود، فایل تولیدشده شامل هر دو خروجی به صورت متصل به هم خواهد بود: گواهی تازه ثبت‌نام‌شده و به دنبال آن زنجیره آن.

گواهی مورد نظر برای به‌روزرسانی (یعنی تمدید یا تجدید کلید) در پیام‌های درخواست به‌روزرسانی کلید (KUR) یا برای ابطال در پیام‌های درخواست ابطال (RR). برای KUR گواهی مورد به‌روزرسانی به صورت پیش‌فرض -cert است، و گواهی حاصل گواهی مرجع (reference certificate) نامیده می‌شود. برای RR گواهی مورد ابطال را می‌توان با استفاده از -csr نیز مشخص کرد. اگر -issuer و -serial ارائه شوند، -oldcert و -csr نادیده گرفته می‌شوند.

گواهی مرجع (در صورت وجود) همچنین برای استخراج DN موضوع پیش‌فرض و نام‌های جایگزین موضوع و ورودی صادرکننده پیش‌فرض در الگوی گواهی درخواستی یک IR/CR/KUR استفاده می‌شود. کلید عمومی آن به عنوان جایگزین در الگوی درخواست‌های صدور گواهی به کار می‌رود. موضوع آن در صورتی که -cert داده نشده باشد به عنوان فرستنده پیام‌های خروجی استفاده می‌شود. صادرکننده آن به عنوان گیرنده پیش‌فرض در هدر پیام‌های CMP استفاده می‌شود در صورتی که هیچ‌یک از -recipient، -srvcert یا -issuer داده نشده باشند.

نام متمایز (DN) مربوط به X.509 جهت قرارگیری به عنوان فیلد صادرکننده (issuer) در الگوی گواهی درخواستی در پیام‌های IR/CR/KUR/RR. اگر مقدار NULL-DN ("/") داده شود، هیچ صادرکننده‌ای در الگو قرار نمی‌گیرد.

در صورت ارائه و عدم تعیین هیچ‌یک از -recipient یا -srvcert، DN صادرکننده به عنوان گیرنده جایگزین پیام‌های خروجی CMP استفاده می‌شود.

آرگومان باید به صورت /type0=value0/type1=value1/type2=... قالب‌بندی شود. برای جزئیات به توضیحات گزینه -subject مراجعه کنید.

تعیین شماره سریال گواهی مورد نظر برای ابطال در درخواست ابطال. شماره سریال می‌تواند ده‌دهی یا هگزادسیمال (در صورت پیشوند "0x") باشد.
تنظیم CRLReason جهت درج در درخواست ابطال (RR)؛ مقادیر: 0..10 یا -1 برای هیچ‌کدام (که پیش‌فرض است).

شماره‌های دلیل تعریف‌شده در RFC 5280 عبارتند از:

CRLReason ::= ENUMERATED {
     unspecified             (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6),
     -- value 7 is not used
     removeFromCRL           (8),
     privilegeWithdrawn      (9),
     aACompromise           (10)
 }

نام دامنه یا آدرس IP host و به صورت اختیاری port مربوط به سرور CMP برای اتصال با استفاده از HTTP(S). آدرس IP می‌تواند v4 یا v6 باشد، مانند 127.0.0.1 یا "[::1]" برای localhost. اگر رشته میزبان یک آدرس IPv6 باشد، باید در "[" و "]" محصور شود.

این گزینه مانع استفاده از -port و -use_mock_srv می‌شود. اگر -rspin با تعداد کافی آرگومان نام فایل داده شود، نادیده گرفته می‌شود.

اگر طرح‌واره (scheme) "https" داده شود، گزینه -tls_used ضمنی است. هنگامی که TLS استفاده می‌شود، پورت پیش‌فرض 443 و در غیر این صورت 80 است. بخش‌های اختیاری userinfo و fragment نادیده گرفته می‌شوند. هر بخش query ارائه‌شده به عنوان بخشی از مؤلفه مسیر بررسی می‌شود. اگر مسیری درج شود، مقدار پیش‌فرض را برای گزینه -path فراهم می‌کند.

سرور پراکسی HTTP(S) برای رسیدن به سرور CMP، مگر اینکه -no_proxy اعمال شود؛ به بخش زیر مراجعه کنید. اگر رشته میزبان یک آدرس IPv6 باشد، باید در "[" و "]" قرار گیرد. پورت پراکسی در صورت وجود طرح‌واره "https" به طور پیش‌فرض 443 و در غیر این صورت 80 است؛ صرف‌نظر از آن، پیشوند اختیاری "http://" یا "https://" نادیده گرفته می‌شود (توجه داشته باشید که استفاده از TLS ممکن است توسط -tls_used یا -server با پیشوند "https" الزامی شود)، همچنین هرگونه مؤلفه مسیر، userinfo، query و fragment نادیده گرفته می‌شوند. در صورت تنظیم به متغیر محیطی "http_proxy" و در غیر این صورت به "HTTP_PROXY" در صورتی که TLS استفاده نشود، و در غیر این صورت به "https_proxy" در صورت تنظیم وگرنه "HTTPS_PROXY" بازمی‌گردد. اگر -server داده نشود، این گزینه نادیده گرفته می‌شود.
فهرستی از آدرس‌های IP و/یا نام‌های DNS سرورها که نباید برای آن‌ها از پراکسی HTTP(S) استفاده شود، جداشده با کاما و/یا فاصله (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). پیش‌فرض از متغیر محیطی "no_proxy" در صورت تنظیم، وگرنه "NO_PROXY" گرفته می‌شود. اگر -server داده نشود، این گزینه نادیده گرفته می‌شود.
نام متمایز (DN) برای استفاده در فیلد گیرنده (recipient) هدر پیام‌های درخواست CMP، یعنی سرور CMP (معمولاً CA مورد خطاب).

فیلد گیرنده در هدر یک پیام CMP الزامی است. اگر صریحاً داده نشود، گیرنده به ترتیب زیر تعیین می‌شود: موضوع گواهی سرور CMP ارائه‌شده با گزینه -srvcert، گزینه -issuer، صادرکننده گواهی داده‌شده با گزینه -oldcert، صادرکننده گواهی کلاینت CMP (گزینه -cert)، تا جایی که هر یک از آن‌ها موجود باشد، وگرنه به عنوان آخرین چاره NULL-DN.

آرگومان باید به صورت /type0=value0/type1=value1/type2=... قالب‌بندی شود. برای جزئیات به توضیحات گزینه -subject مراجعه کنید.

مسیر HTTP در سرور CMP (معروف به نام مستعار CMP یا CMP alias) برای استفاده در درخواست‌های POST. پیش‌فرض هر مسیری است که با -server داده شده باشد، در غیر این صورت "/".
اگر مقدار داده‌شده 0 باشد، اتصالات HTTP پس از هر پاسخ بسته می‌شوند (که رفتار پیش‌فرض HTTP 1.0 است) حتی اگر یک تراکنش CMP به بیش از یک رفت‌وبرگشت (round trip) نیاز داشته باشد. اگر مقدار 1 یا 2 باشد، برای هر تراکنش یک اتصال پایدار (persistent connection) درخواست می‌شود. اگر مقدار 2 باشد، یک اتصال پایدار الزامی است، یعنی اگر سرور آن را نپذیرد، خطا رخ می‌دهد. مقدار پیش‌فرض 1 است، که به معنای ترجیح برای باز نگه‌داشتن اتصال است.
تعداد ثانیه‌هایی که یک رفت‌وبرگشت پیام درخواست-پاسخ CMP مجاز است طول بکشد پیش از اینکه خطای مهلت زمانی بازگردانده شود. مقدار کوچک‌تر یا مساوی 0 به معنای عدم محدودیت (انتظار نامحدود) است. پیش‌فرض استفاده از تنظیم -total_timeout است.
حداکثر کل ثانیه‌هایی که یک تراکنش می‌تواند طول بکشد، شامل نظرسنجی (polling) و غیره. مقدار کوچک‌تر یا مساوی 0 به معنای عدم محدودیت (انتظار نامحدود) است. پیش‌فرض 0 است.

گواهی(های) مد نظر (معمولاً CAهای ریشه) که کلاینت باید به عنوان لنگرهای اعتماد هنگام اعتبارسنجی حفاظت مبتنی بر امضای پیام‌های پاسخ CMP استفاده کند. این گزینه در صورت تعیین همزمان گزینه -srvcert نادیده گرفته می‌شود. این گزینه انعطاف‌پذیری بیشتری نسبت به -srvcert فراهم می‌کند زیرا گواهی حفاظت CMP سرور سنجاق (pin) نمی‌شود، بلکه می‌تواند هر گواهی‌ای باشد که بتوان زنجیره‌ای از آن به یکی از لنگرهای اعتماد مشخص‌شده ساخت.

اگر هیچ‌یک از گزینه‌های -trusted، -srvcert و -secret مشخص نشوند، خطاهای اعتبارسنجی پیام ایجاد خواهند شد، مگر آنکه -unprotected_errors یک استثنا قائل شود.

می‌توان چندین منبع را جداشده با کاما و/یا فاصله مشخص کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). هر منبع ممکن است حاوی چندین گواهی باشد.

گزینه‌های اعتبارسنجی گواهی -verify_hostname، -verify_ip و -verify_email هیچ تأثیری بر اعتبارسنجی گواهی فعال‌شده از طریق این گزینه ندارند.

گواهی(های) میانی نامعتمد CA. هرگونه گواهی اضافی ارائه‌شده با گزینه -cert به آن اضافه می‌شود. تمام این گواهی‌ها ممکن است برای ساخت مسیر گواهی جهت گواهی امضاکننده CMP خود کلاینت (جهت قرارگیری در فیلد extraCerts پیام‌های درخواست) و برای گواهی کلاینت TLS (در صورت استفاده از TLS) و همچنین برای ساخت زنجیره هنگام اعتبارسنجی گواهی‌های سرور (بررسی حفاظت مبتنی بر امضای پیام CMP) و هنگام اعتبارسنجی گواهی‌های تازه ثبت‌نام‌شده مفید باشند.

می‌توان چندین منبع را جداشده با کاما و/یا فاصله مشخص کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). هر منبع ممکن است حاوی چندین گواهی باشد.

گواهی خاص سرور CMP برای انتظار و اعتماد مستقیم (حتی اگر منقضی شده باشد) هنگام بررسی حفاظت مبتنی بر امضای پیام‌های پاسخ CMP. این کار سرور پذیرفته‌شده را سنجاق (pin) کرده و باعث نادیده گرفته شدن گزینه -trusted می‌شود.

در صورت تنظیم، موضوع گواهی همچنین به عنوان مقدار پیش‌فرض گیرنده درخواست‌های CMP و مقدار پیش‌فرض فرستنده مورد انتظار پاسخ‌های CMP استفاده می‌شود.

نام متمایز (DN) مورد انتظار در فیلد فرستنده پیام‌های دریافتی CMP. پیش‌فرض آن DN موضوع -srvcert سنجاق‌شده است (در صورت وجود).

این گزینه می‌تواند برای اطمینان از اینکه فقط یک موجودیت مشخص به عنوان امضاکننده پیام CMP پذیرفته می‌شود استفاده گردد تا مهاجمان نتوانند از گواهی‌های دلخواه یک سلسله‌مراتب PKI معتمد برای جا زدن خود به عنوان سرور CMP سوءاستفاده کنند. توجه داشته باشید که این گزینه نسبت به تنظیم -srvcert آزادی عمل بیشتری می‌دهد، چرا که -srvcert سرور را به دارنده یک گواهی خاص محدود می‌کند، در حالی که نام فرستنده مورد انتظار پس از به‌روزرسانی‌های گواهی سرور نیز همچنان تطابق خواهد داشت.

آرگومان باید به صورت /type0=value0/type1=value1/type2=... قالب‌بندی شود. برای جزئیات به توضیحات گزینه -subject مراجعه کنید.

نادیده گرفتن محدودیت‌های استفاده از کلید (key usage) در گواهی‌های امضاکننده CMP هنگام اعتبارسنجی حفاظت مبتنی بر امضای پیام‌های دریافتی CMP. به طور پیش‌فرض، "digitalSignature" باید توسط گواهی‌های امضاکننده CMP مجاز باشد. این گزینه برای هر دو کلاینت CMP و سرور ماک اعمال می‌شود.
پذیرش حفاظت نامعتبر یا گم‌شده در پاسخ‌های منفی از سوی سرور. این برای انواع پیام‌ها و محتواهای زیر اعمال می‌شود:
  • پیام‌های خطا
  • پاسخ‌های منفی گواهی (IP/CP/KUP)
  • پاسخ‌های منفی ابطال (RP)
  • پیام‌های منفی PKIConf

هشدار: این تنظیم منجر به رفتاری نامشخص می‌شود و منحصراً برای فراهم آوردن امکان تعامل با پیاده‌سازی‌های سروری که ناقض RFC 9810 هستند در نظر گرفته شده است؛ به عنوان مثال:

  • بخش 5.1.3.1 استثنائات عدم حفاظت را فقط برای موارد خاص مجاز می‌داند: "ممکن است مواردی وجود داشته باشد که در آن‌ها از رشته بیتی PKIProtection عمداً برای حفاظت از پیام استفاده نشود [...] زیرا حفاظت دیگری، خارج از PKIX، به جای آن اعمال خواهد شد."
  • بخش 5.3.21 در رابطه با ErrMsgContent صریح است: "مرجع صدور گواهی (CA) همواره باید آن را با یک کلید امضا، امضا کند."
  • پیوست D.4 پیام PKIConf را با داشتن حفاظت نشان می‌دهد.
عدم ذخیره در حافظه موقت (cache) برای گواهی‌های موجود در فیلد extraCerts پیام‌های CMP دریافتی. به طور پیش‌فرض، این گواهی‌ها نگهداری می‌شوند زیرا ممکن است برای اعتبارسنجی پیام‌های بعدی مفید باشند. این گزینه برای کلاینت‌های CMP و سرور ماک اعمال می‌شود.

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

فایلی برای ذخیره گواهی با موفقیت اعتبارسنجی‌شده (در صورت وجود) که سرور CMP برای حفاظت مبتنی بر امضای پیام پاسخ استفاده کرده است. اگر چنین گواهی‌ای وجود نداشته باشد (معمولاً به دلیل اینکه حفاظت مبتنی بر MAC بوده است)، این مورد با حذف فایل (در صورت وجود) نشان داده می‌شود.
فایلی برای ذخیره فهرست گواهی‌های موجود در فیلد extraCerts آخرین پیام پاسخ دریافتی که pollRep یا PKIConf نباشد.
فایلی برای ذخیره فهرست گواهی‌های CA موجود در فیلد caPubs در صورت دریافت یک پیام پاسخ گواهی مثبت (یعنی IP، CP یا KUP) یا موجود در یک پیام پاسخ عمومی (genp) با infoType از نوع "caCerts".
گواهی ریشه CA برای گنجاندن در یک درخواست genm از نوع infoType با مقدار "rootCaCert". در صورت وجود و دریافت گواهی اختیاری oldWithNew، این گواهی با استفاده از گواهی newWithNew به عنوان (تنها) لنگر اعتماد بررسی و اعتبارسنجی می‌شود.
این گزینه باید زمانی که -infotype rootCaCert داده می‌شود، فراهم گردد. این گزینه فایلی را برای ذخیره گواهی newWithNew دریافتی در پیام genp از نوع "rootCaKeyUpdate" مشخص می‌کند. اگر در صورت موفقیت چنین گواهی‌ای دریافت نشود، این فایل (در صورت وجود) حذف می‌شود تا نشان دهد به‌روزرسانی گواهی ریشه درخواستی CA در دسترس نیست.

هر گواهی newWithNew دریافت‌شده با استفاده از هر گواهی newWithOld دریافتی به عنوان گواهی میانی نامعتمد و گواهی ارائه‌شده با -oldwithold به عنوان (تنها) لنگر اعتماد، یا در صورت عدم ارائه، با استفاده از گواهی‌های ارائه‌شده با گزینه -trusted اعتبارسنجی می‌شود.

هشدار: گواهی newWithNew قرار است گواهی‌ای باشد که مورد اعتماد قرار می‌گیرد. اعتماد قرار داده‌شده به آن نمی‌تواند قوی‌تر از اعتماد قرار داده‌شده به گواهی -oldwithold (در صورت وجود) باشد، در غیر این صورت نمی‌تواند قوی‌تر از ضعیف‌ترین اعتماد قرار داده‌شده به هر یک از گواهی‌های -trusted باشد.

فایلی برای ذخیره هرگونه گواهی newWithOld دریافتی در پیام genp با infoType از نوع "rootCaKeyUpdate". اگر در صورت موفقیت چنین گواهی‌ای دریافت نشود، این موضوع با حذف فایل نشان داده می‌شود.
فایلی برای ذخیره هرگونه گواهی oldWithNew دریافتی در پیام genp با infoType از نوع "rootCaKeyUpdate". اگر در صورت موفقیت چنین گواهی‌ای دریافت نشود، این موضوع با حذف فایل نشان داده می‌شود.
گواهی برای استخراج داده‌های صادرکننده CRL برای فیلد منبع هنگام دریافت CRL در درخواست genm با infoType از نوع "crlStatusList". هر نام نقطه توزیع (distribution point) موجود بر نام‌های صادرکننده ترجیح داده می‌شود.
فهرست CRL برای دریافت به‌روزرسانی در درخواست genm با infoType از نوع "crlStatusList". مگر اینکه گزینه -crlcert نیز ارائه شده باشد، از CRL داده‌شده برای استخراج داده‌های صادرکننده CRL برای فیلد منبع استفاده می‌شود. هر نام نقطه توزیع موجود بر نام‌های صادرکننده ترجیح داده می‌شود. اگر CRL حاوی فیلد thisUpdate باشد، مقدار آن در درخواست کپی می‌شود.
فایلی برای ذخیره هرگونه CRL دریافت‌شده در پیام genp با infoType از نوع "crls". اگر در صورت موفقیت چنین CRLای دریافت نشود، این موضوع با حذف فایل نشان داده می‌شود.

شماره/رشته/مقدار مرجع برای استفاده به عنوان senderKID جایگزین؛ این مورد در صورتی که نتوان نام فرستنده‌ای را از گزینه‌های -cert یا -subject تعیین کرد الزامی است و معمولاً هنگام احراز هویت با کلید از پیش اشتراک‌گذاشته‌شده (MAC مبتنی بر گذرواژه) استفاده می‌شود.
منبع یک مقدار محرمانه (secret) را برای استفاده در حفاظت پیام مبتنی بر MAC فراهم می‌کند. این گزینه بر گزینه‌های -cert و -key اولویت دارد. مقدار محرمانه برای ایجاد حفاظت مبتنی بر MAC در پیام‌های خروجی و برای اعتبارسنجی پیام‌های ورودی دارای حفاظت مبتنی بر MAC استفاده می‌شود. الگوریتم پیش‌فرض کد احراز هویت پیام مبتنی بر گذرواژه (PBM) طبق تعریف بخش 5.1.3.1 در RFC 9810 است.

برای اطلاعات بیشتر درباره قالب arg به openssl-passphrase-options(1) مراجعه کنید.

گواهی فعلی امضاکننده CMP کلاینت. نیازمند این است که کلید متناظر با -key ارائه شود.

موضوع و کلید عمومی موجود در این گواهی به عنوان مقادیر جایگزین در الگوی گواهی پیام‌های IR/CR/KUR عمل می‌کنند.

موضوع این گواهی به عنوان فرستنده پیام‌های خروجی CMP استفاده خواهد شد، در حالی که موضوع -oldcert یا -subject ممکن است مقادیر جایگزین فراهم کنند.

صادرکننده این گواهی به عنوان یکی از مقادیر جایگزین گیرنده و به عنوان ورودی صادرکننده جایگزین در الگوی گواهی پیام‌های IR/CR/KUR استفاده می‌شود.

هنگام انجام حفاظت پیام مبتنی بر امضا، این "گواهی حفاظت" که "گواهی امضاکننده" نیز نامیده می‌شود، ابتدا در فیلد extraCerts پیام‌های خروجی قرار می‌گیرد و امضا با کلید متناظر انجام می‌شود. در پیام‌های درخواست مقداردهی اولیه (IR)، این گزینه می‌تواند برای احراز هویت با استفاده از یک گواهی موجودیت خارجی طبق تعریف پیوست D.7 از RFC 9810 استفاده شود.

برای پیام‌های درخواست به‌روزرسانی کلید (KUR)، این گزینه در صورتی که -oldcert داده نشده باشد به عنوان گواهی مورد به‌روزرسانی نیز استفاده می‌شود.

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

اگر این فهرست از گواهی‌ها ارائه شود، زنجیره ساخته‌شده برای گواهی امضاکننده CMP سمت کلاینت ارائه‌شده با گزینه -cert با استفاده از گواهی‌های داده‌شده به عنوان لنگرهای اعتماد اعتبارسنجی می‌شود.

می‌توان چندین منبع را جداشده با کاما و/یا فاصله مشخص کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). هر منبع ممکن است حاوی چندین گواهی باشد.

گزینه‌های اعتبارسنجی گواهی -verify_hostname، -verify_ip و -verify_email هیچ تأثیری بر اعتبارسنجی گواهی فعال‌شده از طریق این گزینه ندارند.

فایل کلید خصوصی متناظر برای گواهی فعلی کلاینت داده‌شده در گزینه -cert. این کلید برای حفاظت پیام مبتنی بر امضا استفاده خواهد شد، مگر آنکه گزینه -secret نشان‌دهنده حفاظت مبتنی بر MAC یا -unprotected_requests داده شده باشد.

همچنین به عنوان جایگزین برای گزینه -newkey در پیام‌های IR/CR/KUR استفاده می‌شود.

منبع عبارت عبور برای کلید خصوصی داده‌شده با گزینه -key. همچنین برای -cert و -oldcert در صورتی که یک فایل رمزشده PKCS#12 باشند استفاده می‌شود. اگر در اینجا مشخص نشود، در صورت نیاز رمز عبور درخواست خواهد شد.

برای اطلاعات بیشتر درباره قالب arg به openssl-passphrase-options(1) مراجعه کنید.

نام خلاصه پیام (digest) پشتیبانی‌شده را برای استفاده در MSG_SIG_ALG مربوط به RFC 9810 و به عنوان تابع یک‌طرفه (OWF) در "MSG_MAC_ALG" مشخص می‌کند. در صورت کاربرد، این گزینه برای حفاظت پیام و امضاهای اثبات مالکیت (POPO) استفاده می‌شود. برای مشاهده فهرست خلاصه پیام‌های پشتیبانی‌شده از دستور "openssl list -digest-commands" استفاده کنید. پیش‌فرض "sha256" است.
نام الگوریتم MAC را در "MSG_MAC_ALG" مشخص می‌کند. برای دریافت نام‌های الگوریتم‌های MAC پشتیبانی‌شده از "openssl list -mac-algorithms" استفاده کنید و در صورت نیاز چنین نامی را با نام یک الگوریتم دایجست پشتیبانی‌شده ترکیب کنید، مثلاً hmacWithSHA256. پیش‌فرض "hmac-sha1" است، جهت سازگاری با گذشته مطابق RFC 4210.
گواهی‌هایی برای الحاق در فیلد extraCerts هنگام ارسال پیام‌ها. می‌توان از آن‌ها به عنوان زنجیره پیش‌فرض گواهی امضاکننده CMP برای درج در پیام استفاده کرد.

می‌توان چندین منبع را جداشده با کاما و/یا فاصله مشخص کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). هر منبع ممکن است حاوی چندین گواهی باشد.

ارسال پیام‌های درخواست بدون حفاظت در سطح CMP.

قالب فایل مورد استفاده هنگام ذخیره گواهی در یک فایل. مقدار پیش‌فرض PEM است.
قالب فایل مورد استفاده هنگام ذخیره یک CRL در یک فایل. مقدار پیش‌فرض DER است. قالب DER ترجیح داده می‌شود زیرا ذخیره‌سازی کارآمدتر CRLهای بزرگ را امکان‌پذیر می‌سازد.
قالب ورودی کلید؛ به طور پیش‌فرض نامشخص است. برای جزئیات به "گزینه‌های قالب (Format Options)" در openssl(1) مراجعه کنید.
منبع عبارت عبور برای گواهی ارائه‌شده با گزینه‌های -trusted، -untrusted، -own_trusted، -srvcert، -crlcert، -out_trusted، -extracerts، -srv_trusted، -srv_untrusted، -ref_cert، -rsp_extracerts، -rsp_capubs، -rsp_newwithnew، -rsp_newwithold، -rsp_oldwithnew، -tls_extra و -tls_trusted. اگر در اینجا مشخص نشود، در صورت نیاز رمز عبور درخواست خواهد شد.

برای اطلاعات بیشتر درباره قالب arg به openssl-passphrase-options(1) مراجعه کنید.

به "گزینه‌های موتور (Engine Options)" در openssl(1) مراجعه کنید. این گزینه منسوخ شده است.

به عنوان جایگزینی برای استفاده از این ترکیب:

-engine {engineid} -key {keyid} -keyform ENGINE

همچنین می‌توان شناسه کلید را به صورت URI به -key داد، مانند این:

-key org.openssl.engine:{engineid}:{keyid}

این مورد برای تمام گزینه‌هایی که کلیدها را تعیین می‌کنند اعمال می‌شود: -key، -newkey و -tls_key.

به "گزینه‌های ارائه‌دهنده (Provider Options)" در openssl(1)، provider(7) و property(7) مراجعه کنید.

برای جزئیات به "گزینه‌های وضعیت تصادفی (Random State Options)" در openssl(1) مراجعه کنید.

وادار کردن کلاینت CMP به استفاده از TLS (صرف‌نظر از اینکه سایر گزینه‌های مربوط به TLS تنظیم شده باشند یا خیر) برای تبادل پیام با سرور از طریق HTTP. این گزینه با گزینه -port پشتیبانی نمی‌شود. اگر گزینه -server با طرح‌واره "https" داده شود، این گزینه ضمنی است. اگر گزینه -server داده نشود یا -use_mock_srv داده شود یا -rspin با تعداد کافی آرگومان نام فایل ارائه شود، نادیده گرفته می‌شود.

در صورتی که TLS استفاده نشود، گزینه‌های مربوط به TLS زیر نادیده گرفته می‌شوند.

گواهی TLS کلاینت برای احراز هویت در برابر سرور TLS. اگر منبع شامل گواهی‌های بیشتری باشد، آن‌ها (در کنار گواهی‌های -untrusted) برای ساخت زنجیره گواهی کلاینت که به سرور TLS ارائه می‌شود استفاده خواهند شد.
کلید خصوصی برای گواهی TLS کلاینت.
منبع عبارت عبور برای کلید خصوصی TLS کلاینت (-tls_key). همچنین برای -tls_cert در صورتی که یک فایل رمزشده PKCS#12 باشد استفاده می‌شود. اگر در اینجا مشخص نشود، در صورت نیاز رمز عبور درخواست خواهد شد.

برای اطلاعات بیشتر درباره قالب arg به openssl-passphrase-options(1) مراجعه کنید.

گواهی‌های اضافی برای ارائه به سرور TLS هنگام دست‌تکانی (handshake).
گواهی(های) معتمد برای استفاده در اعتبارسنجی گواهی سرور TLS. این متضمن اعتبارسنجی نام میزبان (hostname validation) است.

می‌توان چندین منبع را جداشده با کاما و/یا فاصله مشخص کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد). هر منبع ممکن است حاوی چندین گواهی باشد.

گزینه‌های اعتبارسنجی گواهی -verify_hostname، -verify_ip و -verify_email هیچ تأثیری بر اعتبارسنجی گواهی فعال‌شده از طریق این گزینه ندارند.

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

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

این گزینه برای پشتیبانی از سناریوهای آفلاین مفید است که در آن‌ها درخواست گواهی (یا هر درخواست CMP دیگر) از قبل تولید شده و بعداً ارسال می‌شود.

اگر گزینه -rspin داده شود، این گزینه نادیده گرفته می‌شود زیرا در حالت اخیر در عمل هیچ درخواستی ارسال نمی‌شود.

توجه داشته باشید که کلاینت در هر صورت توالی پیام‌های درخواست CMP خود را به صورت داخلی تولید می‌کند. بنابراین، تمامی گزینه‌های لازم برای انجام این کار (مانند -cmd و تمام گزینه‌های فراهم‌کننده پارامترهای لازم) باید هنگام حضور گزینه -reqin نیز ارائه شوند.

اگر گزینه -reqin برای یک درخواست گواهی ارائه شود و هیچ‌یک از گزینه‌های -newkey، -key، -oldcert یا -csr مشخص نشده باشند، یک کلید عمومی جایگزین از فایل پیام درخواست گرفته می‌شود (در صورتی که در الگوی گواهی گنجانده شده باشد).

راهنمایی: در صورتی که گزینه -reqin برای درخواست گواهی داده شود، موقعیت‌هایی وجود دارد که در آن‌ها کلاینت به کلید عمومی برای صدور گواهی دسترسی دارد اما به کلید خصوصی که به طور پیش‌فرض برای اثبات مالکیت لازم است دسترسی ندارد. در این حالت POPO در عمل لازم نیست (زیرا پیام درخواست گواهی تولیدشده به صورت داخلی ارسال نخواهد شد)، و تولید آن را می‌توان با گزینه‌های -popo -1 یا -popo 0 غیرفعال کرد.

می‌توان چندین نام فایل را جداشده با کاما و/یا فاصله مشخص کرد (که در حالت اخیر کل آرگومان باید در "..." قرار گیرد).

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

کلاینت برای برآورده کردن بررسی‌هایی که باید توسط سرور انجام شود، نیاز دارد فیلد recipNonce را در درخواست‌های داده‌شده (به جز اولی) به‌روزرسانی کند. این امر باعث حفاظت مجدد (در صورت الزامی بودن حفاظت از درخواست‌ها) می‌شود.

استفاده از یک transactionID تازه برای پیام‌های درخواست CMP خوانده‌شده با -reqin، که باعث محافظت مجدد از آن‌ها می‌شود (اگر حفاظت از درخواست‌ها الزامی باشد). این ممکن است در حالتی لازم باشد که توالی درخواست‌ها مجدداً استفاده شود و سرور CMP اعتراض کند که شناسه تراکنش قبلاً استفاده شده است.
ذخیره توالی درخواست‌های CMP ایجادشده توسط کلاینت در فایل(های) داده‌شده. این درخواست‌ها در صورتی که از گزینه -reqin نیز استفاده شود، به سرور ارسال نمی‌شوند.

می‌توان چندین نام فایل را جداشده با کاما و/یا فاصله مشخص کرد.

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

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

این گزینه برای پشتیبانی از سناریوهای آفلاین مناسب است که در آن‌ها درخواست گواهی (یا هر درخواست CMP دیگر) از قبل تولید شده و بعداً ارسال می‌گردد.

پردازش توالی پاسخ‌های CMP ارائه‌شده در فایل(های) داده‌شده، بدون برقراری تماس با سرور مشخص‌شده، تا زمانی که نام فایل‌های کافی برای تکمیل تراکنش فراهم باشد.

می‌توان چندین نام فایل را جداشده با کاما و/یا فاصله مشخص کرد.

با هر سرور مشخص‌شده از طریق گزینه‌های -server یا -use_mock_srv تنها زمانی تماس گرفته می‌شود که برای تکمیل تراکنش به پاسخ‌های بیشتری نیاز باشد. در این حالت تراکنش ناموفق خواهد بود مگر آنکه سرور برای ادامه تراکنشی که قبلاً آغاز شده آماده شده باشد.

ذخیره توالی پاسخ‌های CMP واقعاً استفاده‌شده در فایل(های) داده‌شده. این پاسخ‌ها از سرور دریافت شده‌اند مگر آنکه -rspin اعمال شود.

می‌توان چندین نام فایل را جداشده با کاما و/یا فاصله مشخص کرد.

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

آزمون کلاینت با استفاده از ماک سرور CMP داخلی در سطح API، با دور زدن انتقال مبتنی بر سوکت از طریق HTTP. این گزینه مانع استفاده از گزینه‌های -server و -port می‌شود.

عمل کردن به عنوان ماک سرور CMP مبتنی بر HTTP در حال گوش دادن روی پورت محلی مشخص‌شده. کلاینت ممکن است سرور را از طریق مثلاً 127.0.0.1 یا "[::1]" مورد خطاب قرار دهد. این گزینه مانع استفاده از گزینه‌های -server و -use_mock_srv می‌شود. گزینه‌های -rspin، -rspout، -reqin و -reqout تاکنون در این حالت پشتیبانی نمی‌شوند.
حداکثر تعداد پیام‌های (درخواست) CMP که ماک سرور HTTP مربوط به CMP باید مدیریت کند، که باید غیرمنفی باشد. مقدار پیش‌فرض 0 است که به معنای عدم اعمال محدودیت است. در هر صورت، سرور در اثر خطاهای داخلی خاتمه می‌یابد، اما زمانی که خطایی در سطح CMP تشخیص دهد که بتواند با موفقیت با یک پیام خطا به آن پاسخ دهد متوقف نمی‌شود.
مقدار مرجع برای استفاده به عنوان senderKID سرور در صورتی که هیچ -srv_cert داده نشده باشد.
منبع رمز عبور برای احراز هویت سرور با یک کلید از پیش اشتراک‌گذاشته‌شده (secret).
گواهی سرور.
کلید خصوصی مورد استفاده سرور برای امضای پیام‌ها.
منبع عبارت عبور فایل کلید خصوصی (و گواهی) سرور.
گواهی‌های معتمد برای احراز هویت کلاینت.

گزینه‌های اعتبارسنجی گواهی -verify_hostname، -verify_ip و -verify_email هیچ تأثیری بر اعتبارسنجی گواهی فعال‌شده از طریق این گزینه ندارند.

گواهی‌های CA میانی که ممکن است هنگام اعتبارسنجی گواهی‌های کلاینت مفید باشند.
گواهی مورد انتظار برای پیام‌های RR و هرگونه oldCertID در پیام‌های KUR.
گواهی مورد بازگردانی به عنوان نتیجه ثبت‌نام ماک.
کلید خصوصی مورد بازگردانی به عنوان نتیجه تولید متمرکز کلید.
منبع عبارت عبور برای rsp_cert و rsp_key.
فهرست CRL مورد بازگردانی در genp از نوع "crls".
گواهی‌های اضافی برای درج در پاسخ‌های صدور گواهی ماک.
گواهی‌های CA برای گنجاندن در پیام پاسخ مقداردهی اولیه (IP) ماک.
گواهی برای بازگردانی در فیلد newWithNew مربوط به genp از نوع rootCaKeyUpdate.
گواهی برای بازگردانی در فیلد newWithOld مربوط به genp از نوع rootCaKeyUpdate.
گواهی برای بازگردانی در فیلد oldWithNew مربوط به genp از نوع rootCaKeyUpdate.
تعداد دفعاتی که کلاینت پیش از دریافت گواهی باید نظرسنجی (poll) کند.
مقدار checkAfter (تعداد ثانیه‌های انتظار) برای درج در پاسخ نظرسنجی.
اعطای تایید ضمنی برای گواهی تازه ثبت‌نام‌شده.
مقدار PKIStatus برای درج در پاسخ سرور. محدوده معتبر 0 (پذیرفته‌شده / accepted) تا 6 (هشدار به‌روزرسانی کلید / keyUpdateWarning) است.
یک شماره بیت اطلاعات شکست برای درج در پاسخ سرور. محدوده معتبر 0 (الگوریتم نامعتبر / badAlg) تا 26 (درخواست گواهی تکراری / duplicateCertReq) است.
متنی برای درج به عنوان رشته وضعیت در پاسخ سرور.
اجبار سرور به پاسخ با پیام خطا.
ارسال پیام‌های پاسخ بدون حفاظت در سطح CMP.
در صورت وجود پاسخ‌های منفی، سرور پیام‌های خطای محافظت‌نشده، پاسخ‌های گواهی (IP/CP/KUP) و پاسخ‌های ابطال (RP) محافظت‌نشده ارسال خواهد کرد. هشدار: این تنظیم منجر به رفتاری ناقض RFC 9810 می‌شود.
پذیرش حفاظت مفقود یا نامعتبر در درخواست‌ها.
پذیرش پیام‌های خطای بدون حفاظت از کلاینت. تاکنون این گزینه اثری ندارد زیرا سرور هیچ پیام خطایی را نمی‌پذیرد.
پذیرش RAVERIFIED به عنوان اثبات مالکیت (POPO).

تنظیم گزینه‌های گوناگون اعتبارسنجی زنجیره گواهی. برای جزئیات به "گزینه‌های اعتبارسنجی (Verification Options)" در openssl-verification-options(1) مراجعه کنید.

گزینه‌های اعتبارسنجی گواهی -verify_hostname، -verify_ip و -verify_email تنها بر اعتبارسنجی گواهی فعال‌شده از طریق گزینه -out_trusted اثر می‌گذارند.

هنگامی که یک کلاینت از یک سرور CMP گواهی‌های CA مورد اعتماد را دریافت می‌کند، برای نمونه از طریق فیلد "caPubs" در یک پاسخ گواهی یا با استفاده از پیام‌های عمومی با infoType از نوع "caCerts" یا "rootCaCert"، احراز هویت سرور CMP از اهمیت بسیار بالایی برخوردار است. بنابراین باید در تنظیم احراز هویت سرور با استفاده از -trusted و گزینه‌های مربوطه برای احراز هویت مبتنی بر گواهی یا -secret برای حفاظت مبتنی بر MAC دقت ویژه‌ای به عمل آید. اگر احراز هویت مبتنی بر گواهی باشد، باید از گزینه -srvcertout برای دریافت گواهی اعتبارسنجی‌شده سرور و انجام بررسی مجوز بر اساس آن استفاده شود.

هنگام راه‌اندازی پیکربندی‌های CMP و آزمایش گزینه‌های ثبت‌نام، معمولاً تا زمانی که پیکربندی صحیح و کامل شود، خطاهای گوناگونی رخ می‌دهد. هنگامی که سرور CMP خطایی را گزارش می‌کند، کلاینت به طور پیش‌فرض حفاظت پیام پاسخ CMP را بررسی خواهد کرد. با این حال، برخی از سرویس‌های CMP تمایلی به محافظت از پاسخ‌های منفی ندارند. در این حالت، کلاینت آن‌ها را رد می‌کند و بنابراین محتوای آن‌ها نمایش داده نمی‌شود، هرچند که معمولاً حاوی نکاتی هستند که برای عیب‌یابی مفید خواهند بود. برای کمک در چنین مواردی، کلاینت CMP از طریق گزینه -unprotected_errors یک راهکار جایگزین ارائه می‌دهد که امکان پذیرش چنین پیام‌های منفی را فراهم می‌سازد.

اگر OpenSSL با پشتیبانی از trace فعال ساخته شده باشد (مثلاً "./config enable-trace") و متغیر محیطی OPENSSL_TRACE شامل HTTP باشد، درخواست‌ها و هدرهای پاسخ انتقال‌یافته از طریق HTTP چاپ می‌شوند.

این پیاده‌سازی کلاینت CMP همراه با بخش‌های نمایشی CMP در فایل پیکربندی نمونه openssl/apps/openssl.cnf ارائه می‌شود که می‌تواند برای تعامل آسان با Insta Demo CA استفاده شود.

جهت ثبت‌نام یک گواهی اولیه از آن CA، اجرای دستورات شل زیر کافی است.

export OPENSSL_CONF=/path/to/openssl/apps/openssl.cnf
openssl genrsa -out insta.priv.pem
openssl cmp -section insta

این دستور باید فایل insta.cert.pem حاوی یک گواهی جدید برای کلید خصوصی نگه‌داری‌شده در insta.priv.pem را تولید کند. می‌توان آن را مثلاً با دستور زیر مشاهده کرد:

openssl x509 -noout -text -in insta.cert.pem

در صورتی که راه‌اندازی شبکه مستلزم استفاده از یک پراکسی HTTP باشد، می‌توان آن را طبق معمول از طریق متغیر محیطی http_proxy یا گزینه -proxy در فایل پیکربندی یا آرگومان خط فرمان CMP به نام -proxy مشخص کرد، برای نمونه:

-proxy http://192.168.1.1:8080

در سناریوی Insta Demo CA، هم کلاینت‌ها و هم سرور می‌توانند از کلید محرمانه از پیش اشتراک‌گذاشته‌شده insta و مقدار مرجع 3078 برای احراز هویت متقابل استفاده کنند.

به عنوان جایگزین، پیام‌های CMP را می‌توان به روش مبتنی بر امضا محافظت کرد، که در آن لنگر اعتماد در این مورد insta.ca.crt است و کلاینت می‌تواند از هر گواهی که قبلاً از آن CA دریافت کرده استفاده کند، همان‌طور که در بخش [signature] از پیکربندی نمونه مشخص شده است. این کار را می‌توان به سادگی همراه با بخش [insta] استفاده کرد:

openssl cmp -section insta,signature

به طور پیش‌فرض نوع پیام CMP از نوع IR استفاده می‌شود، با این حال CR نیز در اینجا به همان خوبی کار می‌کند. می‌توان این مورد را مستقیماً در خط فرمان تعیین کرد:

openssl cmp -section insta -cmd cr

یا با ارجاع به بخش [cr] در پیکربندی نمونه علاوه بر بخش قبلی:

openssl cmp -section insta,cr

جهت به‌روزرسانی گواهی ثبت‌نام‌شده می‌توان دستور زیر را فراخوانی کرد:

openssl cmp -section insta,kur,signature

با استفاده از حفاظت مبتنی بر امضا همراه با گواهی‌ای که قرار است به‌روزرسانی شود. برای به‌روزرسانی‌های گواهی، حفاظت مبتنی بر MAC عموماً نباید استفاده شود.

به روشی مشابه، هر گواهی از قبل ثبت‌نام‌شده را می‌توان ابطال کرد:

openssl cmp -section insta,rr -trusted insta.ca.crt

یا:

openssl cmp -section insta,rr,signature

گزینه‌های بسیار بیشتری را می‌توان در فایل پیکربندی و/یا در خط فرمان مشخص کرد. برای نمونه، گزینه خط فرمان -reqexts ممکن است به بخشی در فایل پیکربندی اشاره کند که افزونه‌های X.509 مورد استفاده در درخواست‌های گواهی را تعریف می‌کند، مانند "v3_req" در openssl/apps/openssl.cnf:

openssl cmp -section insta,cr -reqexts v3_req

مثال‌های زیر در ابتدا از یک فایل پیکربندی استفاده نمی‌کنند. آن‌ها فرض می‌کنند که می‌توان با یک سرور CMP روی پورت محلی TCP 80 تماس گرفت و درخواست‌ها را تحت نام مستعار /pkix/ می‌پذیرد.

برای ثبت‌نام نخستین گواهی خود، کلاینت یک کلید کلاینت تولید می‌کند و یک پیام درخواست اولیه را با استفاده از یک کلید محرمانه از پیش اشتراک‌گذاشته‌شده برای احراز هویت متقابل به سرور محلی CMP ارسال می‌نماید. در این مثال کلاینت هنوز گواهی CA را ندارد، بنابراین ما نام CA را با گزینه -recipient مشخص می‌کنیم و هرگونه گواهی CA را که ممکن است دریافت کنیم در فایل "capubs.pem" ذخیره می‌نماییم.

در مثال‌های کاربرد خط فرمان زیر، کاراکتر "\" در انتهای خطوط فقط برای قالب‌بندی است؛ هر یک از فراخوانی‌های دستور باید در یک خط واحد باشند.

openssl genrsa -out cl_key.pem
openssl cmp -cmd ir -server 127.0.0.1:80/pkix/ -recipient "/CN=CMPserver" \
  -ref 1234 -secret pass:1234-5678 \
  -newkey cl_key.pem -subject "/CN=MyName" \
  -cacertsout capubs.pem -certout cl_cert.pem

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

openssl genrsa -out cl_key_new.pem
openssl cmp -cmd kur -server 127.0.0.1:80/pkix/ \
  -trusted capubs.pem \
  -cert cl_cert.pem -key cl_key.pem \
  -newkey cl_key_new.pem -certout cl_cert.pem
cp cl_key_new.pem cl_key.pem

این توالی دستورات را می‌توان به هر تعداد دفعات لازم تکرار کرد.

درخواست "تمامی اطلاعات مرتبط" با یک پیام عمومی خالی (empty General Message). این دستور اطلاعات مربوط به تمام infoTypeهای ITAV دریافت‌شده را در خروجی استاندارد چاپ می‌کند.

openssl cmp -cmd genm -server 127.0.0.1/pkix/ -recipient "/CN=CMPserver" \
  -ref 1234 -secret pass:1234-5678

برای فراخوانی‌های کلاینت CMP، به ویژه برای ثبت‌نام گواهی، معمولاً پارامترهای زیادی باید تنظیم شوند که انجام آن در خط فرمان خسته‌کننده و مستعد خطا است. بنابراین، کلاینت این امکان را فراهم می‌کند که گزینه‌ها از بخش‌های فایل پیکربندی OpenSSL که معمولاً openssl.cnf نامیده می‌شود خوانده شوند. مقادیر یافت‌شده در آنجا را می‌توان همچنان توسط بخش‌های بارگذاری‌شده بعدی و در خط فرمان گسترش داد و حتی بازنویسی کرد.

پس از گنجاندن بخش‌های زیر در فایل پیکربندی:

[cmp]
server = 127.0.0.1
path = pkix/
trusted = capubs.pem
cert = cl_cert.pem
key = cl_key.pem
newkey = cl_key.pem
certout = cl_cert.pem
[init]
recipient = "/CN=CMPserver"
trusted =
cert =
key =
ref = 1234
secret = pass:1234-5678-1234-567
subject = "/CN=MyName"
cacertsout = capubs.pem

تراکنش‌های ثبت‌نام فوق به این دستورات کاهش می‌یابند:

openssl cmp -section cmp,init
openssl cmp -cmd kur -newkey cl_key_new.pem

و تراکنش فوق با استفاده از یک پیام عمومی به این دستور کاهش می‌یابد:

openssl cmp -section cmp,init -cmd genm

openssl-genrsa(1), openssl-ecparam(1), openssl-list(1), openssl-req(1), openssl-x509(1), x509v3_config(5)

برنامه cmp در OpenSSL 3.0 اضافه شد.

گزینه -engine در OpenSSL 3.0 منسوخ شد.

گزینه‌های -oldwithold، -newwithnew، -newwithold، -oldwithnew، -srvcertout و -serial در OpenSSL 3.2 اضافه شدند، و همچنین گسترش -cacertsout برای استفاده هنگام دریافت گواهی‌های CA. از آن زمان، گزینه -issuer ممکن است برای گواهی‌های مورد نظر جهت ابطال نیز استفاده شود.

گزینه‌های -profile و -no_cache_extracerts در OpenSSL 3.3 اضافه شدند، همچنین پشتیبانی از تحویل با تأخیر (delayed delivery) برای تمام انواع پیام‌های پاسخ.

گزینه‌های -template، -crlcert، -oldcrl، -crlout، -crlform و -rsp_crl در OpenSSL 3.4 اضافه شدند.

گزینه‌های -centralkeygen، -newkeyout، -rsp_key و -rsp_keypass در OpenSSL 3.5 اضافه شدند.

حق نشر 2007-2026 متعلق به توسعه‌دهندگان پروژه OpenSSL است. کلیه حقوق محفوظ است.

تحت مجوز آپاچی نسخه 2.0 ("مجوز") مجوزدهی شده است. شما نباید از این فایل استفاده کنید مگر در انطباق با این مجوز. می‌توانید نسخه‌ای از آن را در فایل LICENSE در توزیع منبع یا در https://www.openssl.org/source/license.html دریافت نمایید.

2026-06-09 3.5.7