نام (NAME)

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

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

jarsigner [options] jar-file alias

jarsigner -verify [options] jar-file [alias ...]

options

گزینه‌های خط فرمان. بخش Options for jarsigner را ببینید.

-verify

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

jar-file

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

alias

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

توضیحات (DESCRIPTION)

ابزار jarsigner دو هدف را دنبال می‌کند:

•

امضای فایل‌های بایگانی جاوا (JAR).

•

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

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

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

•

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

•

با فرض اینکه کلید خصوصی محرمانه بماند، جعل‌ناپذیر است.

•

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

•

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

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

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

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

دستور jarsigner می‌تواند امضاهایی شامل برچسب زمانی (timestamp) تولید کند که به سیستم‌ها یا مستقرکنندگان امکان می‌دهد بررسی کنند آیا فایل JAR در زمانی که گواهیِ امضاکننده هنوز معتبر بوده امضا شده است یا خیر.

علاوه بر این، رابط‌های برنامه‌نویسی (APIها) به برنامه‌ها اجازه می‌دهند اطلاعات برچسب زمانی را دریافت کنند.

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

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

دستور jarsigner همچنین تلاش می‌کند پس از امضا یا اعتبارسنجی، گواهی امضاکننده را اعتبارسنجی کند. در طول اعتبارسنجی، در صورت مشخص بودن گزینهٔ -revCheck، وضعیت ابطال هر گواهی در زنجیرهٔ گواهی‌های امضاکننده بررسی می‌شود. در صورت وجود خطای اعتبارسنجی یا هر مشکل دیگری، این دستور پیام‌های هشدار تولید می‌کند. اگر گزینهٔ -strict را مشخص کنید، دستور با هشدارهای جدی مانند خطا برخورد می‌کند. بخش Errors and Warnings را ببینید..SH "نام‌های مستعار مخزن کلید (KEYSTORE ALIASES)"

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

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

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

مکان مخزن کلید (KEYSTORE LOCATION)

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

لینوکس و OS X: مقدار پیش‌فرض user.home، دایرکتوری خانگی کاربر است.

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

پیاده‌سازی مخزن کلید (KEYSTORE IMPLEMENTATION)

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

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

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

