نام (NAME)

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

خلاصه دستور (SYNOPSIS)

keytool [commands]

commands

بخش دستورها (Commands) را ببینید. این دستورها بر اساس وظیفه به شرح زیر دسته‌بندی می‌شوند:

نکات دستور و گزینه‌ها (COMMAND AND OPTION NOTES)

برای مشاهدهٔ فهرست و توضیحات دستورهای گوناگون، بخش Commands را ببینید.

•

پیش از نام تمامی دستورها و گزینه‌ها یک علامت منها (-) قرار می‌گیرد.

•

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

•

تمامی مواردی که کج (italic) نبوده یا درون آکولاد یا قلاب قرار ندارند، باید دقیقاً به همان صورت نوشته شوند.

•

آکولادهای احاطه‌کنندهٔ یک گزینه نشان می‌دهند که در صورت مشخص نشدن گزینه در خط فرمان، یک مقدار پیش‌فرض استفاده خواهد شد. بخش Option Defaults را ببینید. آکولاد همچنین در اطراف گزینه‌های -v، -rfc و -J نیز استفاده شده است، که تنها در صورت حضور در خط فرمان معنا دارند. آن‌ها هیچ مقدار پیش‌فرضی به‌جز عدم وجود ندارند.

•

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

•

موارد کج (مقادیر گزینه‌ها) نشان‌دهندهٔ مقادیر واقعی هستند که باید وارد شوند. برای نمونه، در اینجا قالب دستور -printcert آمده است:

keytool -printcert {-file cert_file} {-v}

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

•

مقادیر گزینه‌ها چنانچه شامل فاصله (space) باشند باید درون علامت نقل‌قول قرار گیرند.

•

گزینهٔ -help پیش‌فرض است. دستور keytool به تنهایی همانند keytool -help عمل می‌کند.

پیش‌فرض‌های گزینه‌ها (OPTION DEFAULTS)

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

-alias "mykey"

-keyalg

    "DSA" (هنگام استفاده از -genkeypair)

    "DES" (هنگام استفاده از -genseckey)

-keysize

    2048 (هنگام استفاده از -genkeypair و در صورتی که -keyalg برابر "RSA" باشد)

    1024 (هنگام استفاده از -genkeypair و در صورتی که -keyalg برابر "DSA" باشد)

    256 (هنگام استفاده از -genkeypair و در صورتی که -keyalg برابر "EC" باشد)

    56 (هنگام استفاده از -genseckey و در صورتی که -keyalg برابر "DES" باشد)

    168 (هنگام استفاده از -genseckey و در صورتی که -keyalg برابر "DESede" باشد)

-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، راهنمای مرجع Java Cryptography Architecture (JCA) را در http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA ببینید..SH "گزینه‌های عمومی (COMMON OPTIONS)" گزینهٔ -v می‌تواند برای همهٔ دستورها به‌جز -help به کار رود. هنگامی که گزینهٔ -v استفاده می‌شود، نشان‌دهندهٔ حالت پرگو (verbose) است، به این معنی که اطلاعات بیشتری در خروجی ارائه می‌شود.

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

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

-storetype storetype

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

-keystore keystore

مکان keystore.

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

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

-storepass[:env| :file] argument

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

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

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

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

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

-providerName provider_name

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

-providerClass provider_class_name

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

-providerArg provider_arg

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

-protected

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

-ext {name{:critical} {=value}}

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

افزونه‌های نام‌گذاری‌شده (NAMED EXTENSIONS)

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

BC یا BasicContraints

مقادیر: شکل کامل به این صورت است: ca:{true|false}[,pathlen:<len>] یا <len>، که شکل کوتاه ca:true,pathlen:<len> است. هنگامی که <len> حذف شود، مقدار برابر ca:true خواهد بود.

KU یا KeyUsage

مقادیر: usage(,usage)*، که در آن usage می‌تواند یکی از مقادیر digitalSignature، nonRepudiation (contentCommitment)، keyEncipherment، dataEncipherment، keyAgreement، keyCertSign، cRLSign، encipherOnly یا decipherOnly باشد. آرگومان usage می‌تواند با چند نویسهٔ نخست (مانند dig برای digitalSignature) یا به شیوهٔ شتری (مانند dS برای digitalSignature یا cRLS برای cRLSign) خلاصه شود، مادامی که ابهامی وجود نداشته باشد. مقادیر usage به بزرگی و کوچکی حروف حساس هستند.

EKU یا ExtendedKeyUsage

مقادیر: usage(,usage)*، که در آن usage می‌تواند یکی از مقادیر anyExtendedKeyUsage، serverAuth، clientAuth، codeSigning، emailProtection، timeStamping، OCSPSigning یا هر OID string باشد. آرگومان usage می‌تواند با چند نویسهٔ نخست یا به شیوهٔ شتری خلاصه شود، تا زمانی که ابهامی پیش نیاید. مقادیر usage به بزرگی و کوچکی حروف حساس هستند.

