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

jarsigner - امضا و اعتبارسنجی فایل‌های آرشیو جاوا (JAR).

jarsigner [ گزینه‌ها ] jar-file alias
jarsigner -verify [ گزینه‌ها ] jar-file [alias ...]
گزینه‌ها
گزینه‌های خط فرمان. بخش گزینه‌ها را ببینید.

گزینه -verify می‌تواند صفر یا چند نام مستعار مخزن کلید را بعد از نام فایل JAR دریافت کند. هنگامی که گزینه -verify مشخص می‌شود، دستور jarsigner بررسی می‌کند که گواهی استفاده‌شده برای اعتبارسنجی هر مدخل امضاشده در فایل JAR با یکی از نام‌های مستعار مخزن کلید مطابقت داشته باشد. این نام‌های مستعار در مخزن کلید مشخص‌شده توسط -keystore یا مخزن کلید پیش‌فرض تعریف شده‌اند.

اگر گزینه -strict را نیز مشخص کنید و دستور jarsigner هشدارهای شدیدی را تشخیص دهد، پیام "jar verified, with signer errors" نمایش داده می‌شود.

فایل JAR که باید امضا شود.

اگر گزینه -strict را نیز مشخص کرده باشید و دستور jarsigner هشدارهای شدیدی را تشخیص داده باشد، پیام "jar signed, with signer errors" نمایش داده می‌شود.

نام‌های مستعاری که در مخزن کلید مشخص‌شده توسط -keystore یا مخزن کلید پیش‌فرض تعریف شده‌اند.

ابزار jarsigner دو هدف اصلی دارد:

•
امضای فایل‌های آرشیو جاوا (JAR).
•
اعتبارسنجی امضاها و بررسی یکپارچگی فایل‌های JAR امضاشده.

قابلیت JAR امکان بسته‌بندی فایل‌های کلاس، تصاویر، صداها و سایر داده‌های دیجیتال را در یک فایل واحد برای توزیع سریع‌تر و آسان‌تر فراهم می‌کند. ابزاری به نام jar به توسعه‌دهندگان امکان تولید فایل‌های JAR را می‌دهد. (از نظر فنی، هر فایل ZIP را نیز می‌توان یک فایل JAR در نظر گرفت، هرچند هنگام ایجاد توسط دستور jar یا پردازش توسط دستور jarsigner، فایل‌های JAR شامل یک فایل META-INF/MANIFEST.MF نیز هستند.)

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

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

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

دستور jarsigner از اطلاعات کلید و گواهی موجود در یک مخزن کلید (keystore) برای تولید امضاهای دیجیتال برای فایل‌های JAR استفاده می‌کند. مخزن کلید پایگاه‌داده‌ای از کلیدهای خصوصی و زنجیره‌های گواهی X.509 مرتبط با آن‌ها است که کلیدهای عمومی متناظر را تایید می‌کنند. دستور keytool برای ایجاد و مدیریت مخازن کلید استفاده می‌شود.

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

دستور jarsigner می‌تواند امضاهایی شامل برچسب زمانی (timestamp) تولید کند که به سیستم‌ها یا مستقرکنندگان (از جمله Java Plug-in) امکان می‌دهد بررسی کنند آیا فایل JAR در زمانی که گواهی امضا هنوز معتبر بوده، امضا شده است یا خیر. علاوه بر این، رابط‌های برنامه‌نویسی (APIها) به برنامه‌ها اجازه می‌دهند اطلاعات برچسب زمانی را دریافت کنند.

در حال حاضر، دستور jarsigner فقط می‌تواند فایل‌های JAR ایجادشده توسط دستور jar یا فایل‌های ZIP را امضا کند. فایل‌های JAR همان فایل‌های ZIP هستند، با این تفاوت که دارای فایل META-INF/MANIFEST.MF نیز می‌باشند. هنگامی که دستور jarsigner یک فایل ZIP را امضا می‌کند، یک فایل META-INF/MANIFEST.MF ایجاد می‌شود.

رفتار پیش‌فرض دستور jarsigner امضای یک فایل JAR یا ZIP است. برای اعتبارسنجی یک فایل JAR امضاشده از گزینه -verify استفاده کنید.

دستور jarsigner همچنین پس از امضا یا اعتبارسنجی تلاش می‌کند گواهی امضاکننده را ارزیابی کند. اگر خطای ارزیابی یا هر مشکل دیگری وجود داشته باشد، دستور پیام‌های هشدار تولید می‌کند. اگر گزینه -strict را مشخص کنید، دستور هشدارهای شدید را به عنوان خطا در نظر می‌گیرد. بخش خطاها و هشدارها را ببینید.

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

