keytool(1) ابزارهای امنیتی keytool(1)

keytool - مدیریت انبار کلید (پایگاه‌داده) کلیدهای رمزنگاری، زنجیره‌های گواهی X.509 و گواهی‌های مورد اعتماد

keytool [دستورات]
دستورات
بخش دستورات را ببینید. این دستورات بر اساس وظیفه به شرح زیر دسته‌بندی شده‌اند:
•
ایجاد یا افزودن داده به انبار کلید
•
-gencert
•
-genkeypair
•
-genseckey
•
-importcert
•
-importpassword
•
وارد کردن محتوا از یک انبار کلید دیگر
•
-importkeystore
•
تولید درخواست گواهی
•
-certreq
•
صدور داده
•
-exportcert
•
نمایش داده‌ها
•
-list
•
-printcert
•
-printcertreq
•
-printcrl
•
مدیریت انبار کلید
•
-storepasswd
•
-keypasswd
•
-delete
•
-changealias
•
دریافت راهنما
•
-help

دستور keytool ابزاری برای مدیریت کلید و گواهی است. این ابزار به کاربران امکان می‌دهد جفت‌کلیدهای عمومی/خصوصی و گواهی‌های مرتبط خود را برای خوداحراز‌هویت (جایی که کاربر خود را به سایر کاربران و سرویس‌ها احراز هویت می‌کند) یا خدمات یکپارچگی داده و احراز هویت با استفاده از امضاهای دیجیتال مدیریت کنند. دستور keytool همچنین به کاربران اجازه می‌دهد کلیدهای عمومی طرف‌های ارتباطی خود را (در قالب گواهی‌ها) ذخیره موقت (کش) کنند.

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

دستور keytool همچنین به کاربران امکان می‌دهد کلیدهای مخفی و عبارت‌های عبور مورد استفاده در رمزنگاری و رمزگشایی متقارن (DES) را مدیریت نمایند.

دستور keytool کلیدها و گواهی‌ها را در یک انبار کلید (keystore) ذخیره می‌کند. نام‌های مستعار انبار کلید را ببینید.

برای فهرست و شرح دستورات مختلف به بخش دستورات مراجعه کنید.

•
نام تمام دستورات و گزینه‌ها با یک علامت خط تیره (-) آغاز می‌شود.
•
گزینه‌های هر دستور را می‌توان به هر ترتیبی ارائه داد.
•
تمام مواردی که مورب نبوده یا داخل آکولاد یا قلاب قرار ندارند، باید دقیقاً به همان صورت درج شوند.
•
آکولادها در اطراف یک گزینه نشان‌دهنده آن است که در صورت عدم تعیین گزینه در خط فرمان، از یک مقدار پیش‌فرض استفاده خواهد شد. بخش مقادیر پیش‌فرض گزینه‌ها را ببینید. همچنین در اطراف گزینه‌های -v، -rfc و -J از آکولاد استفاده شده که تنها هنگام حضور در خط فرمان معنا دارند. آن‌ها مقدار پیش‌فرضی جز عدم وجود ندارند.
•
قلاب‌ها در اطراف یک گزینه نشان‌دهنده آن است که اگر گزینه در خط فرمان مشخص نشود، از کاربر برای مقدار آن سوال خواهد شد. برای گزینه -keypass، اگر گزینه را در خط فرمان مشخص نکنید، دستور keytool ابتدا تلاش می‌کند از گذرواژه انبار کلید برای بازیابی کلید خصوصی/مخفی استفاده کند. اگر این تلاش ناموفق باشد، دستور keytool گذرواژه کلید خصوصی/مخفی را از شما درخواست می‌کند.
•
موارد مورب (مقادیر گزینه‌ها) نشان‌دهنده مقادیر واقعی هستند که باید فراهم شوند. برای نمونه، قالب دستور -printcert به این صورت است:
keytool -printcert {-file cert_file} {-v}

هنگامی که دستور -printcert را مشخص می‌کنید، cert_file را با نام فایل واقعی جایگزین کنید، مانند: keytool -printcert -file VScert.cer

•
مقادیر گزینه‌ها در صورتی که حاوی فاصله (space) باشند، باید داخل علامت نقل‌قول (کوتیشن) قرار گیرند.
•
گزینه -help پیش‌فرض است. دستور keytool به تنهایی همانند keytool -help عمل می‌کند.

مثال‌های زیر پیش‌فرض‌های مقادیر گزینه‌های مختلف را نشان می‌دهند.

-alias "mykey"
-keyalg
    "DSA" (هنگام استفاده از -genkeypair)
    "DES" (هنگام استفاده از -genseckey)
-keysize
    2048 (هنگام استفاده از -genkeypair و مقدار "RSA" برای -keyalg)
    1024 (هنگام استفاده از -genkeypair و مقدار "DSA" برای -keyalg)
    256 (هنگام استفاده از -genkeypair و مقدار "EC" برای -keyalg)
    56 (هنگام استفاده از -genseckey و مقدار "DES" برای -keyalg)
    168 (هنگام استفاده از -genseckey و مقدار "DESede" برای -keyalg)
-validity 90
-keystore <فایل به نام .keystore در دایرکتوری خانگی کاربر>
-storetype <مقدار مشخصه "keystore.type" در
    فایل مشخصه‌های امنیتی، که توسط متد ایستا
    getDefaultType در java.security.KeyStore برگردانده می‌شود>
-file
    stdin (در صورت خواندن)
    stdout (در صورت نوشتن)
-protected false

در تولید یک جفت‌کلید عمومی/خصوصی، الگوریتم امضا (گزینه -sigalg) از الگوریتم کلید خصوصی زیربنایی مشتق می‌شود:

•
اگر کلید خصوصی زیربنایی از نوع DSA باشد، گزینه -sigalg به طور پیش‌فرض روی SHA1withDSA تنظیم می‌شود.
•
اگر کلید خصوصی زیربنایی از نوع RSA باشد، گزینه -sigalg به طور پیش‌فرض روی SHA256withRSA تنظیم می‌شود.
•
اگر کلید خصوصی زیربنایی از نوع EC باشد، گزینه -sigalg به طور پیش‌فرض روی SHA256withECDSA تنظیم می‌شود.

برای مشاهده فهرست کامل آرگومان‌های -keyalg و -sigalg، راهنمای مرجع معماری رمزنگاری جاوا (JCA) را در نشانی زیر ببینید: http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA

گزینه -v می‌تواند برای تمام دستورات به جز -help استفاده شود. هنگامی که گزینه -v درج می‌شود، نشان‌دهنده حالت پرگو (verbose) است، به این معنی که اطلاعات بیشتری در خروجی ارائه می‌گردد.

همچنین یک آرگومان -Jjavaoption وجود دارد که می‌تواند برای هر دستوری استفاده شود. هنگامی که -Jjavaoption درج می‌شود، رشته javaoption مشخص‌شده مستقیماً به مفسر جاوا ارسال می‌گردد. این گزینه نباید حاوی هیچ فاصله‌ای باشد. برای تنظیم محیط اجرا یا مصرف حافظه کاربرد دارد. برای مشاهده فهرستی از گزینه‌های ممکن مفسر، دستور java -h یا java -X را در خط فرمان وارد کنید.

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


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

محل قرارگیری انبار کلید.

اگر از storetype نوع JKS استفاده شود و فایل انبار کلید هنوز وجود نداشته باشد، برخی دستورات keytool می‌توانند باعث ایجاد یک فایل انبار کلید جدید شوند. برای نمونه، اگر keytool -genkeypair فراخوانی شود و گزینه -keystore مشخص نشده باشد، فایل انبار کلید پیش‌فرض با نام .keystore در دایرکتوری خانگی کاربر در صورت عدم وجود ایجاد می‌شود. به طور مشابه، اگر گزینه -keystore ks_file مشخص شود اما ks_file وجود نداشته باشد، ایجاد خواهد شد. برای اطلاعات بیشتر در مورد storetype نوع JKS، بخش پیاده‌سازی انبار کلید در نام‌های مستعار انبار کلید را ببینید.

توجه داشته باشید که جریان ورودی از گزینه -keystore به متد KeyStore.load ارسال می‌شود. اگر NONE به عنوان نشانی URL مشخص شود، یک جریان تهی (null) به متد KeyStore.load ارسال می‌گردد. در صورتی که انبار کلید مبتنی بر فایل نباشد، مانند زمانی که روی یک دستگاه توکن سخت‌افزاری قرار دارد، باید مقدار NONE مشخص شود.


گذرواژه‌ای که برای محافظت از یکپارچگی انبار کلید استفاده می‌شود.

اگر اصلاح‌کننده env یا file مشخص نشده باشد، گذرواژه دارای مقدار آرگومان argument خواهد بود که باید حداقل ۶ کاراکتر باشد. در غیر این صورت، گذرواژه به صورت زیر بازیابی می‌شود:

•
env: بازیابی گذرواژه از متغیر محیطی با نام argument.
•
file: بازیابی گذرواژه از فایل با نام argument.

نکته: تمام گزینه‌های دیگری که نیازمند گذرواژه هستند، مانند -keypass، -srckeypass، -destkeypass، -srcstorepass و -deststorepass، اصلاح‌کننده‌های env و file را می‌پذیرند. به یاد داشته باشید که گزینه گذرواژه و اصلاح‌کننده را با یک دونقطه (:) جدا کنید.

گذرواژه باید برای تمام دستوراتی که به محتویات انبار کلید دسترسی دارند فراهم شود. برای چنین دستوراتی، هنگامی که گزینه -storepass در خط فرمان ارائه نشود، از کاربر خواسته می‌شود آن را وارد کند.

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


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

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

همراه با گزینه -providerClass برای نمایش یک آرگومان ورودی رشته‌ای اختیاری برای سازنده provider_class_name استفاده می‌شود.

مقدار true یا false. این مقدار زمانی باید true مشخص شود که گذرواژه باید از طریق یک مسیر احراز هویت محافظت‌شده مانند یک دستگاه اختصاصی کارت‌خوان پین مشخص گردد. از آنجا که دو انبار کلید در دستور -importkeystore درگیر هستند، دو گزینه -srcprotected و -destprotected به ترتیب برای انبار کلید مبدأ و مقصد ارائه شده‌اند.