SAN یا SubjectAlternativeName

مقادیر: type:value(,type:value)*، که در آن type می‌تواند EMAIL، URI، DNS، IP یا OID باشد. آرگومان value مقدار رشته‌ای برای type است.

IAN یا IssuerAlternativeName

مقادیر: مشابه SubjectAlternativeName.

SIA یا SubjectInfoAccess

مقادیر: method:location-type:location-value (,method:location-type:location-value)*، که در آن method می‌تواند timeStamping، caRepository یا هر OID باشد. آرگومان‌های location-type و location-value می‌توانند هر type:value پشتیبانی‌شده توسط افزونهٔ SubjectAlternativeName باشند.

AIA یا AuthorityInfoAccess

مقادیر: مشابه SubjectInfoAccess. آرگومان method می‌تواند ocsp، caIssuers یا هر OID باشد.

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

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

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

افزونهٔ subjectKeyIdentifier همواره ایجاد می‌شود. برای گواهی‌هایی که خودامضاشده نیستند، authorityKeyIdentifier ایجاد می‌گردد.

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

دستورها (COMMANDS)

-gencert

{-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

-genkeypair

{-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 v3 قرار می‌دهد که به عنوان یک زنجیرهٔ گواهی تک‌عنصری ذخیره می‌شود. این زنجیرهٔ گواهی و کلید خصوصی در یک مدخل جدید در keystore که با alias مشخص می‌شود ذخیره می‌گردند.

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

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

مقدار keypass گذرواژه‌ای است که برای محافظت از کلید خصوصی جفت‌کلید تولیدشده استفاده می‌شود. اگر هیچ گذرواژه‌ای ارائه نشود، از کاربر خواسته می‌شود آن را وارد کند. اگر در اعلان کلید Return را فشار دهید، گذرواژهٔ کلید برابر با گذرواژهٔ keystore تنظیم می‌شود. مقدار 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، ترجیح داده می‌شود..TP -genseckey

{-alias alias} {-keyalg keyalg} {-keysize keysize} [-keypass keypass]

{-storetype storetype} {-keystore keystore} [-storepass storepass]

{-providerClass provider_class_name {-providerArg provider_arg}} {-v}

{-protected} {-Jjavaoption}

یک کلید مخفی تولید کرده و آن را در یک KeyStore.SecretKeyEntry جدید که با alias مشخص می‌شود، ذخیره می‌کند.

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

-importcert

{-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 خوانده و آن را در مدخل keystore مشخص‌شده با alias ذخیره می‌کند. اگر فایلی مشخص نشود، گواهی یا زنجیره گواهی از stdin خوانده می‌شود.

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

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

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

-importpassword

{-alias alias} [-keypass keypass] {-storetype storetype} {-keystore keystore}

[-storepass storepass]

{-providerClass provider_class_name {-providerArg provider_arg}}

{-v} {-protected} {-Jjavaoption}

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

-importkeystore

{-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}

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

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

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

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

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

-printcertreq

{-file file}

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

-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) ارسال شود. مرجع صدور گواهی، درخواست‌دهنده گواهی را (معمولاً به صورت برون‌خط) احراز هویت کرده و یک گواهی یا زنجیره گواهی بازمی‌گرداند که برای جایگزینی زنجیره گواهی موجود (که در ابتدا شامل یک گواهی خودامضا است) در keystore استفاده می‌شود.

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

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

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

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

-exportcert

{-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 را از keystore خوانده و آن را در فایل cert_file ذخیره می‌کند. هنگامی که هیچ فایلی مشخص نشده باشد، گواهی به stdout فرستاده می‌شود.

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

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

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

{-alias alias} {-storetype storetype} {-keystore keystore} [-storepass storepass]

{-providerName provider_name}

{-providerClass provider_class_name {-providerArg provider_arg}}

{-v | -rfc} {-protected} {-Jjavaoption}

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

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

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

-printcert

{-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 را برای تونل‌زنی پیشکار در خط فرمان مشخص کرد. راهنمای مرجع Java Secure Socket Extension (JSSE) را در http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html ببینید

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

-printcrl

-file crl_ {-v}

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

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

-storepasswd

[-new new_storepass] {-storetype storetype} {-keystore keystore}

[-storepass storepass] {-providerName provider_name}

{-providerClass provider_class_name {-providerArg provider_arg}}

{-v} {-Jjavaoption}

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

-keypasswd

{-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 در خط فرمان ارائه نشود، و گذرواژهٔ کلید با گذرواژهٔ keystore متفاوت باشد، آن‌گاه از کاربر خواسته می‌شود آن را وارد کند.

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

-delete

[-alias alias] {-storetype storetype} {-keystore keystore} [-storepass storepass]

{-providerName provider_name}  

{-providerClass provider_class_name {-providerArg provider_arg}}

{-v} {-protected} {-Jjavaoption}

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

-changealias

{-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}

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

-help

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

برای اطلاعات بیشتر دربارهٔ یک دستور خاص، عبارت زیر را وارد کنید که در آن command_name نام دستور است: keytool -command_name -help..SH "مثال‌ها (EXAMPLES)" این مثال مراحل متوالی ایجاد یک keystore برای مدیریت جفت‌کلید عمومی/خصوصی و گواهی‌های دریافتی از هویت‌های معتمد را شرح می‌دهد.

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

keytool -genkeypair

keytool -certreq -file MarkJ.csr

keytool -importcert -alias abc -file ABCCA.cer

keytool -importcert -trustcacerts -file VSMarkJ.cer

keytool -exportcert -alias mykey -file MJ.cer

keytool -importkeystore

    -srckeystore key.jks -destkeystore NONE

    -srcstoretype JKS -deststoretype PKCS11

    -srcstorepass <src keystore password>

    -deststorepass <destination keystore pwd>

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 -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

اصطلاحات (TERMS)

مخزن کلید (Keystore)

یک keystore تسهیلاتی برای ذخیره‌سازی کلیدهای رمزنگاری و گواهی‌ها است.

مدخل‌های مخزن کلید (Keystore entries)

مخازن کلید (keystores) می‌توانند انواع مختلفی از مدخل‌ها را داشته باشند. دو نوع مدخل که بیشترین کاربرد را برای دستور keytool دارند شامل موارد زیر هستند:

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

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

نام‌های مستعار مخزن کلید (KeyStore aliases)

دسترسی به تمام مدخل‌های keystore (مدخل‌های کلید و مدخل‌های گواهی مورد اعتماد) از طریق نام‌های مستعار (alias) یکتا انجام می‌شود.

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

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

keytool -genkeypair -alias duke -keypass dukekeypasswd

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

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

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

پیاده‌سازی مخزن کلید (KeyStore implementation)

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

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

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

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

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

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

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

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

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

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

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

keystore.type=jks

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

keystore.type=pkcs12

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

گواهی (Certificate)

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

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

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

هویت (Identity): یک روش شناخته‌شده برای نشانی‌دهی به یک موجودیت. در برخی سیستم‌ها، هویت همان کلید عمومی است، و در برخی دیگر می‌تواند هر چیزی باشد، از یک UID در Oracle Solaris گرفته تا یک نشانی ایمیل یا یک نام متمایز در X.509.

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

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

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

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

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

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

گواهی‌های X.509 (X.509 Certificates)

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

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

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

نسخه ۱ استاندارد 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): «نام متمایز» (Distinguished Name) استاندارد X.500 برای موجودیتی که گواهی را امضا کرده است. به بخش «نام‌های متمایز X.500» (X.500 Distinguished Names) مراجعه کنید. این موجودیت معمولاً یک CA است. استفاده از این گواهی به معنای اعتماد به موجودیتی است که این گواهی را امضا کرده است. در برخی موارد، مانند گواهی‌های CA ریشه یا بالاترین سطح، صادرکننده گواهی خود را امضا می‌کند.

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

نام موضوع (Subject name): نام موجودیتی که گواهی، کلید عمومی آن را مشخص می‌کند. این نام از استاندارد X.500 استفاده می‌کند، بنابراین برای یکتا بودن در سراسر اینترنت در نظر گرفته شده است. این نام، «نام متمایز» (DN) استاندارد X.500 موجودیت است. به بخش «نام‌های متمایز X.500» (X.500 Distinguished Names) مراجعه کنید. برای نمونه:

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

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

اطلاعات کلید عمومی موضوع (Subject public key information): این کلید عمومی موجودیت نام‌برده‌شده به همراه یک شناسه الگوریتم است که مشخص می‌کند این کلید متعلق به کدام سیستم رمزنگاری کلید عمومی بوده و هرگونه پارامتر کلید مرتبط را مشخص می‌نماید..TP زنجیره‌های گواهی (Certificate Chains) دستور keytool می‌تواند مدخل‌های کلید keystore را ایجاد و مدیریت کند که هرکدام حاوی یک کلید خصوصی و یک زنجیره گواهی مرتبط هستند. نخستین گواهی در زنجیره، حاوی کلید عمومی متناظر با کلید خصوصی است.

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

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

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

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

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

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

فایل گواهی‌های cacerts

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

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

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

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

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

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

استاندارد کدگذاری گواهی Internet RFC 1421

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

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

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

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

-----BEGIN CERTIFICATE-----

encoded certificate goes here. 

-----END CERTIFICATE-----

نام‌های متمایز 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

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

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

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

  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

  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

نکات (NOTES)

همچنین ببینید (SEE ALSO)

•

jar(1)

•

jarsigner(1)

•

مسیر آموزشی: قابلیت‌های امنیتی در Java SE در http://docs.oracle.com/javase/tutorial/security/index.html