هنگامی که از دستور jarsigner برای امضای فایل JAR استفاده می‌کنید، باید نام مستعار مدخل مخزن کلید را که حاوی کلید خصوصی مورد نیاز برای تولید امضا است مشخص کنید. برای نمونه، دستور زیر فایل JAR با نام MyJARFile.jar را با کلید خصوصی مرتبط با نام مستعار duke در مخزن کلیدی به نام mystore در دایرکتوری working امضا می‌کند. از آنجا که هیچ فایل خروجی مشخص نشده است، فایل MyJARFile.jar را با فایل JAR امضاشده بازنویسی می‌کند.

jarsigner -keystore /working/mystore -storepass <keystore password>
      -keypass <private key password> MyJARFile.jar duke

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

دستور jarsigner دارای گزینه -keystore برای تعیین URL مخزن کلید مورد استفاده است. مخزن کلید به طور پیش‌فرض در فایلی به نام .keystore در دایرکتوری خانگی کاربر، طبق ویژگی سیستمی user.home ذخیره می‌شود.

در سیستم‌های Oracle Solaris، مقدار user.home به طور پیش‌فرض دایرکتوری خانگی کاربر است.

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

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

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

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

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

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

دستور jarsigner می‌تواند مخازن کلید مبتنی بر فایل را از هر مکانی که با یک URL قابل تعیین باشد بخواند. علاوه بر این، این دستور می‌تواند مخازن کلید غیرمبتنی بر فایل را مانند آنچه توسط MSCAPI در ویندوز و PKCS11 در تمام پلتفرم‌ها ارائه می‌شود بخواند.

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

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

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

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

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

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

keystore.type=jks

بزرگی و کوچکی حروف در مشخص کردن نوع مخزن کلید اهمیتی ندارد؛ برای نمونه، JKS با jks یکسان است.

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

keystore.type=pkcs12

نکته: اگر از بسته ارائه‌دهنده PKCS 11 استفاده می‌کنید، بخش‌های "KeyTool" و "JarSigner" را در راهنمای مرجع Java PKCS #11 ببینید: http://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html

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

•
الگوریتم امضای دیجیتال (DSA) با الگوریتم خلاصه‌ساز SHA1
•
الگوریتم RSA با الگوریتم خلاصه‌ساز SHA256
•
الگوریتم رمزنگاری منحنی بیضوی (EC) با SHA256 همراه با الگوریتم امضای دیجیتال منحنی بیضوی (ECDSA).

اگر کلیدهای عمومی و خصوصی امضاکننده از نوع کلیدهای DSA باشند، jarsigner فایل JAR را با الگوریتم SHA1withDSA امضا می‌کند. اگر کلیدهای امضاکننده از نوع RSA باشند، jarsigner تلاش می‌کند فایل JAR را با الگوریتم SHA256withRSA امضا کند. اگر کلیدهای امضاکننده از نوع EC باشند، jarsigner فایل JAR را با الگوریتم SHA256withECDSA امضا می‌نماید.

این الگوریتم‌های امضای پیش‌فرض را می‌توان با استفاده از گزینه -sigalg لغو کرد.

هنگامی که از دستور jarsigner برای امضای یک فایل JAR استفاده می‌شود، فایل JAR خروجی دقیقاً مشابه فایل JAR ورودی است، با این تفاوت که دو فایل اضافی در دایرکتوری META-INF آن قرار می‌گیرد:

•
یک فایل امضا با پسوند .SF
•
یک فایل بلوک امضا با پسوند .DSA، .RSA، یا .EC

نام پایه این دو فایل از مقدار گزینه -sigFile گرفته می‌شود. برای نمونه، هنگامی که گزینه -sigFile MKSIGN باشد، فایل‌ها MKSIGN.SF و MKSIGN.DSA نام‌گذاری می‌شوند.

اگر گزینه -sigfile در خط فرمان قید نشود، نام پایه فایل‌های .SF و .DSA برابر با ۸ نویسه نخست نام مستعار مشخص‌شده در خط فرمان خواهد بود که همگی به حروف بزرگ تبدیل شده‌اند. اگر نام مستعار کمتر از ۸ نویسه داشته باشد، کل نام مستعار استفاده می‌شود. اگر نام مستعار شامل نویسه‌هایی باشد که در نام فایل امضا مجاز نیستند، هر یک از این نویسه‌ها در تشکیل نام فایل به یک نویسه خط زیرین (_) تبدیل می‌شوند. نویسه‌های معتبر شامل حروف، ارقام، خط زیرین و خط تیره هستند.