نشان‌دهنده یک پسوند گواهی X.509 است. این گزینه می‌تواند در -genkeypair و -gencert برای گنجاندن پسوندها در گواهی تولیدشده، یا در -certreq برای نشان دادن پسوندهای درخواست‌شده در درخواست گواهی استفاده شود. این گزینه می‌تواند چندین بار درج شود. آرگومان name می‌تواند نام یک پسوند پشتیبانی‌شده (بخش پسوندهای نام‌دار را ببینید) یا یک شماره اختیاری OID باشد. آرگومان value در صورت ارائه، نشان‌دهنده آرگومان مربوط به پسوند است. هنگامی که value حذف شود، به معنای مقدار پیش‌فرض پسوند است یا اینکه پسوند نیازی به آرگومان ندارد. اصلاح‌کننده :critical در صورت ارائه، نشان می‌دهد که ویژگی isCritical پسوند برابر با true است؛ در غیر این صورت false خواهد بود. می‌توانید به جای :critical از :c استفاده کنید.

دستور keytool از این پسوندهای نام‌دار پشتیبانی می‌کند. نام‌ها به بزرگی و کوچکی حروف حساس نیستند.

مقادیر: شکل کامل آن: ca:{true|false}[,pathlen:<len>] یا <len> است که شکل کوتاه ca:true,pathlen:<len> می‌باشد. هنگامی که <len> حذف شود، برابر با ca:true است.
مقادیر: usage(,usage)*، که در آن usage می‌تواند یکی از مقادیر digitalSignature، nonRepudiation (محتوای تعهد یا contentCommitment)، keyEncipherment، dataEncipherment، keyAgreement، keyCertSign، cRLSign، encipherOnly یا decipherOnly باشد. تا زمانی که ابهامی وجود نداشته باشد، آرگومان usage می‌تواند با چند حرف اول (dig برای digitalSignature) یا به سبک شتری (dS برای digitalSignature یا cRLS برای cRLSign) مخفف شود. مقادیر usage به بزرگی و کوچکی حروف حساس هستند.
مقادیر: usage(,usage)*، که در آن usage می‌تواند یکی از مقادیر anyExtendedKeyUsage، serverAuth، clientAuth، codeSigning، emailProtection، timeStamping، OCSPSigning یا هر رشته OID باشد. تا زمانی که ابهامی وجود نداشته باشد، آرگومان usage می‌تواند با چند حرف اول یا به سبک شتری مخفف شود. مقادیر usage به بزرگی و کوچکی حروف حساس هستند.
مقادیر: type:value(,type:value)*، که در آن type می‌تواند EMAIL، URI، DNS، IP یا OID باشد. آرگومان value مقدار فرمت رشته‌ای برای آن type است.
مقادیر: همانند SubjectAlternativeName.
مقادیر: method:location-type:location-value (,method:location-type:location-value)*، که در آن method می‌تواند timeStamping، caRepository یا هر OID باشد. آرگومان‌های location-type و location-value می‌توانند هر مقدار type:value پشتیبانی‌شده توسط پسوند SubjectAlternativeName باشند.
مقادیر: همانند SubjectInfoAccess. آرگومان method می‌تواند ocsp، caIssuers یا هر OID باشد.

هنگامی که name برابر با OID باشد، مقدار آن کدگذاری هگزادسیمال DER مربوط به extnValue برای پسوند بدون نوع OCTET STRING و بایت‌های طول خواهد بود. به جز اعداد هگزادسیمال استاندارد (0-9, a-f, A-F)، هر نویسه اضافی در رشته هگز نادیده گرفته می‌شود. بنابراین هر دو مقدار 01:02:03:04 و 01020304 به عنوان مقادیر یکسان پذیرفته می‌شوند. هنگامی که مقداری وجود ندارد، پسوند دارای فیلد مقدار خالی است.

نام ویژه honored که تنها در -gencert استفاده می‌شود، مشخص می‌کند که پسوندهای گنجانده‌شده در درخواست گواهی چگونه باید پذیرفته شوند. مقدار این نام یک فهرست جداشده با کاما از موارد all (تمام پسوندهای درخواستی پذیرفته می‌شوند)، name{:[critical|non-critical]} (پسوند نام‌برده پذیرفته می‌شود اما با ویژگی isCritical متفاوت) و -name (همراه با all برای استثنا کردن) است. پسوندهای درخواستی به طور پیش‌فرض پذیرفته نمی‌شوند.

اگر علاوه بر گزینه -ext honored، گزینه -ext نام‌دار یا OID دیگری ارائه شود، این پسوند به پسوندهای پذیرفته‌شده قبلی اضافه می‌شود. اما اگر این نام (یا OID) در مقدار honored نیز ظاهر شود، مقدار و ویژگی بحرانی بودن آن، موارد موجود در درخواست را بازنویسی خواهد کرد.

پسوند subjectKeyIdentifier همیشه ایجاد می‌شود. برای گواهی‌های غیرخودامضاشده، پسوند authorityKeyIdentifier ایجاد می‌گردد.

نکته: کاربران باید آگاه باشند که برخی ترکیبات پسوندها (و سایر فیلدهای گواهی) ممکن است با استانداردهای اینترنت منطبق نباشند. بخش هشدار انطباق گواهی را ببینید.

