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

jarsigner-openjdk8 - ابزار امضا و اعتبارسنجی فایل‌های JAR در OpenJDK 8

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

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

دستور 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 منتقل می‌شود. مقدار NONE زمانی باید مشخص شود که کلاس KeyStore مبتنی بر فایل نباشد، برای مثال هنگامی که روی یک دستگاه توکن سخت‌افزاری قرار دارد.

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

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

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

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

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

دستورات jarsigner و policytool می‌توانند مخازن کلید مبتنی بر فایل را از هر مکانی که با یک 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، یک برچسب زمانی امضا (signature time stamp) تولید و ذخیره کند. علاوه بر این، 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 دارد بخوانید. هنگام خواندن، خلاصه پیام فایل را محاسبه کرده و نتیجه را با خلاصه مربوط به این فایل در بخش مانیفست مقایسه کنید. خلاصه‌ها باید یکسان باشند، در غیر این صورت اعتبارسنجی با شکست مواجه می‌شود.

اگر در طول فرآیند اعتبارسنجی خرابی جدی رخ دهد، فرآیند متوقف شده و یک استثنای امنیتی (security exception) صادر می‌شود. دستور 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 توکن را درخواست می‌کنند. اگر توکن دارای مسیر احراز هویت محافظت‌شده باشد (مانند صفحه کلید PIN اختصاصی یا اثرانگشت‌خوان)، باید گزینه -protected مشخص شود و هیچ گزینه رمز عبوری نباید داده شود.


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

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

•
env: رمز عبور را از متغیر محیطی به نام argument بازیابی می‌کند.
•
file: رمز عبور را از فایل به نام argument بازیابی می‌کند.
نکته: رمز عبور نباید در خط فرمان یا در یک اسکریپت مشخص شود مگر اینکه برای اهداف آزمایشی باشد یا در یک سیستم امن قرار داشته باشید.

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

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

•
env: رمز عبور را از متغیر محیطی به نام argument بازیابی می‌کند.
•
file: رمز عبور را از فایل به نام argument بازیابی می‌کند.
نکته: رمز عبور نباید در خط فرمان یا در یک اسکریپت مشخص شود مگر اینکه برای اهداف آزمایشی باشد یا در یک سیستم امن قرار داشته باشید.

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

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

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


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

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

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


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

برای فهرستی از نام‌های استاندارد الگوریتم خلاصه پیام، بخش "Appendix A: Standard Names" را در راهنمای مرجع Java Cryptography Architecture (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) باشد، نام متمایز (distinguished name) امضاکننده است.

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


زنجیره گواهی مورد استفاده را زمانی مشخص می‌کند که زنجیره گواهی مرتبط با کلید خصوصی مدخل مخزن کلید کامل نباشد. این موضوع زمانی رخ می‌دهد که مخزن کلید روی یک توکن سخت‌افزاری با ظرفیت ناکافی برای نگهداری زنجیره کامل گواهی قرار داشته باشد. این فایل می‌تواند دنباله‌ای از گواهی‌های 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 باشند. وقتی رمز عبور باید از طریق یک مسیر احراز هویت محافظت‌شده مانند یک دستگاه PINخوان اختصاصی وارد شود، مقدار 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 به آدرس http://example.tsa.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 استفاده کنید.


مسیر فایل کلاس و هر فایل 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 شامل مدخل‌های امضاشده‌ای است که با نام مستعار موجود در این مخزن کلید امضا نشده‌اند.

هشدارهای اطلاع‌رسانی شامل مواردی هستند که خطا محسوب نمی‌شوند اما به عنوان اقدام نامناسب (bad practice) تلقی می‌گردند. آنها فاقد کد خروج هستند.

این 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