فایل امضا (Signature File)

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

•
نام فایل
•
نام الگوریتم خلاصه‌ساز (SHA)
•
مقدار خلاصه‌ساز SHA

در فایل مانیفست، مقدار خلاصه‌ساز SHA برای هر فایل مبدأ، خلاصه (هش) داده‌های باینری در فایل مبدأ است. در فایل .SF، مقدار خلاصه‌ساز برای یک فایل مبدأ مشخص، هش سه خط مربوط به آن فایل مبدأ در فایل مانیفست است.

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

فایل بلوک امضا (Signature Block File)

فایل .SF امضا شده و امضا در فایل بلوک امضا قرار داده می‌شود. این فایل همچنین شامل گواهی یا زنجیره گواهی کدگذاری‌شده از مخزن کلید است که کلید عمومی متناظر با کلید خصوصی استفاده‌شده برای امضا را تایید می‌کند. این فایل بسته به الگوریتم خلاصه‌ساز مورد استفاده، دارای پسوند .DSA، .RSA، یا .EC است.

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

-tsa url
-tsacert alias
-altsigner class
-altsignerpath classpathlist
-tsapolicyid policyid

اعتبارسنجی موفق فایل JAR زمانی رخ می‌دهد که امضاها معتبر باشند و هیچ‌یک از فایل‌هایی که در زمان تولید امضاها در فایل JAR وجود داشتند از آن زمان تغییری نکرده باشند. اعتبارسنجی فایل JAR شامل گام‌های زیر است:

1.
اعتبارسنجی امضای فایل .SF.

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

2.
بررسی خلاصه ذکرشده در هر مدخل فایل .SF با هر بخش متناظر در مانیفست.

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

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

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

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

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

نکته: شما باید هرگونه هشدار اضافی (یا خطا در صورت تعیین گزینه -strict) و همچنین محتوای گواهی را (با مشخص کردن گزینه‌های -verbose و -certs) بررسی کنید تا مشخص شود که آیا می‌توان به امضا اعتماد کرد یا خیر.

یک فایل JAR می‌تواند توسط چندین نفر با اجرای چندباره دستور jarsigner روی فایل و مشخص کردن نام مستعار برای هر شخص در هر بار امضا شود، به صورت زیر:

jarsigner myBundle.jar susan
jarsigner myBundle.jar kevin

هنگامی که یک فایل JAR چندین بار امضا می‌شود، چندین فایل .SF و .DSA در فایل JAR حاصل وجود خواهد داشت، یک جفت برای هر امضا. در مثال پیشین، فایل JAR خروجی شامل فایل‌هایی با نام‌های زیر است:

SUSAN.SF
SUSAN.DSA
KEVIN.SF
KEVIN.DSA

بخش‌های زیر گزینه‌های گوناگون jarsigner را شرح می‌دهند. به استانداردهای زیر توجه داشته باشید:

•
پیش از نام تمام گزینه‌ها یک علامت خط تیره (-) قرار می‌گیرد.
•
گزینه‌ها را می‌توان به هر ترتیبی وارد کرد.
•
مواردی که با حروف کج یا زیرخط‌دار هستند (مقادیر گزینه‌ها) نشان‌دهنده مقادیر واقعی هستند که باید وارد شوند.
•
گزینه‌های -storepass، -keypass، -sigfile، -sigalg، -digestalg، -signedjar و گزینه‌های مربوط به TSA تنها هنگام امضای یک فایل JAR کاربرد دارند؛ آن‌ها هنگام اعتبارسنجی یک فایل JAR امضاشده کاربردی ندارند. گزینه -keystore هم برای امضا و هم برای اعتبارسنجی فایل JAR کاربرد دارد. علاوه بر این، نام‌های مستعار هنگام امضا و اعتبارسنجی فایل JAR مشخص می‌شوند.

نشانی اینترنتی (URL) را مشخص می‌کند که محل مخزن کلید را نشان می‌دهد. این مقدار به طور پیش‌فرض روی فایل .keystore در دایرکتوری خانگی کاربر، طبق ویژگی سیستمی user.home تنظیم شده است.

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

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

آرگومان -keystore به جای یک URL می‌تواند یک نام فایل و مسیر باشد، که در این صورت مشابه یک URL از نوع :file در نظر گرفته می‌شود؛ برای نمونه، موارد زیر معادل یکدیگرند:

-keystore filePathAndName
-keystore file:filePathAndName