پیاده‌سازی‌های مخزن کلید مبتنی بر ارائه‌دهنده (provider-based) هستند؛ بدین معنا که رابط‌های کاربردی ارائه‌شده توسط کلاس KeyStore بر پایه یک واسط ارائه‌دهنده سرویس (Service Provider Interface یا SPI) پیاده‌سازی شده‌اند. یک کلاس انتزاعی متناظر به نام KeystoreSpi نیز در پکیج java.security وجود دارد که متدهای واسط ارائه‌دهنده سرویس را که ارائه‌دهندگان باید پیاده‌سازی کنند، تعریف می‌کند. اصطلاح ارائه‌دهنده (provider) به یک پکیج یا مجموعه‌ای از پکیج‌ها اشاره دارد که پیاده‌سازی عینی زیرمجموعه‌ای از سرویس‌های قابل‌دسترس از طریق Java Security API را فراهم می‌کنند. برای ارائه یک پیاده‌سازی مخزن کلید، کلاینت‌ها باید یک ارائه‌دهنده را پیاده‌سازی کرده و پیاده‌سازی زیرکلاسی از KeystoreSpi را ارائه دهند، همان‌گونه که در How to Implement a Provider in the Java Cryptography Architecture [https://www.oracle.com/pls/topic/lookup?ctx=en/java/javase/11/tools&id=JSSEC-GUID-2BCFDD85-D533-4E6C-8CE9-29990DEB0190] شرح داده شده است.

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

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

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

اگر نوع مخزن کلید را به‌طور صریح مشخص نکنید، ابزارها پیاده‌سازی مخزن کلید را بر اساس مقدار مشخصه keystore.type تعیین‌شده در فایل مشخصات امنیتی برمی‌گزینند. فایل مشخصات امنیتی java.security نام دارد و در دایرکتوری مشخصات امنیتی JDK به نشانی java.home/conf/security قرار دارد.

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

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

نوع پیش‌فرض مخزن کلید، pkcs12 است که یک مخزن کلید چندسکویی مبتنی بر استاندارد RSA PKCS12 Personal Information Exchange Syntax می‌باشد. این مقدار با خط زیر در فایل مشخصات امنیتی تعیین می‌شود:

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

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

فایل امضا (SIGNATURE FILE)

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

•

نام فایل

•

نام الگوریتم چکیده (SHA)

•

مقدار چکیده SHA

نکته:

نام الگوریتم چکیده (SHA) و مقدار چکیده SHA در یک خط قرار دارند.

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

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

فایل بلوک امضا (SIGNATURE BLOCK FILE)

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

برچسب زمانی امضا (SIGNATURE TIME STAMP)

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

•

-tsa url

•

-tsacert alias

•

-tsapolicyid policyid

•

-tsadigestalg algorithm

بخش Options for jarsigner را ببینید..SH "اعتبارسنجی فایل JAR (JAR FILE VERIFICATION)"

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

1.

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

2.

اعتبارسنجی خلاصه (digest) درج‌شده در هر مدخل فایل .SF با بخش متناظر آن در مانیفست.

3.

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

4.

بررسی برای استفاده از الگوریتم‌های غیرفعال‌شده. بخش Supported Algorithms را ببینید.

نکته:

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

چندین امضا برای یک فایل JAR (MULTIPLE SIGNATURES FOR A JAR FILE)

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

jarsigner myBundle.jar susan
jarsigner myBundle.jar kevin

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

SUSAN.SF
SUSAN.RSA
KEVIN.SF
KEVIN.RSA

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

•

نام تمام گزینه‌ها با یک خط پیوند (-) آغاز می‌شود.

•

گزینه‌ها را می‌توان به هر ترتیبی ارائه داد.

•

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

•

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

-keystore url

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

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

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

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

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

-keystore NONE -storetype PKCS11

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

keytool -keystore NONE -storetype PKCS11 -list

-storepass [:env | :file] argument

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

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

نکته:

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

-storetype storetype

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

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

-keypass [:env | :file] argument -certchain file

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

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

نکته:

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

-certchain file

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

-sigfile file

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

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

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

-signedjar file

نام فایل JAR امضاشده را مشخص می‌کند.

-digestalg algorithm

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

برای مشاهده فهرستی از نام‌های استاندارد الگوریتم خلاصه پیام، به
Java Security Standard Algorithm Names مراجعه کنید..PP
اگر این گزینه مشخص نشود، از SHA256 استفاده می‌شود.
باید یا یک ارائه‌دهندهٔ نصب‌شده به‌صورت ایستا وجود داشته باشد که پیاده‌سازی الگوریتم مشخص‌شده را ارائه دهد یا کاربر باید ارائه‌دهنده‌ای را با گزینه‌های -addprovider یا -providerClass مشخص کند؛ در غیر این صورت، دستور موفق نخواهد بود.

-sigalg algorithm

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

این الگوریتم باید با کلید خصوصی به‌کاررفته برای امضای فایل JAR سازگار باشد.
اگر این گزینه مشخص نشود، از یک الگوریتم پیش‌فرض متناسب با کلید خصوصی، همان‌طور که در بخش Supported Algorithms شرح داده شده است، استفاده می‌شود.
باید یا یک ارائه‌دهنده به‌صورت ایستا نصب شده باشد که پیاده‌سازی الگوریتم مشخص‌شده را فراهم کند یا باید یکی را با گزینهٔ -addprovider یا -providerClass مشخص کنید؛ در غیر این صورت، دستور موفق نمی‌شود.

برای فهرستی از نام‌های استاندارد الگوریتم‌های خلاصهٔ پیام، به Java Security Standard Algorithm Names مراجعه کنید.

-verify

یک فایل JAR امضاشده را اعتبارسنجی می‌کند.

-verbose[:suboptions]

وقتی گزینهٔ -verbose در خط فرمان بیاید، نشان می‌دهد که jarsigner هنگام امضا یا اعتبارسنجی از حالت پرگو (verbose) استفاده کند که زیرگزینه‌ها تعیین می‌کنند چه میزان اطلاعات نمایش داده شود.
این امر باعث می‌شود jarsigner اطلاعات اضافی دربارهٔ پیشرفت امضا یا اعتبارسنجی JAR چاپ کند.
مقدار suboptions می‌تواند all، grouped یا summary باشد.

اگر گزینهٔ -certs نیز مشخص شده باشد، حالت پیش‌فرض (یا زیرگزینهٔ all) هر مدخل را هنگام پردازش، و پس از آن، اطلاعات گواهی را برای هر امضاکنندهٔ فایل JAR نمایش می‌دهد.

اگر گزینهٔ -certs و زیرگزینهٔ -verbose:grouped مشخص شوند، مدخل‌های دارای اطلاعات امضاکنندهٔ یکسان گروه‌بندی شده و به همراه اطلاعات گواهی‌شان با هم نمایش داده می‌شوند.

اگر -certs و زیرگزینهٔ -verbose:summary مشخص شوند، مدخل‌های دارای اطلاعات امضاکنندهٔ یکسان گروه‌بندی شده و به همراه اطلاعات گواهی‌شان نمایش داده می‌شوند.

جزئیات مربوط به هر مدخل خلاصه شده و به‌صورت one entry (and more) نمایش داده می‌شود.
به Example of Verifying a Signed JAR File و Example of Verification with Certificate Information مراجعه کنید.

-certs

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

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

-revCheck

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

-tsa url

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

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

-tsacert alias

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

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

-tsapolicyid policyid

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

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

-tsadigestalg algorithm

الگوریتم خلاصهٔ پیام را مشخص می‌کند که برای ایجاد نقش پیام (message imprint) ارسالی به کارساز TSA استفاده می‌شود.
اگر این گزینه مشخص نشود، از SHA-256 استفاده خواهد شد.

به Supported Algorithms مراجعه کنید.

برای فهرستی از نام‌های استاندارد الگوریتم‌های خلاصهٔ پیام، به Java Security Standard Algorithm Names مراجعه کنید.

-internalsf

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

-sectionsonly

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

به‌طور پیش‌فرض، این سرآیند به‌عنوان یک بهینه‌سازی اضافه می‌شود.
هنگامی که این سرآیند وجود دارد، هر زمان که فایل JAR اعتبارسنجی شود، فرآیند اعتبارسنجی می‌تواند ابتدا بررسی کند که آیا هش موجود در سرآیند با هش کل فایل manifest مطابقت دارد یا خیر.
در صورت وجود تطابق، اعتبارسنجی به مرحلهٔ بعدی می‌رود.
در صورت عدم تطابق، لازم است یک اعتبارسنجی کمتر بهینه‌شده انجام شود تا بررسی شود آیا هش موجود در بخش اطلاعات هر فایل منبع در فایل .SF با هش بخش متناظر آن در فایل manifest برابر است یا خیر.
به JAR File Verification مراجعه کنید..PP
گزینهٔ -sectionsonly اساساً برای آزمایش استفاده می‌شود.
نباید برای مقاصدی جز آزمایش استفاده شود، زیرا استفاده از آن بار اضافی بیشتری تحمیل می‌کند.

-protected

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

-providerName providerName

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

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

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

-addprovider name [-providerArg arg]

یک ارائه‌دهندهٔ امنیتی را بر اساس نام (مانند SunPKCS11) و یک آرگومان پیکربندی اختیاری اضافه می‌کند.
مقدار ارائه‌دهندهٔ امنیتی، نام ارائه‌دهنده‌ای است که در یک ماژول تعریف شده است.

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

jarsigner -keystore NONE -storetype PKCS11 -addprovider SunPKCS11 -providerArg /mydir1/mydir2/token.config

-providerClass provider-class-name [-providerArg arg]

برای مشخص کردن نام فایل کلاس اصلیِ ارائه‌دهندهٔ خدمات رمزنگاری در زمانی که ارائه‌دهندهٔ خدمات در فایل ویژگی‌های امنیتی java.security فهرست نشده باشد استفاده می‌شود.
یک ارائه‌دهندهٔ امنیتی را بر اساس نام کامل کلاس (fully-qualified) و یک آرگومان پیکربندی اختیاری اضافه می‌کند.

نکته:

روش ارجح برای بارگذاری PKCS11 استفاده از ماژول‌ها است.
-addprovider را ببینید.

-Jjavaoption

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

-strict

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

-conf url

یک فایل گزینه‌های از پیش‌پیکربندی‌شده را مشخص می‌کند.
برای جزئیات بیشتر، مستندات keytool را مطالعه کنید.
کلیدهای ویژگی پشتیبانی‌شده عبارتند از "jarsigner.all" برای همهٔ اقدامات، "jarsigner.sign" برای امضا کردن، و "jarsigner.verify" برای اعتبارسنجی.
آرگومان‌های jarsigner شامل نام فایل JAR و نام(های) مستعار را نمی‌توان در این فایل تنظیم کرد.

گزینه‌های زیر در jarsigner از JDK 9 منسوخ شده‌اند و ممکن است در انتشار‌های آیندهٔ JDK حذف شوند.

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

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

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

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

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

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

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

خطاها و هشدارها (ERRORS AND WARNINGS)

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

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

برای نمونه، اگر گواهیِ استفاده‌شده برای امضای یک مدخل منقضی شده باشد و دارای افزونهٔ KeyUsage باشد که اجازهٔ امضای فایل را نمی‌دهد، هنگام مشخص بودن گزینهٔ -strict، دستور jarsigner با کد 12 (=4+8) خارج می‌شود.

نکته: کدهای خروج دوباره استفاده می‌شوند (هم‌پوشانی دارند)، زیرا در Linux و OS X تنها مقادیر بین 0 تا 255 معتبر و مجاز هستند.

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

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

failure

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

هشدارهای جدی (SEVERE WARNINGS)

نکته:

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

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

hasExpiredCert

کد 4. این JAR حاوی مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها منقضی شده است.

hasExpiredTsaCert

کد 4. برچسب زمانی منقضی شده است.

notYetValidCert

کد 4. این JAR حاوی مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها هنوز معتبر نیست.

chainNotValidated

کد 4. این JAR حاوی مدخل‌هایی است که زنجیرهٔ گواهی آن‌ها اعتبارسنجی نشده است.

tsaChainNotValidated

کد 64. برچسب زمانی نامعتبر است.

signerSelfSigned

کد 4. این JAR حاوی مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها خودامضاشده است.

disabledAlg

کد 4. الگوریتم استفاده‌شده یک ریسک امنیتی تلقی شده و غیرفعال است.

badKeyUsage

کد 8. این JAR حاوی مدخل‌هایی است که افزونهٔ KeyUsage در گواهی امضاکنندهٔ آن‌ها اجازهٔ امضای کد را نمی‌دهد.

badExtendedKeyUsage

کد 8. این JAR حاوی مدخل‌هایی است که افزونهٔ ExtendedKeyUsage در گواهی امضاکنندهٔ آن‌ها اجازهٔ امضای کد را نمی‌دهد.

badNetscapeCertType

کد 8. این JAR حاوی مدخل‌هایی است که افزونهٔ NetscapeCertType در گواهی امضاکنندهٔ آن‌ها اجازهٔ امضای کد را نمی‌دهد.

hasUnsignedEntry

کد 16. این JAR حاوی مدخل‌های امضانشده‌ای است که بررسی یکپارچگی روی آن‌ها انجام نشده است.

notSignedByAlias

کد 32. این JAR حاوی مدخل‌های امضاشده‌ای است که توسط نام(های) مستعار مشخص‌شده امضا نشده‌اند.

aliasNotInStore

کد 32. این JAR حاوی مدخل‌های امضاشده‌ای است که توسط نام مستعار موجود در این keystore امضا نشده‌اند.

tsaChainNotValidated

کد 64. این JAR حاوی مدخل‌هایی است که زنجیرهٔ گواهی TSA آن‌ها نامعتبر است.

مثال امضای یک فایل JAR (EXAMPLE OF SIGNING A JAR FILE)

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

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

اگر می‌خواهید برای گذرواژهٔ store و گذرواژهٔ کلید خصوصی اعلان دریافت کنید (از شما پرسیده شود)، می‌توانید دستور قبلی را به شکل زیر کوتاه کنید:

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

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

مثال از اعتبارسنجی با اطلاعات گواهی (EXAMPLE OF VERIFICATION WITH CERTIFICATE INFORMATION)

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

jarsigner -keystore $JAVA_HOME/lib/security/cacerts -verify -verbose -certs ButtonDemo.jar
s k     866 Tue Sep 12 20:08:48 EDT 2017 META-INF/MANIFEST.MF
      >>> Signer
      X.509, CN="Oracle America, Inc.", OU=Software Engineering, O="Oracle America, Inc.", L=Redwood City, ST=California, C=US
      [certificate is valid from 2017-01-30, 7:00 PM to 2018-02-01, 6:59 PM]
      X.509, CN=Symantec Class 3 SHA256 Code Signing CA, OU=Symantec Trust Network, O=Symantec Corporation, C=US
      [certificate is valid from 2013-12-09, 7:00 PM to 2023-12-09, 6:59 PM]
      X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US (verisignclass3g5ca [jdk])
      [trusted certificate]
      >>> TSA
      X.509, CN=Symantec Time Stamping Services Signer - G4, O=Symantec Corporation, C=US
      [certificate is valid from 2012-10-17, 8:00 PM to 2020-12-29, 6:59 PM]
      X.509, CN=Symantec Time Stamping Services CA - G2, O=Symantec Corporation, C=US
      [certificate is valid from 2012-12-20, 7:00 PM to 2020-12-30, 6:59 PM]
        825 Tue Sep 12 20:08:48 EDT 2017 META-INF/ORACLE_C.SF
       7475 Tue Sep 12 20:08:48 EDT 2017 META-INF/ORACLE_C.RSA
          0 Tue Sep 12 20:07:54 EDT 2017 META-INF/
          0 Tue Sep 12 20:07:16 EDT 2017 components/
          0 Tue Sep 12 20:07:16 EDT 2017 components/images/
smk     523 Tue Sep 12 20:07:16 EDT 2017 components/ButtonDemo$1.class
      [entry was signed on 2017-09-12, 4:08 PM]
      >>> Signer
      X.509, CN="Oracle America, Inc.", OU=Software Engineering, O="Oracle America, Inc.", L=Redwood City, ST=California, C=US
      [certificate is valid from 2017-01-30, 7:00 PM to 2018-02-01, 6:59 PM]
      X.509, CN=Symantec Class 3 SHA256 Code Signing CA, OU=Symantec Trust Network, O=Symantec Corporation, C=US
      [certificate is valid from 2013-12-09, 7:00 PM to 2023-12-09, 6:59 PM]
      X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US (verisignclass3g5ca [jdk])
      [trusted certificate]
      >>> TSA
      X.509, CN=Symantec Time Stamping Services Signer - G4, O=Symantec Corporation, C=US
      [certificate is valid from 2012-10-17, 8:00 PM to 2020-12-29, 6:59 PM]
      X.509, CN=Symantec Time Stamping Services CA - G2, O=Symantec Corporation, C=US
      [certificate is valid from 2012-12-20, 7:00 PM to 2020-12-30, 6:59 PM]
smk    3440 Tue Sep 12 20:07:16 EDT 2017 components/ButtonDemo.class
...
smk    2346 Tue Sep 12 20:07:16 EDT 2017 components/ButtonDemo.jnlp
...
smk     172 Tue Sep 12 20:07:16 EDT 2017 components/images/left.gif
...
smk     235 Tue Sep 12 20:07:16 EDT 2017 components/images/middle.gif
...
smk     172 Tue Sep 12 20:07:16 EDT 2017 components/images/right.gif
...
  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
- Signed by "CN="Oracle America, Inc.", OU=Software Engineering, O="Oracle America, Inc.", L=Redwood City, ST=California, C=US"
    Digest algorithm: SHA-256
    Signature algorithm: SHA256withRSA, 2048-bit key
  Timestamped by "CN=Symantec Time Stamping Services Signer - G4, O=Symantec Corporation, C=US" on Tue Sep 12 20:08:49 UTC 2017
    Timestamp digest algorithm: SHA-1
    Timestamp signature algorithm: SHA1withRSA, 2048-bit key
jar verified.
The signer certificate expired on 2018-02-01. However, the JAR will be valid until the timestamp expires on 2020-12-29.

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