{-rfc} {-infile infile} {-outfile outfile} {-alias alias} {-sigalg sigalg}
{-dname dname} {-startdate startdate {-ext ext}* {-validity valDays}
[-keypass keypass] {-keystore keystore} [-storepass storepass]
{-storetype storetype} {-providername provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

یک گواهی را در پاسخ به یک فایل درخواست گواهی (که می‌تواند با دستور keytool -certreq ایجاد شود) تولید می‌کند. این دستور درخواست را از infile (در صورت عدم تعیین، از ورودی استاندارد) می‌خواند، آن را با استفاده از کلید خصوصی alias امضا می‌کند، و گواهی X.509 را در outfile (در صورت عدم تعیین، در خروجی استاندارد) صادر می‌نماید. هنگامی که -rfc مشخص شود، فرمت خروجی PEM با کدگذاری Base64 خواهد بود؛ در غیر این صورت یک DER باینری ایجاد می‌شود.

مقدار sigalg الگوریتمی را مشخص می‌کند که باید برای امضای گواهی استفاده شود. آرگومان startdate تاریخ و زمان شروع اعتبار گواهی است. آرگومان valDays تعداد روزهایی را که گواهی باید معتبر در نظر گرفته شود بیان می‌کند.

هنگامی که dname ارائه شود، به عنوان موضوع (subject) گواهی تولیدشده استفاده می‌شود. در غیر این صورت، موضوع موجود در درخواست گواهی استفاده می‌گردد.

مقدار ext نشان می‌دهد که کدام پسوندهای X.509 در گواهی تعبیه خواهند شد. بخش گزینه‌های عمومی را برای ساختار نحوی -ext بخوانید.

گزینه -gencert به شما امکان می‌دهد زنجیره‌های گواهی ایجاد کنید. مثال زیر یک گواهی با نام e1 ایجاد می‌کند که شامل سه گواهی در زنجیره گواهی خود است.

دستورات زیر چهار جفت‌کلید با نام‌های ca، ca1، ca2 و e1 ایجاد می‌کنند:

keytool -alias ca -dname CN=CA -genkeypair
keytool -alias ca1 -dname CN=CA -genkeypair
keytool -alias ca2 -dname CN=CA -genkeypair
keytool -alias e1 -dname CN=E1 -genkeypair

دو دستور زیر یک زنجیره از گواهی‌های امضاشده ایجاد می‌کنند؛ ca گواهی ca1 را امضا می‌کند و ca1 گواهی ca2 را امضا می‌نماید، که همگی خودصادرشده هستند:

keytool -alias ca1 -certreq |
    keytool -alias ca -gencert -ext san=dns:ca1 |
    keytool -alias ca1 -importcert
keytool -alias ca2 -certreq |
    $KT -alias ca1 -gencert -ext san=dns:ca2 |
    $KT -alias ca2 -importcert

دستور زیر گواهی e1 را ایجاد کرده و آن را در فایل e1.cert ذخیره می‌کند که توسط ca2 امضا شده است. در نتیجه، e1 باید حاوی ca، ca1 و ca2 در زنجیره گواهی خود باشد:

keytool -alias e1 -certreq | keytool -alias ca2 -gencert > e1.cert
{-alias alias} {-keyalg keyalg} {-keysize keysize} {-sigalg sigalg}
[-dname dname] [-keypass keypass] {-startdate value} {-ext ext}*
{-validity valDays} {-storetype storetype} {-keystore keystore}
[-storepass storepass]
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

یک جفت‌کلید (یک کلید عمومی و کلید خصوصی مرتبط با آن) تولید می‌کند. کلید عمومی را در یک گواهی خودامضاشده X.509 نسخه ۳ بسته‌بندی کرده که به عنوان یک زنجیره گواهی تک‌عنصری ذخیره می‌شود. این زنجیره گواهی و کلید خصوصی در یک مدخل جدید انبار کلید که با alias شناسایی می‌شود ذخیره می‌گردند.

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

مقدار dname نام متمایز (Distinguished Name) X.500 را مشخص می‌کند تا با مقدار alias مرتبط شود و به عنوان فیلدهای صادرکننده (issuer) و موضوع (subject) در گواهی خودامضاشده استفاده گردد. اگر هیچ نام متمایزی در خط فرمان ارائه نشود، از کاربر خواسته می‌شود آن را وارد کند.

مقدار keypass گذرواژه‌ای است که برای محافظت از کلید خصوصی جفت‌کلید تولیدشده استفاده می‌شود. اگر گذرواژه‌ای ارائه نشود، از کاربر خواسته می‌شود آن را وارد کند. اگر در اعلان کلید بازگشت (Enter) را فشار دهید، گذرواژه کلید بر روی همان گذرواژه انبار کلید تنظیم می‌شود. مقدار keypass باید حداقل ۶ کاراکتر باشد.

مقدار startdate زمان صدور گواهی را مشخص می‌کند که به عنوان مقدار "Not Before" در فیلد اعتبار (Validity) گواهی X.509 نیز شناخته می‌شود.

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

([+-]nnn[ymdHMS])+

[yyyy/mm/dd] [HH:MM:SS]

در شکل اول، زمان صدور به میزان مقدار مشخص‌شده از زمان جاری جابجا می‌شود. مقدار حاصل ترکیب توالی‌ای از زیرمقادیر است. در داخل هر زیرمقدار، علامت مثبت (+) به معنای جابجایی به جلو و علامت منفی (-) به معنای جابجایی به عقب است. زمان جابجایی nnn واحد از سال، ماه، روز، ساعت، دقیقه یا ثانیه است (که به ترتیب با یک نویسه منفرد y، m، d، H، M یا S مشخص می‌شود). مقدار دقیق زمان صدور با استفاده از متد java.util.GregorianCalendar.add(int field, int amount) روی هر زیرمقدار از چپ به راست محاسبه می‌شود. برای مثال، با مشخص کردن، زمان صدور برابر خواهد بود با:

Calendar c = new GregorianCalendar();
c.add(Calendar.YEAR, -1);
c.add(Calendar.MONTH, 1);
c.add(Calendar.DATE, -1);
return c.getTime()

در شکل دوم، کاربر زمان دقیق صدور را در دو بخش تنظیم می‌کند: سال/ماه/روز و ساعت:دقیقه:ثانیه (با استفاده از منطقه زمانی محلی). کاربر می‌تواند فقط یک بخش را ارائه دهد، به این معنی که بخش دیگر همان تاریخ (یا زمان) جاری خواهد بود. کاربر باید تعداد ارقام را دقیقاً مطابق با تعریف فرمت ارائه دهد (در صورت کوتاه‌تر بودن با 0 پر شود). هنگامی که هم تاریخ و هم زمان ارائه می‌شوند، یک (و تنها یک) نویسه فاصله بین دو بخش قرار می‌گیرد. ساعت باید همیشه در قالب ۲۴ ساعته ارائه شود.

هنگامی که این گزینه ارائه نشود، تاریخ شروع همان زمان جاری است. این گزینه حداکثر یک بار می‌تواند ارائه شود.

مقدار valDays تعداد روزهایی را مشخص می‌کند (شروع از تاریخ مشخص‌شده توسط -startdate، یا تاریخ جاری هنگامی که -startdate مشخص نشده است) که گواهی باید معتبر در نظر گرفته شود.

این دستور در نسخه‌های قبلی -genkey نامیده می‌شد. نام قدیمی همچنان در این نسخه پشتیبانی می‌شود. نام جدید، -genkeypair، برای آینده ترجیح داده می‌شود.

{-alias alias} {-keyalg keyalg} {-keysize keysize} [-keypass keypass]
{-storetype storetype} {-keystore keystore} [-storepass storepass]
{-providerClass provider_class_name {-providerArg provider_arg}} {-v}
{-protected} {-Jjavaoption}

یک کلید مخفی (secret key) تولید می‌کند و آن را در یک مدخل جدید KeyStore.SecretKeyEntry که با alias شناسایی می‌شود ذخیره می‌نماید.

مقدار keyalg الگوریتم مورد استفاده برای تولید کلید مخفی را مشخص می‌کند و مقدار keysize اندازه کلید تولیدشده را تعیین می‌نماید. مقدار keypass گذرواژه‌ای است که از کلید مخفی محافظت می‌کند. اگر گذرواژه‌ای ارائه نشود، از کاربر خواسته می‌شود آن را وارد کند. اگر در اعلان کلید Enter را فشار دهید، گذرواژه کلید بر روی همان گذرواژه انبار کلید تنظیم می‌شود. مقدار keypass باید حداقل ۶ کاراکتر باشد.

{-alias alias} {-file cert_file} [-keypass keypass] {-noprompt} {-trustcacerts}
{-storetype storetype} {-keystore keystore} [-storepass storepass]
{-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

گواهی یا زنجیره گواهی (جایی که دومی در یک پاسخ با قالب PKCS#7 یا توالی‌ای از گواهی‌های X.509 ارائه می‌شود) را از فایل cert_file می‌خواند و آن را در مدخل انبار کلید که با alias شناسایی می‌شود ذخیره می‌نماید. اگر هیچ فایلی مشخص نشود، گواهی یا زنجیره گواهی از stdin خوانده می‌شود.

دستور keytool می‌تواند گواهی‌های X.509 نسخه ۱، ۲ و ۳ و زنجیره‌های گواهی با قالب PKCS#7 متشکل از گواهی‌های این نوع را وارد کند. داده‌های وارد شونده باید در قالب کدگذاری باینری یا قالب کدگذاری قابل چاپ (معروف به کدگذاری Base64) همان‌طور که توسط استاندارد RFC 1421 اینترنت تعریف شده است ارائه شوند. در حالت دوم، کدگذاری باید در ابتدا با رشته‌ای که با -----BEGIN شروع می‌شود و در انتها با رشته‌ای که با -----END شروع می‌شود محصور گردد.

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

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

{-alias alias} [-keypass keypass] {-storetype storetype} {-keystore keystore}
[-storepass storepass]
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

یک عبارت عبور را وارد می‌کند و آن را در یک مدخل جدید KeyStore.SecretKeyEntry که با alias شناسایی می‌شود ذخیره می‌نماید. عبارت عبور ممکن است از طریق جریان ورودی استاندارد ارائه شود؛ در غیر این صورت از کاربر خواسته می‌شود آن را وارد کند. مقدار keypass گذرواژه‌ای است که برای محافظت از عبارت عبور واردشده استفاده می‌شود. اگر گذرواژه‌ای ارائه نشود، از کاربر خواسته می‌شود آن را وارد کند. اگر در اعلان کلید Enter را فشار دهید، گذرواژه کلید بر روی همان گذرواژه انبار کلید تنظیم می‌شود. مقدار keypass باید حداقل ۶ کاراکتر باشد.

{-srcstoretype srcstoretype} {-deststoretype deststoretype}
[-srcstorepass srcstorepass] [-deststorepass deststorepass] {-srcprotected}
{-destprotected} 
{-srcalias srcalias {-destalias destalias} [-srckeypass srckeypass]} 
[-destkeypass destkeypass] {-noprompt}
{-srcProviderName src_provider_name} {-destProviderName dest_provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}} {-v}
{-protected} {-Jjavaoption}

یک مدخل منفرد یا تمامی مدخل‌ها را از یک انبار کلید مبدأ به یک انبار کلید مقصد وارد می‌کند.

هنگامی که گزینه -srcalias ارائه شود، دستور مدخل منفرد شناسایی‌شده توسط نام مستعار را به انبار کلید مقصد وارد می‌کند. اگر نام مستعار مقصد همراه با destalias ارائه نشود، از srcalias به عنوان نام مستعار مقصد استفاده می‌شود. اگر مدخل مبدأ با یک گذرواژه محافظت شده باشد، از srckeypass برای بازیابی مدخل استفاده می‌شود. اگر srckeypass ارائه نشود، دستور keytool تلاش می‌کند از srcstorepass برای بازیابی مدخل استفاده کند. اگر srcstorepass یا ارائه نشده باشد یا نادرست باشد، از کاربر برای گذرواژه سوال می‌شود. مدخل مقصد با destkeypass محافظت می‌شود. اگر destkeypass ارائه نشود، مدخل مقصد با گذرواژه مدخل مبدأ محافظت می‌گردد. برای نمونه، اکثر ابزارهای شخص ثالث نیازمند این هستند که storepass و keypass در یک انبار کلید PKCS #12 یکسان باشند. برای ایجاد یک انبار کلید PKCS #12 برای این ابزارها، همیشه مقدار -destkeypass را برابر با -deststorepass مشخص کنید.

اگر گزینه -srcalias ارائه نشود، تمام مدخل‌های موجود در انبار کلید مبدأ به انبار کلید مقصد وارد می‌شوند. هر مدخل مقصد تحت همان نام مستعار مدخل مبدأ ذخیره می‌شود. اگر مدخل مبدأ با گذرواژه محافظت شده باشد، از srcstorepass برای بازیابی مدخل استفاده می‌شود. اگر srcstorepass ارائه نشده یا نادرست باشد، از کاربر برای گذرواژه سوال می‌شود. اگر نوع یک مدخل در انبار کلید مبدأ در انبار کلید مقصد پشتیبانی نشود، یا در صورت وقوع خطا هنگام ذخیره یک مدخل در انبار کلید مقصد، از کاربر پرسیده می‌شود که آیا آن مدخل نادیده گرفته شده و ادامه یابد یا عملیات متوقف شود. مدخل مقصد با گذرواژه مدخل مبدأ محافظت می‌گردد.

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

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

{-file file}

محتوای یک درخواست گواهی با قالب PKCS #10 را چاپ می‌کند، که می‌تواند توسط دستور keytool -certreq تولید شده باشد. این دستور درخواست را از فایل می‌خواند. اگر فایلی وجود نداشته باشد، درخواست از ورودی استاندارد خوانده می‌شود.

{-alias alias} {-dname dname} {-sigalg sigalg} {-file certreq_file}
[-keypass keypass] {-storetype storetype} {-keystore keystore}
[-storepass storepass] {-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

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

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

کلید خصوصی مرتبط با alias برای ایجاد درخواست گواهی PKCS #10 استفاده می‌شود. برای دسترسی به کلید خصوصی، باید گذرواژه صحیح ارائه شود. اگر keypass در خط فرمان ارائه نشده باشد و با گذرواژه مورد استفاده برای محافظت از یکپارچگی انبار کلید متفاوت باشد، از کاربر برای آن سوال می‌شود. اگر dname ارائه شود، به عنوان موضوع (subject) در CSR استفاده می‌شود. در غیر این صورت، نام متمایز X.500 مرتبط با alias استفاده می‌گردد.

مقدار sigalg الگوریتمی را مشخص می‌کند که باید برای امضای CSR استفاده شود.

درخواست CSR در فایل certreq_file ذخیره می‌شود. اگر هیچ فایلی مشخص نشود، CSR به stdout ارسال می‌گردد.

از دستور importcert برای وارد کردن پاسخ دریافت‌شده از CA استفاده کنید.

{-alias alias} {-file cert_file} {-storetype storetype} {-keystore keystore}
[-storepass storepass] {-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-rfc} {-v} {-protected} {-Jjavaoption}

گواهی مرتبط با alias را از انبار کلید می‌خواند و آن را در فایل cert_file ذخیره می‌کند. هنگامی که هیچ فایلی مشخص نشود، گواهی در stdout چاپ می‌شود.

گواهی به طور پیش‌فرض با کدگذاری باینری صادر می‌شود. اگر گزینه -rfc مشخص شود، خروجی در قالب کدگذاری قابل چاپ تعریف‌شده توسط استاندارد کدگذاری گواهی RFC 1421 اینترنت خواهد بود.

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

این دستور در نسخه‌های قبلی -export نامیده می‌شد. نام قدیمی همچنان در این نسخه پشتیبانی می‌شود. نام جدید، -exportcert، برای آینده ترجیح داده می‌شود.

{-alias alias} {-storetype storetype} {-keystore keystore} [-storepass storepass]
{-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v | -rfc} {-protected} {-Jjavaoption}

محتویات مدخل انبار کلید شناسایی‌شده توسط alias را در stdout چاپ می‌کند. اگر هیچ alias مشخص نشود، محتویات کل انبار کلید چاپ می‌شود.

این دستور به طور پیش‌فرض اثر انگشت SHA1 یک گواهی را چاپ می‌کند. اگر گزینه -v مشخص شود، گواهی در قالبی خوانا برای انسان، همراه با اطلاعات اضافی مانند مالک، صادرکننده، شماره سریال و هرگونه پسوند چاپ می‌شود. اگر گزینه -rfc مشخص شود، محتویات گواهی با استفاده از قالب کدگذاری قابل چاپ طبق استاندارد RFC 1421 اینترنت چاپ می‌شود.

نمی‌توانید هر دو گزینه -v و -rfc را همزمان مشخص کنید.

{-file cert_file | -sslserver host[:port]} {-jarfile JAR_file {-rfc} {-v}
{-Jjavaoption}

گواهی را از فایل cert_file، سرور SSL واقع در host:port، یا فایل JAR امضاشده JAR_file (با گزینه -jarfile) می‌خواند و محتویات آن را در قالبی خوانا برای انسان چاپ می‌کند. هنگامی که هیچ پورتی مشخص نشود، پورت استاندارد HTTPS یعنی 443 فرض می‌شود. توجه داشته باشید که گزینه‌های -sslserver و -file نمی‌توانند همزمان ارائه شوند، در غیر این صورت خطا گزارش می‌شود. اگر هیچ‌یک از دو گزینه مشخص نشوند، گواهی از stdin خوانده می‌شود.

هنگامی که -rfc مشخص شود، دستور keytool گواهی را در حالت PEM طبق استاندارد RFC 1421 اینترنت چاپ می‌کند. استاندارد کدگذاری گواهی RFC 1421 اینترنت را ببینید.

اگر گواهی از یک فایل یا stdin خوانده شود، ممکن است با کدگذاری باینری یا قالب کدگذاری قابل چاپ طبق استاندارد RFC 1421 باشد.

اگر سرور SSL پشت یک دیوار آتش (فایروال) باشد، می‌توان گزینه‌های -J-Dhttps.proxyHost=proxyhost و -J-Dhttps.proxyPort=proxyport را برای تونل‌پراکسی در خط فرمان مشخص کرد. راهنمای مرجع افزونه سوکت امن جاوا (JSSE) را در نشانی زیر ببینید: http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html

نکته: این گزینه می‌تواند مستقل از انبار کلید استفاده شود.

-file crl_ {-v}

فهرست ابطال گواهی (CRL) را از فایل crl_ می‌خواند. یک CRL فهرستی از گواهی‌های دیجیتال است که توسط مرجع صادرکننده آن‌ها باطل شده‌اند. مرجع صدور گواهی فایل crl_ را تولید می‌کند.

نکته: این گزینه می‌تواند مستقل از انبار کلید استفاده شود.

[-new new_storepass] {-storetype storetype} {-keystore keystore}
[-storepass storepass] {-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-Jjavaoption}

گذرواژه مورد استفاده برای محافظت از یکپارچگی محتویات انبار کلید را تغییر می‌دهد. گذرواژه جدید new_storepass است که باید حداقل ۶ کاراکتر باشد.

{-alias alias} [-keypass old_keypass] [-new new_keypass] {-storetype storetype}
{-keystore keystore} [-storepass storepass] {-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}} {-v}
{-Jjavaoption}

گذرواژه‌ای را که کلید خصوصی/مخفی شناسایی‌شده توسط alias تحت آن محافظت می‌شود، از old_keypass به new_keypass تغییر می‌دهد، که باید حداقل ۶ کاراکتر باشد.

اگر گزینه -keypass در خط فرمان ارائه نشده باشد و گذرواژه کلید با گذرواژه انبار کلید متفاوت باشد، از کاربر برای آن سوال می‌شود.

اگر گزینه -new در خط فرمان ارائه نشود، از کاربر برای آن سوال می‌شود.

[-alias alias] {-storetype storetype} {-keystore keystore} [-storepass storepass]
{-providerName provider_name}  
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

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

{-alias alias} [-destalias destalias] [-keypass keypass] {-storetype storetype}
{-keystore keystore} [-storepass storepass] {-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}} {-v}
{-protected} {-Jjavaoption}

یک مدخل موجود انبار کلید را از alias مشخص‌شده به یک نام مستعار جدید، destalias منتقل می‌کند. اگر هیچ نام مستعار مقصدی ارائه نشود، دستور از کاربر برای آن سوال می‌کند. اگر مدخل اصلی با گذرواژه مدخل محافظت شده باشد، گذرواژه می‌تواند با گزینه -keypass ارائه شود. اگر هیچ گذرواژه کلیدی ارائه نشود، ابتدا storepass (در صورت ارائه) امتحان می‌شود. اگر ناموفق باشد، از کاربر برای گذرواژه سوال می‌شود.


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

برای اطلاعات بیشتر در مورد یک دستور خاص، دستور زیر را وارد کنید که در آن command_name نام دستور است: keytool -command_name -help.

این مثال توالی مراحل ایجاد یک انبار کلید را برای مدیریت جفت‌کلیدهای عمومی/خصوصی و گواهی‌های دریافت شده از هویت‌های مورد اعتماد شرح می‌دهد.

ابتدا یک انبار کلید ایجاد کرده و جفت‌کلید را تولید کنید. می‌توانید دستوری مانند زیر را به صورت یک خط واحد وارد نمایید:

keytool -genkeypair -dname "cn=Mark Jones, ou=Java, o=Oracle, c=US"
    -alias business -keypass <new password for private key>
    -keystore /working/mykeystore
    -storepass <new password for keystore> -validity 180

این دستور انبار کلیدی به نام mykeystore در دایرکتوری کاری ایجاد می‌کند (با این فرض که از قبل وجود نداشته باشد) و گذرواژه مشخص‌شده توسط <new password for keystore> را به آن اختصاص می‌دهد. این دستور یک جفت‌کلید عمومی/خصوصی برای هویتی تولید می‌کند که نام متمایز آن دارای نام عمومی Mark Jones، واحد سازمانی Java، سازمان Oracle و کد کشور دوحرفی US است. این دستور از الگوریتم پیش‌فرض تولید کلید DSA برای ایجاد کلیدها استفاده می‌کند؛ هر دو کلید ۱۰۲۴ بیت هستند.

دستور از الگوریتم امضای پیش‌فرض SHA1withDSA برای ایجاد یک گواهی خودامضاشده استفاده می‌کند که شامل کلید عمومی و اطلاعات نام متمایز است. گواهی برای مدت ۱۸۰ روز معتبر است و با کلید خصوصی در یک مدخل انبار کلید که با نام مستعار business ارجاع داده می‌شود مرتبط می‌گردد. به کلید خصوصی گذرواژه مشخص‌شده با <new password for private key> اختصاص داده می‌شود.

در صورت پذیرش مقادیر پیش‌فرض گزینه‌ها، دستور به طور چشمگیری کوتاه‌تر خواهد بود. در این حالت هیچ گزینه‌ای الزامی نیست و برای گزینه‌های مشخص‌نشده‌ای که مقدار پیش‌فرض دارند، از مقادیر پیش‌فرض استفاده می‌شود. برای مقادیر الزامی از شما سوال خواهد شد. می‌توانید دستور زیر را وارد کنید:

keytool -genkeypair

در این حالت، یک مدخل انبار کلید با نام مستعار mykey ایجاد می‌شود، به همراه یک جفت‌کلید تازه تولیدشده و گواهی‌ای که برای ۹۰ روز معتبر است. این مدخل در انبار کلیدی به نام .keystore در دایرکتوری خانگی شما قرار می‌گیرد. فایل انبار کلید در صورت عدم وجود ایجاد می‌شود. اطلاعات نام متمایز، گذرواژه انبار کلید و گذرواژه کلید خصوصی از شما درخواست خواهد شد.

سایر مثال‌ها فرض می‌کنند که شما دستور -genkeypair را بدون گزینه‌های مشخص اجرا کرده‌اید و به اعلان‌ها با مقادیری برابر با مقادیر مشخص‌شده در اولین دستور -genkeypair پاسخ داده‌اید (برای نمونه، نام متمایز cn=Mark Jones, ou=Java, o=Oracle, c=US).

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

keytool -certreq -file MarkJ.csr

این دستور یک CSR برای هویت شناسایی‌شده توسط نام مستعار پیش‌فرض mykey ایجاد می‌کند و درخواست را در فایلی به نام MarkJ.csr قرار می‌دهد. این فایل را به یک CA، مانند VeriSign ارسال کنید. مرجع CA شما (درخواست‌کننده) را معمولاً به صورت آفلاین احراز هویت کرده و یک گواهی امضاشده توسط خود بازمی‌گرداند که کلید عمومی شما را تأیید اعتبار می‌کند. در برخی موارد، CA زنجیره‌ای از گواهی‌ها را بازمی‌گرداند که هر یک کلید عمومی امضاکننده گواهی قبلی در زنجیره را تأیید می‌کنند.

اکنون باید گواهی خودامضاشده را با یک زنجیره گواهی جایگزین کنید، که در آن هر گواهی در زنجیره، کلید عمومی امضاکننده گواهی قبلی را تا یک مرجع ریشه CA تأیید می‌کند.

پیش از آنکه پاسخ گواهی را از یک CA وارد کنید، به یک یا چند گواهی مورد اعتماد در انبار کلید خود یا در فایل انبار کلید cacerts نیاز دارید. بخش -importcert در دستورات را ببینید.

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

فایل انبار کلید cacerts با چندین گواهی ریشه CA متعلق به VeriSign ارائه می‌شود، بنابراین احتمالاً نیازی به وارد کردن گواهی VeriSign به عنوان یک گواهی مورد اعتماد در انبار کلید خود نخواهید داشت. اما اگر از یک CA متفاوت درخواست گواهی امضاشده کنید، و گواهی تأییدکننده کلید عمومی آن CA به cacerts اضافه نشده باشد، باید گواهی آن CA را به عنوان یک گواهی مورد اعتماد وارد نمایید.

گواهی یک CA معمولاً یا خودامضاشده است یا توسط یک CA دیگر امضا شده است که در این صورت به گواهی تأییدکننده کلید عمومی آن CA نیاز دارید. فرض کنید شرکت ABC, Inc. یک مرجع CA است و شما فایلی به نام ABCCA.cer دریافت کرده‌اید که قرار است یک گواهی خودامضاشده از ABC باشد و کلید عمومی آن CA را تأیید کند. دقت کنید که پیش از وارد کردن آن به عنوان یک گواهی مورد اعتماد، از معتبر بودن آن اطمینان حاصل نمایید. ابتدا آن را با دستور keytool -printcert یا دستور keytool -importcert بدون گزینه -noprompt مشاهده کنید و مطمئن شوید اثر انگشت‌های نمایش داده شده گواهی با موارد مورد انتظار مطابقت دارند. می‌توانید با فرد ارسال‌کننده گواهی تماس بگیرید و اثر انگشت‌های مشاهده‌شده را با مواردی که آن‌ها ارائه می‌دهند یا در یک مخزن امن کلید عمومی وجود دارد مقایسه کنید. تنها زمانی که اثر انگشت‌ها یکسان باشند تضمین می‌شود که گواهی در حین انتقال با گواهی شخص دیگری (مثلاً یک مهاجم) جایگزین نشده است. اگر چنین حمله‌ای رخ دهد و شما گواهی را پیش از وارد کردن بررسی نکرده باشید، به هر چیزی که مهاجم امضا کرده باشد اعتماد خواهید کرد.

اگر اطمینان دارید که گواهی معتبر است، می‌توانید آن را با دستور زیر به انبار کلید خود اضافه کنید:

keytool -importcert -alias abc -file ABCCA.cer

این دستور یک مدخل گواهی مورد اعتماد در انبار کلید با استفاده از داده‌های فایل ABCCA.cer ایجاد می‌کند و نام مستعار abc را به آن مدخل اختصاص می‌دهد.

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

برای نمونه، اگر درخواست امضای گواهی خود را به VeriSign ارسال کرده‌اید، می‌توانید پاسخ را با دستور زیر وارد کنید که فرض می‌کند گواهی بازگردانده‌شده VSMarkJ.cer نام دارد:

keytool -importcert -trustcacerts -file VSMarkJ.cer

اگر از دستور jarsigner برای امضای یک فایل آرشیو جاوا (JAR) استفاده کرده‌اید، کلاینت‌هایی که می‌خواهند از این فایل استفاده کنند مایل به تأیید امضای شما خواهند بود. یک روش برای کلاینت‌ها جهت احراز هویت شما این است که ابتدا گواهی کلید عمومی شما را به عنوان یک مدخل مورد اعتماد در انبار کلید خود وارد کنند.

می‌توانید گواهی را صادر کرده و در اختیار کلاینت‌های خود قرار دهید. به عنوان نمونه، می‌توانید گواهی خود را با دستور زیر در فایلی به نام MJ.cer کپی کنید که فرض می‌کند مدخل دارای نام مستعار mykey است:

keytool -exportcert -alias mykey -file MJ.cer

با داشتن گواهی و فایل JAR امضاشده، یک کلاینت می‌تواند از دستور jarsigner برای تأیید امضای شما استفاده کند.

دستور importkeystore برای وارد کردن یک انبار کلید کامل به یک انبار کلید دیگر استفاده می‌شود، به این معنی که تمام مدخل‌های انبار کلید مبدأ شامل کلیدها و گواهی‌ها با یک دستور واحد به انبار کلید مقصد وارد می‌شوند. می‌توانید از این دستور برای وارد کردن مدخل‌ها از نوع متفاوتی از انبار کلید استفاده کنید. در طول فرآیند وارد کردن، تمام مدخل‌های جدید در انبار کلید مقصد دارای نام‌های مستعار و گذرواژه‌های حفاظتی یکسان (برای کلیدهای مخفی و کلیدهای خصوصی) خواهند بود. اگر دستور keytool نتواند کلیدهای خصوصی یا کلیدهای مخفی را از انبار کلید مبدأ بازیابی کند، گذرواژه را از شما درخواست می‌نماید. اگر نام مستعار تکراری شناسایی کند، نام مستعار جدیدی از شما می‌خواهد و می‌توانید نام مستعار جدیدی مشخص کنید یا به دستور keytool اجازه دهید روی مدخل موجود بازنویسی کند.

برای نمونه، جهت وارد کردن مدخل‌ها از یک انبار کلید معمولی نوع JKS به نام key.jks به یک انبار کلید مبتنی بر سخت‌افزار از نوع PKCS #11، از دستور زیر استفاده کنید:

keytool -importkeystore
    -srckeystore key.jks -destkeystore NONE
    -srcstoretype JKS -deststoretype PKCS11
    -srcstorepass <src keystore password>
    -deststorepass <destination keystore pwd>

دستور importkeystore همچنین می‌تواند برای وارد کردن یک مدخل منفرد از یک انبار کلید مبدأ به انبار کلید مقصد استفاده شود. در این حالت، علاوه بر گزینه‌های مثال قبل، باید نام مستعاری را که می‌خواهید وارد کنید مشخص نمایید. با مشخص کردن گزینه -srcalias، می‌توانید نام مستعار مقصد را نیز در خط فرمان مشخص کنید، همچنین گذرواژه حفاظتی برای یک کلید مخفی/خصوصی و گذرواژه حفاظتی مقصد مورد نظر خود را تعیین نمایید. دستور زیر این موضوع را نشان می‌دهد:

keytool -importkeystore
    -srckeystore key.jks -destkeystore NONE
    -srcstoretype JKS -deststoretype PKCS11
    -srcstorepass <src keystore password>
    -deststorepass <destination keystore pwd>
    -srcalias myprivatekey -destalias myoldprivatekey
    -srckeypass <source entry password>
    -destkeypass <destination entry password>
    -noprompt

دستورات زیر دستورات keytool برای تولید جفت‌کلیدها و گواهی‌ها برای سه هویت هستند: ریشه CA (root)، مرجع CA واسط (ca)، و سرور SSL (server). اطمینان حاصل کنید که تمام گواهی‌ها را در یک انبار کلید ذخیره می‌کنید. در این مثال‌ها، RSA الگوریتم کلید توصیه‌شده است.

keytool -genkeypair -keystore root.jks -alias root -ext bc:c
keytool -genkeypair -keystore ca.jks -alias ca -ext bc:c
keytool -genkeypair -keystore server.jks -alias server
keytool -keystore root.jks -alias root -exportcert -rfc > root.pem
keytool -storepass <storepass> -keystore ca.jks -certreq -alias ca |
    keytool -storepass <storepass> -keystore root.jks
    -gencert -alias root -ext BC=0 -rfc > ca.pem
keytool -keystore ca.jks -importcert -alias ca -file ca.pem
keytool -storepass <storepass> -keystore server.jks -certreq -alias server |
    keytool -storepass <storepass> -keystore ca.jks -gencert -alias ca
    -ext ku:c=dig,kE -rfc > server.pem
cat root.pem ca.pem server.pem |
    keytool -keystore server.jks -importcert -alias server

انبار کلید (Keystore)
یک انبار کلید مکانی برای ذخیره‌سازی کلیدهای رمزنگاری و گواهی‌ها است.
مدخل‌های انبار کلید (Keystore entries)
انبارهای کلید می‌توانند انواع متفاوتی از مدخل‌ها را در خود جای دهند. دو نوع مدخل پرکاربرد برای دستور keytool شامل موارد زیر است:

مدخل‌های کلید (Key entries): هر مدخل حاوی اطلاعات بسیار حساس کلیدهای رمزنگاری است که در یک قالب محافظت‌شده برای جلوگیری از دسترسی‌های غیرمجاز ذخیره می‌شود. معمولاً کلیدی که در این نوع مدخل ذخیره می‌شود یک کلید مخفی است، یا یک کلید خصوصی به همراه زنجیره گواهی برای کلید عمومی متناظر. بخش زنجیره‌های گواهی را ببینید. دستور keytool می‌تواند هر دو نوع مدخل را مدیریت کند، در حالی که ابزار jarsigner تنها نوع دوم یعنی کلیدهای خصوصی و زنجیره گواهی مرتبط با آن‌ها را مدیریت می‌نماید.

مدخل‌های گواهی مورد اعتماد (Trusted certificate entries): هر مدخل شامل یک گواهی کلید عمومی منفرد متعلق به یک طرف دیگر است. این مدخل گواهی مورد اعتماد نامیده می‌شود زیرا مالک انبار کلید اطمینان دارد که کلید عمومی موجود در گواهی متعلق به همان هویتی است که با موضوع (مالک) گواهی مشخص شده است. صادرکننده گواهی با امضای دیجیتال گواهی این موضوع را تضمین می‌کند.

نام‌های مستعار انبار کلید (KeyStore aliases)
تمام مدخل‌های انبار کلید (مدخل‌های کلید و گواهی‌های مورد اعتماد) از طریق نام‌های مستعار (alias) منحصربه‌فرد در دسترس قرار می‌گیرند.

یک نام مستعار زمانی مشخص می‌شود که شما هویتی را با دستور -genseckey برای تولید کلید مخفی، دستور -genkeypair برای تولید جفت‌کلید (کلید عمومی و خصوصی) یا دستور -importcert برای افزودن گواهی یا زنجیره گواهی به فهرست گواهی‌های مورد اعتماد به انبار کلید اضافه می‌کنید. دستورات بعدی keytool باید از همین نام مستعار برای ارجاع به آن هویت استفاده کنند.

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

keytool -genkeypair -alias duke -keypass dukekeypasswd

این مثال یک گذرواژه اولیه dukekeypasswd را تعیین می‌کند که دستورات بعدی برای دسترسی به کلید خصوصی مرتبط با نام مستعار duke به آن نیاز خواهند داشت. اگر بعداً بخواهید گذرواژه کلید خصوصی Duke را تغییر دهید، از دستوری مانند زیر استفاده کنید:

keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass

این دستور گذرواژه را از dukekeypasswd به newpass تغییر می‌دهد. گذرواژه نباید در خط فرمان یا اسکریپت‌ها مشخص شود مگر اینکه برای اهداف آزمایشی باشد یا روی یک سیستم امن قرار داشته باشید. اگر یک گزینه گذرواژه الزامی را در خط فرمان مشخص نکنید، از شما درخواست خواهد شد.

پیاده‌سازی انبار کلید (KeyStore implementation)
کلاس KeyStore موجود در بسته java.security رابط‌های مشخصی برای دسترسی و اصلاح اطلاعات موجود در انبار کلید فراهم می‌کند. امکان وجود چندین پیاده‌سازی عینی متفاوت وجود دارد که هر پیاده‌سازی مربوط به نوع خاصی از انبار کلید است.

در حال حاضر دو ابزار خط فرمان (keytool و jarsigner) و یک ابزار گرافیکی به نام Policy Tool از پیاده‌سازی‌های انبار کلید استفاده می‌کنند. از آنجا که کلاس KeyStore عمومی (public) است، کاربران می‌توانند برنامه‌های امنیتی دیگری بنویسند که از آن استفاده کنند.

یک پیاده‌سازی پیش‌فرض توکار وجود دارد که توسط Oracle ارائه شده است. این پیاده‌سازی انبار کلید را به صورت یک فایل با نوع (قالب) اختصاصی به نام JKS پیاده‌سازی می‌کند. این فرمت از هر کلید خصوصی با گذرواژه اختصاصی آن محافظت کرده و همچنین یکپارچگی کل انبار کلید را با یک گذرواژه (احتمالاً متفاوت) محافظت می‌نماید.

پیاده‌سازی‌های انبار کلید مبتنی بر ارائه‌دهنده (Provider) هستند. به طور دقیق‌تر، رابط‌های برنامه‌نویسی ارائه‌شده توسط KeyStore بر اساس رابط ارائه‌دهنده خدمات (SPI) پیاده‌سازی شده‌اند. یعنی یک کلاس انتزاعی متناظر KeystoreSpi در بسته java.security وجود دارد که متدهای SPI را که ارائه‌دهندگان باید پیاده‌سازی کنند تعریف می‌کند. اصطلاح ارائه‌دهنده به یک بسته یا مجموعه‌ای از بسته‌ها اشاره دارد که پیاده‌سازی عینی زیرمجموعه‌ای از سرویس‌های قابل دسترس توسط API امنیت جاوا را فراهم می‌کنند. برای ارائه یک پیاده‌سازی انبار کلید، کلاینت‌ها باید یک ارائه‌دهنده پیاده‌سازی کرده و زیرکلاسی از KeystoreSpi ارائه دهند، همان‌طور که در راهنمای نحوه پیاده‌سازی ارائه‌دهنده در معماری رمزنگاری جاوا شرح داده شده است: http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/HowToImplAProvider.html

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

دستور keytool روی هر پیاده‌سازی انبار کلید مبتنی بر فایل کار می‌کند. این دستور مسیر انبار کلید را که در خط فرمان به آن ارسال شده به عنوان نام فایل در نظر گرفته و آن را به یک FileInputStream تبدیل می‌کند تا اطلاعات انبار کلید را بارگیری کند. دستورات jarsigner و policytool می‌توانند یک انبار کلید را از هر مکانی که با یک نشانی URL مشخص شود بخوانند.

برای keytool و jarsigner، می‌توانید نوع انبار کلید را در خط فرمان با گزینه -storetype مشخص کنید. برای Policy Tool، می‌توانید نوع انبار کلید را با منوی Keystore مشخص نمایید.

اگر نوع انبار کلید را صراحتاً تعیین نکنید، این ابزارها پیاده‌سازی انبار کلید را بر اساس مقدار مشخصه keystore.type تعریف‌شده در فایل مشخصه‌های امنیتی انتخاب می‌کنند. فایل مشخصه‌های امنیتی java.security نام دارد و در دایرکتوری مشخصه‌های امنیتی قرار دارد: java.home\lib\security در ویندوز و java.home/lib/security در Oracle Solaris، که در آن java.home دایرکتوری محیط زمان اجرا است (دایرکتوری jre در SDK یا دایرکتوری سطح بالای JRE).

هر ابزار مقدار keystore.type را دریافت کرده و سپس تمام ارائه‌دهندگان نصب‌شده فعلی را بررسی می‌کند تا ارائه‌دهنده‌ای را بیابد که انبار کلیدی از آن نوع را پیاده‌سازی کرده باشد. سپس از پیاده‌سازی آن ارائه‌دهنده استفاده می‌کند. کلاس KeyStore یک متد ایستا به نام getDefaultType تعریف می‌کند که به برنامه‌ها اجازه می‌دهد مقدار مشخصه keystore.type را بازیابی نمایند. خط کد زیر یک نمونه از نوع انبار کلید پیش‌فرض را همان‌طور که در مشخصه keystore.type تعیین شده ایجاد می‌کند:

KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());

نوع انبار کلید پیش‌فرض jks است که نوع اختصاصی پیاده‌سازی انبار کلید ارائه‌شده توسط Oracle است. این مورد با خط زیر در فایل مشخصه‌های امنیتی مشخص شده است:

keystore.type=jks

برای اینکه ابزارها از یک پیاده‌سازی انبار کلید غیر از پیش‌فرض استفاده کنند، می‌توانید آن خط را برای مشخص کردن نوع انبار کلید متفاوت ویرایش کنید. برای نمونه، اگر بسته ارائه‌دهنده‌ای دارید که یک پیاده‌سازی انبار کلید برای نوعی به نام pkcs12 ارائه می‌دهد، آن خط را به صورت زیر تغییر دهید:

keystore.type=pkcs12

نکته: بزرگی و کوچکی حروف در نام‌گذاری نوع انبار کلید تفاوتی ندارد. برای مثال JKS همانند jks در نظر گرفته می‌شود.

گواهی (Certificate)
یک گواهی (یا گواهی کلید عمومی) بیانیه‌ای با امضای دیجیتال از سوی یک هویت (صادرکننده یا issuer) است که بیان می‌کند کلید عمومی و برخی اطلاعات دیگر هویتی دیگر (موضوع یا subject) دارای مقداری مشخص است. اصطلاحات زیر با گواهی‌ها مرتبط هستند:

کلیدهای عمومی (Public Keys): اعدادی هستند که با یک هویت خاص مرتبط بوده و برای آگاهی تمام کسانی که نیاز به تعاملات مطمئن با آن هویت دارند در نظر گرفته شده‌اند. کلیدهای عمومی برای بررسی و اعتبارسنجی امضاها استفاده می‌شوند.

امضاشده دیجیتالی (Digitally Signed): اگر داده‌هایی به صورت دیجیتالی امضا شوند، همراه با هویت صادرکننده و امضایی ذخیره می‌شوند که اثبات می‌کند آن هویت از داده‌ها آگاهی دارد. داده‌ها با امضا شدن توسط کلید خصوصی هویت، غیرقابل جعل می‌شوند.

هویت (Identity): روشی شناخته‌شده برای نشانی‌دهی یک هویت. در برخی سیستم‌ها هویت همان کلید عمومی است و در برخی دیگر می‌تواند از UID سیستم‌عامل تا آدرس ایمیل یا نام متمایز X.509 متغیر باشد.

امضا (Signature): یک امضا روی داده‌ها با استفاده از کلید خصوصی یک هویت محاسبه می‌شود. امضاکننده در مورد گواهی‌ها با عنوان صادرکننده (Issuer) نیز شناخته می‌شود.

کلیدهای خصوصی (Private Keys): اعدادی هستند که باید تنها برای همان هویتی که کلید خصوصی به آن تعلق دارد شناخته‌شده باشند (یعنی محرمانه نگهداری شوند). کلیدهای خصوصی و عمومی در تمام سیستم‌های رمزنگاری کلید عمومی به صورت جفت وجود دارند. در یک سیستم معمولی رمزنگاری کلید عمومی مانند DSA، هر کلید خصوصی دقیقاً با یک کلید عمومی متناظر است. کلیدهای خصوصی برای محاسبه امضاها استفاده می‌شوند.

موجودیت / هویت (Entity): یک هویت می‌تواند شخص، سازمان، برنامه، رایانه، کسب‌وکار، بانک یا هر چیزی باشد که تا حدی به آن اعتماد دارید.

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

همچنین می‌توانید مرجع صدور گواهی اختصاصی خود را با استفاده از محصولاتی مانند Microsoft Certificate Server یا محصول Entrust CA برای سازمان خود راه‌اندازی کنید. با دستور keytool امکان نمایش، وارد کردن و صدور گواهی‌ها وجود دارد. همچنین امکان تولید گواهی‌های خودامضاشده نیز فراهم است.

دستور keytool در حال حاضر گواهی‌های X.509 را مدیریت می‌کند.

گواهی‌های X.509 (X.509 Certificates)
استاندارد X.509 اطلاعاتی را که می‌توانند درون یک گواهی قرار گیرند تعریف کرده و نحوه نگارش آن را (قالب داده) شرح می‌دهد. تمام داده‌های یک گواهی با دو استاندارد مرتبط به نام‌های ASN.1/DER کدگذاری می‌شوند. استاندارد نحوی انتزاعی ۱ (ASN.1) داده‌ها را توصیف می‌کند و قواعد کدگذاری معین (DER) روش واحدی را برای ذخیره و انتقال آن داده‌ها شرح می‌دهد.

تمام گواهی‌های X.509 علاوه بر امضا، دارای داده‌های زیر هستند:

نسخه (Version): مشخص می‌کند کدام نسخه از استاندارد X.509 بر این گواهی حاکم است که بر اطلاعات قابل تعیین در آن تأثیر می‌گذارد. تاکنون سه نسخه تعریف شده است. دستور keytool می‌تواند گواهی‌های نسخه ۱، ۲ و ۳ را وارد و صادر کند و گواهی‌های نسخه ۳ را تولید می‌نماید.

نسخه ۱ استاندارد X.509 از سال ۱۹۸۸ در دسترس بوده، به طور گسترده پیاده‌سازی شده و عمومی‌ترین نسخه است.

نسخه ۲ استاندارد X.509 مفهوم شناسه‌های منحصربه‌فرد موضوع و صادرکننده را برای مدیریت احتمال استفاده مجدد از نام‌های موضوع یا صادرکننده در طول زمان معرفی کرد. اکثر اسناد مشخصات گواهی اکیداً توصیه می‌کنند که نام‌ها مجدداً استفاده نشوند و گواهی‌ها از شناسه‌های منحصربه‌فرد استفاده نکنند. گواهی‌های نسخه ۲ کاربرد گسترده‌ای ندارند.

نسخه ۳ استاندارد X.509 جدیدترین نسخه (۱۹۹۶) است و از مفهوم پسوندها (Extensions) پشتیبانی می‌کند که در آن هر کسی می‌تواند یک پسوند تعریف کرده و آن را در گواهی قرار دهد. برخی از پسوندهای متداول عبارتند از: KeyUsage (محدود کردن استفاده از کلیدها به اهداف خاص مانند signing-only) و AlternativeNames (امکان ارتباط هویت‌های دیگر مانند نام‌های DNS، آدرس‌های ایمیل، آدرس‌های IP با این کلید عمومی). پسوندها می‌توانند به عنوان بحرانی (Critical) علامت‌گذاری شوند تا نشان دهند که پسوند باید حتماً بررسی شده و اعمال گردد. برای مثال، اگر گواهی دارای پسوند KeyUsage به صورت بحرانی و با مقدار keyCertSign باشد، هنگامی که این گواهی در طول ارتباطات SSL ارائه شود باید رد شود، زیرا پسوند گواهی نشان می‌دهد که کلید خصوصی مرتبط تنها باید برای امضای گواهی‌ها استفاده شود و نه برای SSL.

شماره سریال (Serial number): هویتی که گواهی را ایجاد کرده موظف است شماره سریالی به آن اختصاص دهد تا آن را از سایر گواهی‌های صادرشده متمایز کند. این اطلاعات در موارد متعددی استفاده می‌شود؛ برای مثال، هنگامی که گواهی باطل می‌شود، شماره سریال آن در فهرست ابطال گواهی (CRL) قرار می‌گیرد.

شناسه الگوریتم امضا (Signature algorithm identifier): الگوریتم مورد استفاده توسط مرجع CA برای امضای گواهی را مشخص می‌کند.

نام صادرکننده (Issuer name): نام متمایز X.500 هویتی که گواهی را امضا کرده است. بخش نام‌های متمایز X.500 را ببینید. این هویت معمولاً یک مرجع CA است. استفاده از این گواهی به معنای اعتماد به هویتی است که آن را امضا کرده است. در برخی موارد مانند گواهی‌های ریشه یا مراجع CA سطح بالا، صادرکننده گواهی خود را امضا می‌کند.

دوره اعتبار (Validity period): هر گواهی تنها برای مدت زمان محدودی معتبر است. این دوره با تاریخ و زمان شروع و پایان مشخص می‌شود و می‌تواند از چند ثانیه تا نزدیک به یک قرن متغیر باشد. دوره اعتبار انتخاب‌شده به عوامل مختلفی مانند استحکام کلید خصوصی استفاده‌شده برای امضا یا هزینه‌ای که فرد برای گواهی می‌پردازد بستگی دارد. این دوره، بازه زمانی مورد انتظاری است که هویت‌ها می‌توانند به مقدار عمومی اطمینان کنند مشروط بر اینکه کلید خصوصی به خطر نیفتاده باشد.

نام موضوع (Subject name): نام هویتی که کلید عمومی گواهی متعلق به آن است. این نام از استاندارد X.500 استفاده می‌کند، بنابراین طوری طراحی شده که در سراسر اینترنت یکتا باشد. این نام همان نام متمایز (DN) هویت است. بخش نام‌های متمایز X.500 را ببینید. برای مثال:

CN=Java Duke, OU=Java Software Division, O=Oracle Corporation, C=US

این موارد به نام عمومی (CN)، واحد سازمانی (OU)، سازمان (O) و کشور (C) موضوع اشاره دارند.

اطلاعات کلید عمومی موضوع (Subject public key information): کلید عمومی هویت نام‌برده به همراه یک شناسه الگوریتم که مشخص می‌کند این کلید متعلق به کدام سیستم رمزنگاری کلید عمومی است و پارامترهای کلید مرتبط.

زنجیره‌های گواهی (Certificate Chains)
دستور keytool می‌تواند مدخل‌های کلید انبار کلید را ایجاد و مدیریت کند که هر یک حاوی یک کلید خصوصی و یک زنجیره گواهی مرتبط هستند. اولین گواهی در زنجیره شامل کلید عمومی متناظر با کلید خصوصی است.

هنگامی که کلیدها برای اولین بار تولید می‌شوند، زنجیره معمولاً با یک عضو منفرد یعنی یک گواهی خودامضاشده شروع می‌شود. بخش -genkeypair را در دستورات ببینید. یک گواهی خودامضاشده گواهی‌ای است که صادرکننده (امضاکننده) آن همان موضوع گواهی است. موضوع هویتی است که کلید عمومی آن توسط گواهی تأیید اعتبار می‌شود. هنگامی که دستور -genkeypair برای تولید یک جفت‌کلید عمومی/خصوصی جدید فراخوانی می‌شود، کلید عمومی را در یک گواهی خودامضاشده نیز قرار می‌دهد.

سپس، پس از ایجاد یک درخواست امضای گواهی (CSR) با دستور -certreq و ارسال آن به یک مرجع صدور گواهی (CA)، پاسخ دریافتی از CA با دستور -importcert وارد شده و گواهی خودامضاشده با زنجیره‌ای از گواهی‌ها جایگزین می‌شود. گزینه‌های -certreq و -importcert را در بخش دستورات ببینید. در انتهای زنجیره، گواهی (پاسخ) صادرشده توسط CA قرار دارد که کلید عمومی موضوع را تأیید اعتبار می‌کند. گواهی بعدی در زنجیره، کلید عمومی مرجع CA را تأیید می‌کند.

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

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

یک قالب پاسخ متفاوت (تعریف‌شده توسط استاندارد PKCS #7) شامل زنجیره گواهی پشتیبان علاوه بر گواهی صادرشده است. هر دو قالب پاسخ می‌توانند توسط دستور keytool مدیریت شوند.

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

فایل گواهی‌های cacerts (The cacerts Certificates File)
یک فایل گواهی به نام cacerts در دایرکتوری مشخصه‌های امنیتی قرار دارد: java.home\lib\security در ویندوز و java.home/lib/security در Oracle Solaris، که در آن java.home دایرکتوری محیط زمان اجرا است (دایرکتوری jre در SDK یا دایرکتوری سطح بالای JRE).

فایل cacerts نشان‌دهنده یک انبار کلید در سطح سیستم حاوی گواهی‌های CA است. مدیران سیستم می‌توانند این فایل را با دستور keytool و با تعیین jks به عنوان نوع انبار کلید پیکربندی و مدیریت کنند. فایل انبار کلید cacerts همراه با مجموعه‌ای از گواهی‌های ریشه CA پیش‌فرض عرضه می‌شود. می‌توانید گواهی‌های پیش‌فرض را با دستور زیر فهرست کنید:

keytool -list -keystore java.home/lib/security/cacerts

گذرواژه اولیه فایل انبار کلید cacerts برابر با changeit است. مدیران سیستم باید این گذرواژه و مجوز دسترسی پیش‌فرض فایل را پس از نصب SDK تغییر دهند.

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

برای حذف یک گواهی CA نامعتبر از فایل cacerts، از گزینه delete در دستور keytool استفاده کنید. می‌توانید فایل cacerts را در دایرکتوری نصب JRE پیدا کنید. اگر مجوز ویرایش این فایل را ندارید با مدیر سیستم خود تماس بگیرید.

استاندارد کدگذاری گواهی RFC 1421 اینترنت (Internet RFC 1421 Certificate Encoding Standard)
گواهی‌ها اغلب به جای کدگذاری دودویی، با استفاده از قالب کدگذاری متنی قابل‌چاپ تعریف‌شده توسط استاندارد RFC 1421 اینترنت ذخیره می‌شوند. این قالب گواهی که به عنوان کدگذاری Base64 نیز شناخته می‌شود، صدور گواهی‌ها به سایر برنامه‌ها از طریق ایمیل یا سازوکارهای دیگر را آسان می‌کند.

گواهی‌های خوانده‌شده توسط دستورات -importcert و -printcert می‌توانند در این قالب یا کدگذاری دودویی باشند. دستور -exportcert به طور پیش‌فرض گواهی را با کدگذاری دودویی صادر می‌کند، اما هنگامی که گزینه -rfc مشخص شود، گواهی را در قالب کدگذاری قابل‌چاپ صادر خواهد کرد.

دستور -list به طور پیش‌فرض اثر انگشت SHA1 گواهی را چاپ می‌کند. اگر گزینه -v مشخص شود، گواهی در قالب خوانا برای انسان چاپ می‌شود. اگر گزینه -rfc مشخص شود، گواهی در قالب کدگذاری قابل‌چاپ خروجی داده خواهد شد.

در قالب کدگذاری قابل‌چاپ، گواهی کدگذاری‌شده در ابتدا و انتها با متن زیر محصور می‌شود:

-----BEGIN CERTIFICATE-----
گواهی کدگذاری‌شده در اینجا قرار می‌گیرد.
-----END CERTIFICATE-----
نام‌های متمایز X.500 (X.500 Distinguished Names)
نام‌های متمایز X.500 برای شناسایی هویت‌ها مانند مواردی که توسط فیلدهای subject و issuer (امضاکننده) گواهی‌های X.509 نام‌گذاری می‌شوند، استفاده می‌شوند. دستور keytool از زیربخش‌های زیر پشتیبانی می‌کند:

commonName: نام عمومی شخص مانند Susan Jones.

organizationUnit: نام واحد سازمانی کوچک (مانند دپارتمان یا بخش)؛ برای مثال Purchasing.

localityName: نام محل یا شهر؛ برای مثال Palo Alto.

stateName: نام ایالت یا استان؛ برای مثال California.

country: کد کشور دوحرفی؛ برای مثال CH.

هنگامی که یک رشته نام متمایز را به عنوان مقدار گزینه -dname ارائه می‌دهید (مانند دستور -genkeypair)، رشته باید در قالب زیر باشد:

CN=cName, OU=orgUnit, O=org, L=city, S=state, C=countryCode

تمام موارد مورب نشان‌دهنده مقادیر واقعی هستند و کلیدواژه‌های قبلی اختصاراتی برای موارد زیر می‌باشند:

CN=commonName
OU=organizationUnit
O=organizationName
L=localityName
S=stateName
C=country

یک نمونه رشته نام متمایز عبارت است از:

CN=Mark Smith, OU=Java, O=Oracle, L=Cupertino, S=California, C=US

دستور نمونه با استفاده از چنین رشته‌ای:

keytool -genkeypair -dname "CN=Mark Smith, OU=Java, O=Oracle, L=Cupertino,
S=California, C=US" -alias mark

بزرگی و کوچکی حروف در اختصارات کلیدواژه‌ها تفاوتی ندارد. برای مثال CN، cn و Cn همگی یکسان در نظر گرفته می‌شوند.

ترتیب قرارگیری اهمیت دارد؛ هر زیرمؤلفه باید به ترتیب تعیین‌شده درج شود. با این حال، درج تمام زیرمؤلفه‌ها الزامی نیست و می‌توانید از یک زیرمجموعه استفاده کنید، برای مثال:

CN=Steve Meier, OU=Java, O=Oracle, C=US

اگر مقدار رشته نام متمایز حاوی کاما باشد، هنگام تعیین رشته در خط فرمان کاما باید با یک نویسه بک‌اسلش (\) اسکیپ شود، مانند:

cn=Peter Schuster, ou=Java\, Product Development, o=Oracle, c=US

مشخص کردن رشته نام متمایز در خط فرمان هرگز اجباری نیست. هنگامی که نام متمایز برای دستوری مورد نیاز باشد اما در خط فرمان ارائه نشود، از کاربر برای تک‌تک زیرمؤلفه‌ها سوال خواهد شد. در این حالت، نیازی به اسکیپ کردن کاما با بک‌اسلش (\) نیست.

مهم: پیش از وارد کردن یک گواهی به عنوان گواهی مورد اعتماد، حتماً آن را با دقت بسیار بررسی کنید.

مثال ویندوز:

ابتدا گواهی را با دستور -printcert یا دستور -importcert بدون گزینه -noprompt مشاهده کنید. اطمینان حاصل کنید که اثر انگشت‌های نمایش‌داده‌شده گواهی با موارد مورد انتظار مطابقت دارند. برای مثال، فرض کنید شخصی گواهی‌ای را برای شما ارسال کرده و شما آن را در فایلی به نام \tmp\cert قرار داده‌اید. پیش از افزودن گواهی به فهرست گواهی‌های مورد اعتماد، می‌توانید دستور -printcert را برای مشاهده اثر انگشت‌های آن به صورت زیر اجرا کنید:

  keytool -printcert -file \tmp\cert
    Owner: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll
    Issuer: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll
    Serial Number: 59092b34
    Valid from: Thu Sep 25 18:01:13 PDT 1997 until: Wed Dec 24 17:01:13 PST 1997
    Certificate Fingerprints:
         MD5:  11:81:AD:92:C8:E5:0E:A2:01:2E:D4:7A:D7:5F:07:6F
         SHA1: 20:B6:17:FA:EF:E5:55:8A:D0:71:1F:E8:D6:9D:C0:37:13:0E:5E:FE
         SHA256: 90:7B:70:0A:EA:DC:16:79:92:99:41:FF:8A:FE:EB:90:
                 17:75:E0:90:B2:24:4D:3A:2A:16:A6:E4:11:0F:67:A4

مثال Oracle Solaris:

ابتدا گواهی را با دستور -printcert یا دستور -importcert بدون گزینه -noprompt مشاهده کنید. اطمینان حاصل کنید که اثر انگشت‌های نمایش‌داده‌شده گواهی با موارد مورد انتظار مطابقت دارند. برای مثال، فرض کنید شخصی گواهی‌ای را برای شما ایمیل کرده و شما آن را در فایلی به نام /tmp/cert قرار داده‌اید. پیش از افزودن گواهی به فهرست گواهی‌های مورد اعتماد، می‌توانید دستور -printcert را برای مشاهده اثر انگشت‌های آن به صورت زیر اجرا کنید:

  keytool -printcert -file /tmp/cert
    Owner: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll
    Issuer: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll
    Serial Number: 59092b34
    Valid from: Thu Sep 25 18:01:13 PDT 1997 until: Wed Dec 24 17:01:13 PST 1997
    Certificate Fingerprints:
         MD5:  11:81:AD:92:C8:E5:0E:A2:01:2E:D4:7A:D7:5F:07:6F
         SHA1: 20:B6:17:FA:EF:E5:55:8A:D0:71:1F:E8:D6:9D:C0:37:13:0E:5E:FE
         SHA256: 90:7B:70:0A:EA:DC:16:79:92:99:41:FF:8A:FE:EB:90:
                 17:75:E0:90:B2:24:4D:3A:2A:16:A6:E4:11:0F:67:A4

سپس با فردی که گواهی را ارسال کرده تماس گرفته و اثر انگشت‌هایی را که می‌بینید با مواردی که آن‌ها ارائه می‌دهند مقایسه کنید. تنها در صورت یکسان بودن اثر انگشت‌ها تضمین می‌شود که گواهی در حین انتقال با گواهی شخص دیگری مانند یک مهاجم جایگزین نشده است. اگر چنین حمله‌ای رخ داده باشد و شما گواهی را پیش از وارد کردن بررسی نکرده باشید، به هر چیزی که مهاجم امضا کرده است اعتماد خواهید کرد؛ برای مثال یک فایل JAR حاوی فایل‌های کلاس مخرب.

نکته: اجرای دستور -printcert پیش از وارد کردن گواهی اجباری نیست. زیرا پیش از افزودن گواهی به فهرست گواهی‌های مورد اعتماد در انبار کلید، دستور -importcert اطلاعات گواهی را چاپ کرده و از شما می‌خواهد آن را تأیید کنید. در این مرحله می‌توانید عملیات وارد کردن را متوقف نمایید. اما این کار تنها زمانی ممکن است که دستور -importcert را بدون گزینه -noprompt اجرا کنید. اگر گزینه -noprompt مشخص شده باشد، هیچ تعاملی با کاربر صورت نخواهد گرفت.

اکثر دستوراتی که روی یک انبار کلید عمل می‌کنند نیازمند گذرواژه انبار کلید هستند. برخی دستورات نیازمند گذرواژه کلید خصوصی/مخفی هستند. گذرواژه‌ها می‌توانند در خط فرمان در گزینه‌های -storepass و -keypass مشخص شوند. با این حال، گذرواژه نباید در خط فرمان یا اسکریپت‌ها مشخص شود مگر اینکه برای اهداف آزمایشی باشد یا روی یک سیستم امن قرار داشته باشید. هنگامی که یک گزینه گذرواژه الزامی را در خط فرمان مشخص نکنید، از شما درخواست خواهد شد.

استاندارد اینترنت RFC 5280 مشخصاتی را در مورد گواهی‌های منطبق با X.509 تعریف کرده که شامل مقادیر و ترکیبات مقادیر معتبر برای فیلدها و پسوندهای گواهی است. این استاندارد را در نشانی زیر ببینید: http://tools.ietf.org/rfc/rfc5280.txt

دستور keytool تمام این قوانین را اجبار نمی‌کند، بنابراین می‌تواند گواهی‌هایی تولید کند که با استاندارد منطبق نیستند. گواهی‌هایی که با استاندارد منطبق نباشند ممکن است توسط JRE یا سایر برنامه‌ها رد شوند. کاربران باید اطمینان حاصل کنند که گزینه‌های صحیحی را برای -dname، -ext و غیره ارائه می‌دهند.

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

اگر گزینه -trustcacerts مشخص شده باشد، گواهی‌های اضافی در فایلی به نام cacerts برای زنجیره اعتماد در نظر گرفته می‌شوند.

اگر دستور keytool نتواند یک مسیر اعتماد از گواهی ورودی تا یک گواهی خودامضاشده (از انبار کلید یا فایل cacerts) برقرار کند، اطلاعات گواهی چاپ شده و از کاربر خواسته می‌شود با مقایسه اثر انگشت‌های نمایش‌داده‌شده با اثر انگشت‌های به دست آمده از منبع معتبر دیگر (مانند مالک گواهی)، آن را تأیید کند. پیش از وارد کردن گواهی به عنوان گواهی مورد اعتماد بسیار دقت کنید تا از معتبر بودن آن مطمئن شوید. بخش هشدار وارد کردن گواهی‌های مورد اعتماد را ببینید. سپس کاربر این امکان را دارد که عملیات وارد کردن را متوقف کند. اگر گزینه -noprompt مشخص شده باشد، هیچ تعاملی با کاربر انجام نخواهد شد.

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

روش‌های تعیین معتبر بودن پاسخ گواهی به شرح زیر است:

•
اگر پاسخ یک گواهی منفرد X.509 باشد، دستور keytool تلاش می‌کند یک زنجیره اعتماد از پاسخ گواهی تا یک گواهی خودامضاشده (متعلق به مرجع ریشه CA) برقرار کند. پاسخ گواهی و سلسله‌مراتب گواهی‌ها برای تأیید اعتبار پاسخ گواهی از زنجیره گواهی جدید نام‌های مستعار استفاده می‌شود. اگر زنجیره اعتماد برقرار نشود، پاسخ گواهی وارد نخواهد شد. در این حالت، دستور keytool گواهی را چاپ نکرده و از کاربر برای تأیید سوال نمی‌کند، زیرا تشخیص اصالت پاسخ گواهی برای کاربر بسیار دشوار است.
•
اگر پاسخ یک زنجیره گواهی با قالب PKCS #7 یا دنباله‌ای از گواهی‌های X.509 باشد، زنجیره به گونه‌ای مرتب می‌شود که گواهی کاربر در ابتدا و سپس صفر یا چند گواهی CA قرار می‌گیرد. اگر زنجیره با یک گواهی ریشه خودامضاشده CA پایان یابد و گزینه -trustcacerts مشخص شده باشد، دستور keytool تلاش می‌کند آن را با هر یک از گواهی‌های مورد اعتماد موجود در انبار کلید یا فایل cacerts مطابقت دهد. اگر زنجیره با یک گواهی ریشه خودامضاشده CA پایان نیابد و گزینه -trustcacerts مشخص شده باشد، دستور keytool تلاش می‌کند گواهی ریشه را از گواهی‌های مورد اعتماد موجود در انبار کلید یا فایل cacerts پیدا کرده و به انتهای زنجیره اضافه کند. اگر گواهی پیدا نشود و گزینه -noprompt مشخص نشده باشد، اطلاعات آخرین گواهی موجود در زنجیره چاپ شده و از کاربر برای تأیید آن سوال خواهد شد.

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

این دستور در نسخه‌های قبلی -import نام داشت. این نام قدیمی همچنان در این نسخه پشتیبانی می‌شود، اما نام جدید -importcert برای آینده ترجیح داده می‌شود.

•
jar(1)
•
jarsigner(1)
•
ویژگی‌های امنیتی در Java SE در http://docs.oracle.com/javase/tutorial/security/index.html
03 March 2015 JDK 8