اگر ارائه‌دهنده Sun PKCS #11 در فایل ویژگی‌های امنیتی java.security (واقع در دایرکتوری $JAVA_HOME/lib/security محیط JRE) پیکربندی شده باشد، ابزارهای keytool و jarsigner می‌توانند با تعیین این گزینه‌ها روی توکن PKCS #11 عمل کنند:

-keystore NONE
-storetype PKCS11

برای نمونه، دستور زیر محتویات توکن PKCS#11 پیکربندی‌شده را فهرست می‌کند:

keytool -keystore NONE -storetype PKCS11 -list

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

پین (PIN) برای توکن PKCS #11 نیز می‌تواند با گزینه -storepass مشخص شود. اگر هیچ مقداری مشخص نشود، دستورهای keytool و jarsigner پین توکن را درخواست می‌کنند. اگر توکن دارای یک مسیر احراز هویت محافظت‌شده باشد (مانند یک صفحه کلید اختصاصی PIN یا یک حسگر بیومتریک)، باید گزینه -protected مشخص شود و هیچ گزینه گذرواژه‌ای نباید وارد گردد.


گذرواژه‌ای را مشخص می‌کند که برای دسترسی به مخزن کلید لازم است. این مورد فقط هنگام امضا (نه اعتبارسنجی) فایل JAR لازم است. در این حالت، اگر گزینه -storepass در خط فرمان ارائه نشود، گذرواژه از کاربر درخواست می‌شود.

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

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

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


گذرواژه مورد استفاده برای محافظت از کلید خصوصی مدخل مخزن کلید را مشخص می‌کند که با نام مستعار ارائه‌شده در خط فرمان آدرس‌دهی شده است. این گذرواژه هنگام استفاده از jarsigner برای امضای فایل JAR الزامی است. اگر هیچ گذرواژه‌ای در خط فرمان ارائه نشود و گذرواژه مورد نیاز با گذرواژه مخزن متفاوت باشد، از کاربر درخواست می‌شود آن را وارد کند.

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

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

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


نام پایه فایل را برای استفاده در فایل‌های تولیدشده .SF و .DSA مشخص می‌کند. برای نمونه، اگر نام فایل DUKESIGN باشد، فایل‌های تولیدشده DUKESIGN.SF و DUKESIGN.DSA نام‌گذاری شده و در دایرکتوری META-INF فایل JAR امضاشده قرار می‌گیرند.

نویسه‌های موجود در فایل باید از مجموعه a-zA-Z0-9_- باشند. تنها حروف، ارقام، خط زیرین و خط تیره مجاز هستند. تمامی حروف کوچک برای نام‌های فایل‌های .SF و .DSA به حروف بزرگ تبدیل می‌شوند.

اگر گزینه -sigfile در خط فرمان مشخص نشود، نام پایه فایل‌های .SF و .DSA برابر با ۸ نویسه نخست نام مستعار مشخص‌شده در خط فرمان خواهد بود که همگی به حروف بزرگ تبدیل شده‌اند. اگر نام مستعار کمتر از ۸ نویسه داشته باشد، کل نام مستعار استفاده می‌شود. اگر نام مستعار حاوی نویسه‌هایی باشد که در نام فایل امضا معتبر نیستند، هر یک از این نویسه‌ها به یک خط زیرین (_) تبدیل می‌شوند تا نام فایل تشکیل شود.


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

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

این الگوریتم باید با کلید خصوصی استفاده‌شده برای امضای فایل JAR سازگار باشد. اگر این گزینه مشخص نشود، بسته به نوع کلید خصوصی، یکی از الگوریتم‌های SHA1withDSA، SHA256withRSA یا SHA256withECDSA استفاده می‌شود. باید یا یک ارائه‌دهنده به صورت ایستا نصب شده باشد که پیاده‌سازی الگوریتم مشخص‌شده را فراهم کند یا کاربر باید یکی را با گزینه -providerClass مشخص کند؛ در غیر این صورت، دستور با موفقیت اجرا نخواهد شد.


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

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

اگر این گزینه مشخص نشود، از SHA256 استفاده می‌شود. باید یا یک ارائه‌دهنده به صورت ایستا نصب شده باشد که پیاده‌سازی الگوریتم مشخص‌شده را فراهم کند یا کاربر باید یکی را با گزینه -providerClass مشخص کند؛ در غیر این صورت، دستور با موفقیت اجرا نخواهد شد.


اگر گزینه -certs همراه با گزینه‌های -verify و -verbose در خط فرمان ظاهر شود، خروجی شامل اطلاعات گواهی برای هر امضاکننده فایل JAR خواهد بود. این اطلاعات شامل نام نوع گواهی (ذخیره‌شده در فایل .DSA) است که کلید عمومی امضاکننده را تأیید می‌کند، و اگر گواهی یک گواهی X.509 باشد (نمونه‌ای از java.security.cert.X509Certificate)، نام متمایز (DN) امضاکننده را نیز در بر می‌گیرد.

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


زنجیره گواهی مورد استفاده را زمانی مشخص می‌کند که زنجیره گواهی مرتبط با کلید خصوصی مدخل مخزن کلید که با نام مستعار مشخص‌شده در خط فرمان آدرس‌دهی شده، کامل نباشد. این امر زمانی می‌تواند رخ دهد که مخزن کلید روی یک توکن سخت‌افزاری قرار داشته باشد که ظرفیت کافی برای نگهداری زنجیره گواهی کامل را ندارد. این فایل می‌تواند دنباله‌ای از گواهی‌های الحاق‌شده X.509 یا یک بلوک داده منفرد با قالب PKCS#7 باشد، خواه در قالب کدگذاری دودویی و خواه در قالب کدگذاری قابل چاپ (معروف به کدگذاری Base64) همان‌طور که در استاندارد RFC 1421 اینترنت تعریف شده است. استاندارد کدگذاری گواهی RFC 1421 را ببینید: http://tools.ietf.org/html/rfc1421

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

در گذشته، فایل .DSA (بلوک امضا) تولیدشده در زمان امضای فایل JAR، شامل یک نسخه کدگذاری‌شده کامل از فایل .SF (فایل امضا) بود که آن هم تولید می‌شد. این رفتار تغییر کرده است. برای کاهش حجم کلی فایل JAR خروجی، فایل .DSA به طور پیش‌فرض دیگر حاوی نسخه‌ای از فایل .SF نیست. اگر -internalsf در خط فرمان ظاهر شود، از رفتار قدیمی استفاده می‌شود. این گزینه برای آزمایش مفید است. در عمل، از گزینه -internalsf استفاده نکنید زیرا بار اضافی بیشتری به همراه دارد.

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

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

گزینه -sectionsonly اصولاً برای آزمایش استفاده می‌شود. نباید به جز برای آزمایش استفاده شود زیرا استفاده از آن بار اضافی بیشتری ایجاد می‌کند.


مقادیر می‌توانند true یا false باشند. زمانی که گذرواژه باید از طریق یک مسیر احراز هویت محافظت‌شده مانند یک پین‌خوان اختصاصی مشخص شود، مقدار true را تعیین کنید.

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

در صورت استفاده به همراه گزینه -providerArg ConfigFilePath، ابزارهای keytool و jarsigner ارائه‌دهنده را به صورت پویا نصب می‌کنند و از ConfigFilePath برای مسیر فایل پیکربندی توکن استفاده می‌نمایند. مثال زیر دستوری را برای فهرست کردن مخزن کلید PKCS #11 نشان می‌دهد زمانی که ارائه‌دهنده Oracle PKCS #11 در فایل ویژگی‌های امنیتی پیکربندی نشده است:

jarsigner -keystore NONE -storetype PKCS11 \
          -providerClass sun.security.pkcs11.SunPKCS11 \
          -providerArg /mydir1/mydir2/token.config \
          -list

اگر بیش از یک ارائه‌دهنده در فایل ویژگی‌های امنیتی java.security پیکربندی شده باشد، می‌توانید از گزینه -providerName برای هدف قرار دادن یک نمونه ارائه‌دهنده خاص استفاده کنید. آرگومان این گزینه نام ارائه‌دهنده است.

برای ارائه‌دهنده Oracle PKCS #11، مقدار providerName به شکل SunPKCS11-TokenName است، که در آن TokenName پسوند نامی است که نمونه ارائه‌دهنده با آن پیکربندی شده است، همان‌طور که در جدول ویژگی‌های پیکربندی آمده است. برای نمونه، دستور زیر محتویات نمونه ارائه‌دهنده مخزن کلید PKCS #11 را با پسوند نام SmartCard فهرست می‌کند:

jarsigner -keystore NONE -storetype PKCS11 \
        -providerName SunPKCS11-SmartCard \
        -list

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

اگر -tsa http://example.tsa.url هنگام امضای فایل JAR در خط فرمان ظاهر شود، یک برچسب زمانی برای امضا تولید می‌شود. این URL مکان مرجع برچسب زمانی (TSA) را مشخص می‌کند و هر URL یافته‌شده با گزینه -tsacert را لغو می‌نماید. گزینه -tsa نیازی به وجود گواهی کلید عمومی TSA در مخزن کلید ندارد.

برای تولید برچسب زمانی، jarsigner با استفاده از پروتکل برچسب زمانی (TSP) تعریف‌شده در RFC 3161 با TSA ارتباط برقرار می‌کند. در صورت موفقیت، توکن برچسب زمانی بازگردانده‌شده توسط TSA به همراه امضا در فایل بلوک امضا ذخیره می‌شود.


هنگامی که -tsacert alias در خط فرمان هنگام امضای فایل JAR ظاهر شود، یک برچسب زمانی برای امضا تولید می‌شود. این نام مستعار، گواهی کلید عمومی TSA در مخزن کلید معتبر را مشخص می‌کند. گواهی این مدخل برای یافتن افزونه Subject Information Access که حاوی URL مشخص‌کننده مکان TSA است بررسی می‌شود.

هنگام استفاده از گزینه -tsacert، گواهی کلید عمومی TSA باید در مخزن کلید وجود داشته باشد.


شناسه شیء (OID) را مشخص می‌کند که شناسه خط‌مشی ارسالی به سرور TSA را تعیین می‌نماید. اگر این گزینه مشخص نشود، هیچ شناسه خط‌مشی‌ای ارسال نمی‌شود و سرور TSA یک شناسه خط‌مشی پیش‌فرض را انتخاب خواهد کرد.

شناسه‌های شیء توسط X.696 تعریف شده‌اند که یک استاندارد بخش استانداردسازی مخابرات ITU (ITU-T) است. این شناسه‌ها معمولاً مجموعه‌ای از ارقام نامنفی جداشده با نقطه مانند 1.2.3.4 هستند.


این گزینه یک سازوکار امضای جایگزین را مشخص می‌کند. نام کلاس کاملاً واجد شرایط (Fully-qualified)، فایل کلاسی را مشخص می‌کند که کلاس انتزاعی com.sun.jarsigner.ContentSigner را گسترش می‌دهد. مسیر این فایل کلاس توسط گزینه -altsignerpath تعریف می‌شود. اگر از گزینه -altsigner استفاده شود، دستور jarsigner از سازوکار امضای ارائه‌شده توسط کلاس مشخص‌شده استفاده می‌کند. در غیر این صورت، دستور jarsigner از سازوکار امضای پیش‌فرض خود بهره می‌گیرد.

برای نمونه، برای استفاده از سازوکار امضای ارائه‌شده توسط کلاسی به نام com.sun.sun.jarsigner.AuthSigner، از گزینه -altsigner com.sun.jarsigner.AuthSigner در jarsigner استفاده کنید.


مسیر فایل کلاس و هر فایل JAR که به آن وابسته است را مشخص می‌کند. نام فایل کلاس با گزینه -altsigner مشخص می‌شود. اگر فایل کلاس درون یک فایل JAR باشد، این گزینه مسیر آن فایل JAR را مشخص می‌کند.

یک مسیر مطلق یا مسیری نسبت به دایرکتوری جاری می‌تواند مشخص شود. اگر classpathlist شامل چندین مسیر یا فایل JAR باشد، باید در Oracle Solaris با دونقطه (:) و در ویندوز با سمیکالن (;) از هم جدا شوند. زمانی که کلاس از قبل در مسیر جستجو قرار داشته باشد، این گزینه لازم نیست.

مثال زیر نحوه تعیین مسیر یک فایل JAR را نشان می‌دهد که حاوی فایل کلاس است؛ نام فایل JAR گنجانده شده است:

-altsignerpath /home/user/lib/authsigner.jar

مثال زیر نحوه تعیین مسیر فایل JAR حاوی فایل کلاس را نشان می‌دهد در حالی که نام فایل JAR حذف شده است:

-altsignerpath /home/user/classes/com/sun/tools/jarsigner/

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

برای فرآیند اعتبارسنجی، گزینه -verbose زیرگزینه‌هایی را برای تعیین میزان اطلاعات نمایش‌داده‌شده می‌پذیرد. اگر گزینه -certs نیز مشخص شده باشد، حالت پیش‌فرض (یا زیرگزینه all) هر مدخل را هنگام پردازش و پس از آن، اطلاعات گواهی هر امضاکننده فایل JAR را نمایش می‌دهد. اگر زیرگزینه‌های -certs و -verbose:grouped مشخص شده باشند، مدخل‌هایی با اطلاعات امضاکننده یکسان گروه‌بندی شده و همراه با اطلاعات گواهی آن‌ها نمایش داده می‌شوند. اگر زیرگزینه‌های -certs و -verbose:summary مشخص شده باشند، مدخل‌هایی با اطلاعات امضاکننده یکسان گروه‌بندی شده و همراه با اطلاعات گواهی آن‌ها نمایش داده می‌شوند. جزئیات مربوط به هر مدخل خلاصه‌سازی شده و به صورت one entry (and more) نمایش داده می‌شود. بخش مثال‌ها را ببینید.

در طول فرآیند امضا یا اعتبارسنجی، دستور jarsigner ممکن است خطاها یا هشدارهای مختلفی صادر کند.

اگر شکستی رخ دهد، دستور jarsigner با کد ۱ خارج می‌شود. اگر شکستی رخ ندهد اما یک یا چند هشدار شدید وجود داشته باشد، دستور jarsigner در صورتی که گزینه -strict تعیین نشده باشد با کد ۰ خارج می‌شود، یا زمانی که گزینه -strict مشخص شده باشد با مقدار OR بیتی کدهای هشدار خارج می‌شود. اگر فقط هشدارهای اطلاع‌رسانی وجود داشته باشد یا اصلاً هشداری وجود نداشته باشد، دستور همیشه با کد ۰ خارج می‌شود.

برای نمونه، اگر گواهی مورد استفاده برای امضای یک مدخل منقضی شده باشد و دارای افزونه KeyUsage باشد که اجازه امضای فایل را به آن نمی‌دهد، دستور jarsigner زمانی که گزینه -strict مشخص شده باشد با کد ۱۲ (=۴+۸) خارج می‌شود.

نکته: کدهای خروج مجدداً استفاده می‌شوند زیرا تنها مقادیر بین ۰ تا ۲۵۵ در سیستم‌عامل‌های مبتنی بر یونیکس مجاز هستند.

بخش‌های زیر نام‌ها، کدها و توضیحات خطاها و هشدارهایی را که دستور jarsigner می‌تواند صادر کند، شرح می‌دهند.

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

کد ۱. امضا یا اعتبارسنجی با شکست مواجه شد.

نکته: هشدارهای شدید در صورتی که گزینه -strict را تعیین کنید، به عنوان خطا گزارش می‌شوند.

دلایلی که دستور jarsigner یک هشدار شدید صادر می‌کند شامل مواردی است مانند اینکه گواهی مورد استفاده برای امضای فایل JAR دارای خطا باشد یا فایل JAR امضاشده مشکلات دیگری داشته باشد.

کد ۴. این jar حاوی مدخل‌هایی است که گواهی امضاکننده آن‌ها منقضی شده است.
کد ۴. این jar حاوی مدخل‌هایی است که گواهی امضاکننده آن‌ها هنوز معتبر نشده است.
کد ۴. این jar حاوی مدخل‌هایی است که زنجیره گواهی آن‌ها نمی‌تواند به درستی اعتبارسنجی شود.
کد ۸. این jar حاوی مدخل‌هایی است که افزونه KeyUsage گواهی امضاکننده آن‌ها اجازه امضای کد را نمی‌دهد.
کد ۸. این jar حاوی مدخل‌هایی است که افزونه ExtendedKeyUsage گواهی امضاکننده آن‌ها اجازه امضای کد را نمی‌دهد.
کد ۸. این jar حاوی مدخل‌هایی است که افزونه NetscapeCertType گواهی امضاکننده آن‌ها اجازه امضای کد را نمی‌دهد.
کد ۱۶. این jar حاوی مدخل‌های امضانشده‌ای است که یکپارچگی آن‌ها بررسی نشده است.
کد ۳۲. این jar حاوی مدخل‌های امضاشده‌ای است که توسط نام(های) مستعار مشخص‌شده امضا نشده‌اند.
کد ۳۲. این jar حاوی مدخل‌های امضاشده‌ای است که توسط نام مستعار در این مخزن کلید امضا نشده‌اند.

هشدارهای اطلاع‌رسانی شامل مواردی هستند که خطا نیستند اما به عنوان عملکرد نامناسب تلقی می‌شوند. آن‌ها کدی ندارند.

این jar حاوی مدخل‌هایی است که گواهی امضاکننده آن‌ها ظرف شش ماه آینده منقضی می‌شود.
این jar حاوی ناهماهنگی‌های داخلی شناسایی‌شده در حین اعتبارسنجی است که ممکن است هنگام خواندن از طریق JarFile و JarInputStream محتویات متفاوتی حاصل کند.
این jar حاوی امضاهایی است که شامل برچسب زمانی نیستند. بدون برچسب زمانی، کاربران ممکن است نتوانند این فایل JAR را پس از تاریخ انقضای گواهی امضاکننده (YYYY-MM-DD) یا پس از هر تاریخ ابطال در آینده اعتبارسنجی کنند.

از دستور زیر برای امضای bundle.jar با کلید خصوصی کاربری با نام مستعار jane در مخزن کلیدی به نام mystore در دایرکتوری working استفاده کنید و نام فایل JAR امضاشده را sbundle.jar بگذارید:

jarsigner -keystore /working/mystore
    -storepass <keystore password>
    -keypass <private key password>
    -signedjar sbundle.jar bundle.jar jane

هیچ گزینه -sigfile در دستور بالا مشخص نشده است، بنابراین فایل‌های تولیدشده .SF و .DSA که باید در فایل JAR امضاشده قرار گیرند، نام‌های پیش‌فرضی بر اساس نام مستعار خواهند داشت. آن‌ها JANE.SF و JANE.DSA نام‌گذاری می‌شوند.

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

jarsigner -keystore /working/mystore
    -signedjar sbundle.jar bundle.jar jane

اگر مخزن کلید همان مخزن کلید پیش‌فرض باشد (.keystore در دایرکتوری خانگی شما)، نیازی به تعیین مخزن کلید ندارید، به صورت زیر:

jarsigner -signedjar sbundle.jar bundle.jar jane

اگر می‌خواهید فایل JAR امضاشده روی فایل JAR ورودی (bundle.jar) بازنویسی شود، نیازی به تعیین گزینه -signedjar ندارید، به صورت زیر:

jarsigner bundle.jar jane

برای اعتبارسنجی یک فایل JAR امضاشده به منظور اطمینان از معتبر بودن امضا و دستکاری نشدن فایل JAR، از دستوری مانند زیر استفاده کنید:

jarsigner -verify sbundle.jar

هنگامی که اعتبارسنجی موفقیت‌آمیز باشد، پیام jar verified نمایش داده می‌شود. در غیر این صورت، یک پیام خطا نمایش می‌یابد. زمانی که از گزینه -verbose استفاده می‌کنید می‌توانید اطلاعات بیشتری دریافت نمایید. یک نمونه استفاده از jarsigner با گزینه -verbose در ادامه آمده است:

jarsigner -verify -verbose sbundle.jar
           198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF
           199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF
          1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA
    smk   2752 Fri Sep 26 16:12:30 PDT 1997 AclEx.class
    smk    849 Fri Sep 26 16:12:46 PDT 1997 test.class
      s = signature was verified
      m = entry is listed in manifest
      k = at least one certificate was found in keystore
    jar verified.

اگر گزینه -certs را همراه با گزینه‌های -verify و -verbose مشخص کنید، خروجی شامل اطلاعات گواهی برای هر امضاکننده فایل JAR خواهد بود. این اطلاعات شامل نوع گواهی، اطلاعات نام متمایز امضاکننده (زمانی که گواهی X.509 است)، و در پرانتز، نام مستعار مخزن کلید برای امضاکننده زمانی که گواهی کلید عمومی در فایل JAR با گواهی موجود در یک مدخل مخزن کلید مطابقت دارد، برای نمونه:

jarsigner -keystore /working/mystore -verify -verbose -certs myTest.jar
           198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF
           199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF
          1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA
           208 Fri Sep 26 16:23:30 PDT 1997 META-INF/JAVATEST.SF
          1087 Fri Sep 26 16:23:30 PDT 1997 META-INF/JAVATEST.DSA
    smk   2752 Fri Sep 26 16:12:30 PDT 1997 Tst.class
      X.509, CN=Test Group, OU=Java Software, O=Oracle, L=CUP, S=CA, C=US (javatest)
      X.509, CN=Jane Smith, OU=Java Software, O=Oracle, L=cup, S=ca, C=us (jane)
      s = signature was verified
      m = entry is listed in manifest
      k = at least one certificate was found in keystore
    jar verified.

اگر گواهی برای یک امضاکننده گواهی X.509 نباشد، اطلاعات نام متمایز وجود نخواهد داشت. در این حالت، فقط نوع گواهی و نام مستعار نمایش داده می‌شود. برای نمونه، اگر گواهی یک گواهی PGP باشد و نام مستعار bob باشد، مقدار PGP, (bob) را دریافت خواهید کرد.

•
jar(1)
•
keytool(1)
•
مبحث ویژگی‌های امنیتی در Java SE: http://docs.oracle.com/javase/tutorial/security/index.html
21 November 2013 JDK 8