'\" t
.\" Automatically generated by Pandoc 3.10.2
.\"
.TH "JARSIGNER" "1" "2026" "JDK 26.0.2.1" "JDK Commands"
.SH "نام (NAME)"
jarsigner \- امضا و اعتبارسنجی فایل‌های بایگانی جاوا (JAR)
.SH "خلاصه دستور (SYNOPSIS)"
\f[CR]jarsigner\f[R] [\f[I]options\f[R]] \f[I]jar\-file\f[R]
\f[I]alias\f[R]
.PP
\f[CR]jarsigner\f[R] \f[CR]\-verify\f[R] [\f[I]options\f[R]]
\f[I]jar\-file\f[R] [\f[I]alias\f[R] ...]
.PP
\f[CR]jarsigner\f[R] \f[CR]\-version\f[R]
.TP
\f[I]options\f[R]
گزینه‌های خط فرمان.
بخش \f[B]Options for jarsigner\f[R] را ببینید.
.TP
\f[CR]\-verify\f[R]
گزینهٔ \f[CR]\-verify\f[R] می‌تواند صفر یا چند نام مستعار (alias) در keystore را پس از نام فایل JAR بپذیرد.
هنگامی که گزینهٔ \f[CR]\-verify\f[R] مشخص شود، دستور \f[CR]jarsigner\f[R] بررسی می‌کند که گواهی استفاده‌شده برای اعتبارسنجی هر مدخل امضاشده در فایل JAR با یکی از نام‌های مستعار keystore مطابقت داشته باشد.
این نام‌های مستعار در keystore مشخص‌شده توسط \f[CR]\-keystore\f[R] یا keystore پیش‌فرض تعریف شده‌اند.
.RS
اگر گزینهٔ \f[CR]\-strict\f[R] را نیز مشخص کنید و دستور \f[CR]jarsigner\f[R] هشدارهای شدیدی را شناسایی کند، پیام \(dqjar verified, with signer errors\(dq نمایش داده می‌شود.
.RE
.TP
\f[I]jar\-file\f[R]
فایل JAR که قرار است امضا شود.
.RS
اگر گزینهٔ \f[CR]\-strict\f[R] را نیز مشخص کرده باشید و دستور \f[CR]jarsigner\f[R] هشدارهای شدیدی را شناسایی کند، پیام \(dqjar signed, with signer errors\(dq نمایش داده می‌شود.
.RE
.TP
\f[I]alias\f[R]
نام‌های مستعاری که در keystore مشخص‌شده توسط \f[CR]\-keystore\f[R] یا keystore پیش‌فرض تعریف شده‌اند.
.TP
\f[CR]\-version\f[R]
گزینهٔ \f[CR]\-version\f[R] نسخهٔ برنامهٔ \f[CR]jarsigner\f[R] را چاپ می‌کند.
.SH "توضیحات (DESCRIPTION)"
ابزار \f[CR]jarsigner\f[R] دو هدف دارد:
.IP \(bu 2
امضا کردن فایل‌های بایگانی جاوا (JAR).
.IP \(bu 2
اعتبارسنجی امضاها و یکپارچگی فایل‌های امضاشدهٔ JAR.
.PP
قابلیت JAR امکان بسته‌بندی فایل‌های کلاس، تصاویر، صداها و سایر داده‌های دیجیتال را در یک فایل واحد برای توزیع سریع‌تر و آسان‌تر فراهم می‌کند.
ابزاری به نام \f[CR]jar\f[R] به توسعه‌دهندگان امکان تولید فایل‌های JAR را می‌دهد.
(از نظر فنی، هر فایل ZIP را نیز می‌توان یک فایل JAR در نظر گرفت، هرچند هنگام ایجاد توسط دستور \f[CR]jar\f[R] یا پردازش توسط دستور \f[CR]jarsigner\f[R]، فایل‌های JAR حاوی یک فایل \f[CR]META\-INF/MANIFEST.MF\f[R] نیز هستند.)
.PP
امضای دیجیتال رشته‌ای از بیت‌هاست که از روی داده‌ها (داده‌هایی که امضا می‌شوند) و کلید خصوصی یک نهاد (شخص، شرکت و غیره) محاسبه می‌شود.
مشابه یک امضای دست‌نویس، امضای دیجیتال ویژگی‌های سودمند بسیاری دارد:
.IP \(bu 2
اصالت آن را می‌توان با محاسباتی که از کلید عمومی متناظر با کلید خصوصیِ استفاده‌شده برای تولید امضا بهره می‌برد، اعتبارسنجی کرد.
.IP \(bu 2
با فرض محرمانه ماندن کلید خصوصی، جعل آن غیرممکن است.
.IP \(bu 2
تابعی از داده‌های امضاشده است و بنابراین نمی‌توان ادعا کرد که امضای داده‌های دیگر نیز هست.
.IP \(bu 2
داده‌های امضاشده قابل تغییر نیستند.
اگر داده‌ها تغییر کنند، اصالت امضا دیگر قابل اعتبارسنجی نخواهد بود.
.PP
برای تولید امضای یک نهاد برای یک فایل، آن نهاد باید ابتدا یک جفت‌کلید عمومی/خصوصی مرتبط با خود و یک یا چند گواهی که کلید عمومی آن را تأیید می‌کنند داشته باشد.
گواهی بیانیه‌ای دارای امضای دیجیتال از سوی یک نهاد است که بیان می‌کند کلید عمومی نهادی دیگر دارای مقداری مشخص است.
.PP
دستور \f[CR]jarsigner\f[R] از اطلاعات کلید و گواهی موجود در یک keystore برای تولید امضاهای دیجیتال فایل‌های JAR استفاده می‌کند.
یک keystore پایگاه‌داده‌ای از کلیدهای خصوصی و زنجیره‌های گواهی X.509 مرتبط با آن‌هاست که کلیدهای عمومی متناظر را تأیید می‌کنند.
دستور \f[CR]keytool\f[R] برای ایجاد و مدیریت keystoreها استفاده می‌شود.
.PP
دستور \f[CR]jarsigner\f[R] از کلید خصوصی یک نهاد برای تولید امضا استفاده می‌کند.
فایل JAR امضاشده، علاوه بر موارد دیگر، شامل رونوشتی از گواهی keystore برای کلید عمومی متناظر با کلید خصوصیِ استفاده‌شده برای امضای فایل است.
دستور \f[CR]jarsigner\f[R] می‌تواند امضای دیجیتال فایل JAR امضاشده را با استفاده از گواهی درون آن (در فایل بلوک امضای آن) اعتبارسنجی کند.
.PP
دستور \f[CR]jarsigner\f[R] می‌تواند امضاهایی شامل برچسب زمانی (timestamp) تولید کند که به سیستم‌ها یا مستقرکنندگان امکان می‌دهد بررسی کنند آیا فایل JAR زمانی امضا شده است که گواهی امضا هنوز معتبر بوده یا خیر.
.PP
علاوه بر این، رابط‌های برنامه‌نویسی کاربردی (APIها) به برنامه‌ها امکان می‌دهند تا اطلاعات برچسب زمانی را به دست آورند.
.PP
در حال حاضر، دستور \f[CR]jarsigner\f[R] تنها می‌تواند فایل‌های JAR ایجادشده توسط دستور \f[CR]jar\f[R] یا فایل‌های zip را امضا کند.
فایل‌های JAR مشابه فایل‌های zip هستند، با این تفاوت که دارای یک فایل \f[CR]META\-INF/MANIFEST.MF\f[R] نیز می‌باشند.
هنگامی که دستور \f[CR]jarsigner\f[R] یک فایل zip را امضا می‌کند، یک فایل \f[CR]META\-INF/MANIFEST.MF\f[R] ایجاد می‌شود.
.PP
رفتار پیش‌فرض دستور \f[CR]jarsigner\f[R] امضای یک فایل JAR یا zip است.
برای اعتبارسنجی یک فایل JAR امضاشده از گزینهٔ \f[CR]\-verify\f[R] استفاده کنید.
.PP
دستور \f[CR]jarsigner\f[R] همچنین پس از امضا یا اعتبارسنجی تلاش می‌کند گواهی امضاکننده را تأیید اعتبار کند.
در طول اعتبارسنجی، چنانچه گزینهٔ \f[CR]\-revCheck\f[R] مشخص شده باشد، وضعیت ابطال هر گواهی در زنجیرهٔ گواهی‌های امضاکننده بررسی می‌شود.
اگر خطای اعتبارسنجی یا هر مشکل دیگری رخ دهد، این دستور پیام‌های هشدار تولید می‌کند.
اگر گزینهٔ \f[CR]\-strict\f[R] را مشخص کنید، دستور هشدارهای شدید را به عنوان خطا در نظر می‌گیرد.
بخش \f[B]Errors and Warnings\f[R] را ببینید..SH "نام‌های مستعار مخزن کلید (KEYSTORE ALIASES)"
تمامی موجودیت‌های مخزن کلید (keystore) با نام‌های مستعار (alias) یکتا در دسترس قرار می‌گیرند.
.PP
هنگامی که از دستور \f[CR]jarsigner\f[R] برای امضای یک فایل JAR استفاده می‌کنید، باید نام مستعار مدخلی از keystore را مشخص کنید که حاوی کلید خصوصی مورد نیاز برای تولید امضا است.
اگر هیچ فایل خروجی مشخص نشود، فایل JAR اصلی با فایل JAR امضاشده بازنویسی می‌شود.
.PP
مخازن کلید با گذرواژه محافظت می‌شوند، بنابراین گذرواژه مخزن (store password) باید مشخص شود.
در صورتی که آن را در خط فرمان مشخص نکنید، از شما خواسته می‌شود آن را وارد کنید.
به طور مشابه، کلیدهای خصوصی در یک keystore با یک گذرواژه محافظت می‌شوند، بنابراین گذرواژه کلید خصوصی باید مشخص گردد، و چنانچه آن را در خط فرمان مشخص نکرده باشید و با گذرواژه مخزن یکسان نباشد، از شما برای وارد کردن گذرواژه درخواست خواهد شد.
.SH "مکان مخزن کلید (KEYSTORE LOCATION)"
دستور \f[CR]jarsigner\f[R] دارای گزینه \f[CR]\-keystore\f[R] برای مشخص کردن URL مخزن کلید مورد استفاده است.
به‌طور پیش‌فرض، keystore در فایلی به نام \f[CR].keystore\f[R] در دایرکتوری خانگی کاربر، همان‌طور که توسط ویژگی سیستمی \f[CR]user.home\f[R] تعیین می‌شود، ذخیره می‌گردد.
.PP
\f[B]لینوکس و macOS:\f[R] مقدار پیش‌فرض \f[CR]user.home\f[R]، دایرکتوری خانگی کاربر است.
.PP
جریان ورودی حاصل از گزینه \f[CR]\-keystore\f[R] به متد \f[CR]KeyStore.load\f[R] ارسال می‌شود.
اگر \f[CR]NONE\f[R] به عنوان URL مشخص شود، یک جریان تهی (null stream) به متد \f[CR]KeyStore.load\f[R] منتقل می‌گردد.
زمانی که کلاس \f[CR]KeyStore\f[R] مبتنی بر فایل نیست، به عنوان مثال هنگامی که روی یک دستگاه توکن سخت‌افزاری قرار دارد، باید مقدار \f[CR]NONE\f[R] مشخص شود.
.SH "پیاده‌سازی مخزن کلید (KEYSTORE IMPLEMENTATION)"
کلاس \f[CR]KeyStore\f[R] ارائه‌شده در بسته \f[CR]java.security\f[R] چندین رابط خوش‌تعریف را برای دسترسی و تغییر اطلاعات درون یک keystore فراهم می‌کند.
می‌توانید چندین پیاده‌سازی واقعی (concrete) متفاوت داشته باشید که در آن هر پیاده‌سازی برای نوع خاصی از keystore است.
.PP
در حال حاضر، دو ابزار خط فرمانی وجود دارند که از پیاده‌سازی‌های keystore استفاده می‌کنند (\f[CR]keytool\f[R] و \f[CR]jarsigner\f[R]).
.PP
پیاده‌سازی پیش‌فرض keystore مقدار \f[CR]PKCS12\f[R] است.
این یک keystore چندسکویی بر پایه استاندارد RSA PKCS12 Personal Information Exchange Syntax است.
این استاندارد در درجه اول برای ذخیره‌سازی یا انتقال کلیدهای خصوصی، گواهی‌ها و اسرار متفرقه کاربر در نظر گرفته شده است.
پیاده‌سازی توکار دیگری نیز وجود دارد که توسط Oracle ارائه شده است.
این پیاده‌سازی، keystore را به عنوان فایلی با یک نوع (قالب) اختصاصی به نام \f[CR]JKS\f[R] پیاده‌سازی می‌کند.
این قالب از هر کلید خصوصی با گذرواژه اختصاصی خودش محافظت کرده، و همچنین یکپارچگی کل keystore را با یک گذرواژه (احتمالاً متفاوت) تأمین می‌نماید.
.PP
پیاده‌سازی‌های keystore مبتنی بر ارائه‌دهنده (provider-based) هستند، به این معنی که رابط‌های کاربردی ارائه‌شده توسط کلاس \f[CR]KeyStore\f[R] در قالب یک Service Provider Interface (SPI) پیاده‌سازی می‌شوند.
یک کلاس انتزاعی متناظر به نام \f[CR]KeystoreSpi\f[R] نیز در \f[CR]java.security package\f[R] وجود دارد که متدهای Service Provider Interface را که ارائه‌دهندگان باید پیاده‌سازی کنند، تعریف می‌کند.
اصطلاح ارائه‌دهنده (provider) به یک بسته یا مجموعه‌ای از بسته‌ها اشاره دارد که پیاده‌سازی واقعی زیرمجموعه‌ای از سرویس‌های قابل دسترس از طریق Java Security API را فراهم می‌کنند.
برای ارائه یک پیاده‌سازی keystore، کلاینت‌ها باید یک provider را پیاده‌سازی کرده و پیاده‌سازی زیرکلاسی از \f[CR]KeystoreSpi\f[R] را ارائه دهند، همان‌طور که در \f[B]How to Implement a Provider in the Java Cryptography Architecture\f[R]
[https://www.oracle.com/pls/topic/lookup?ctx=en/java/javase&id=security_guide_implement_provider_jca]
شرح داده شده است.
.PP
برنامه‌ها می‌توانند انواع مختلفی از پیاده‌سازی‌های keystore را از ارائه‌دهندگان مختلف، با استفاده از متد کارخانه‌ای \f[CR]getInstance\f[R] در کلاس \f[CR]KeyStore\f[R] انتخاب کنند.
نوع keystore، ساختار ذخیره‌سازی و قالب داده‌های اطلاعات keystore و الگوریتم‌های مورد استفاده برای محافظت از کلیدهای خصوصی موجود در keystore و یکپارچگی خود keystore را مشخص می‌کند.
پیاده‌سازی‌های انواع مختلف keystore با یکدیگر سازگار نیستند.
.PP
دستورهای \f[CR]jarsigner\f[R] می‌توانند keystoreهای مبتنی بر فایل را از هر مکانی که با استفاده از یک URL قابل تعیین باشد، بخوانند.
علاوه بر این، این دستورها می‌توانند مخازن کلید غیرمبتنی بر فایل مانند موارد ارائه‌شده توسط MSCAPI در Windows و PKCS11 در تمامی پلتفرم‌ها را بخوانند.
.PP
برای دستورهای \f[CR]jarsigner\f[R] و \f[CR]keytool\f[R]، می‌توانید با استفاده از گزینه \f[CR]\-storetype\f[R] نوع keystore را در خط فرمان مشخص کنید.
.PP
اگر نوع keystore را به‌صراحت مشخص نکنید، ابزارها پیاده‌سازی keystore را بر اساس مقدار ویژگی \f[CR]keystore.type\f[R] مشخص‌شده در فایل ویژگی‌های امنیتی انتخاب می‌کنند.
فایل ویژگی‌های امنیتی \f[CR]java.security\f[R] نام دارد و در دایرکتوری ویژگی‌های امنیتی JDK یعنی \f[CR]java.home/conf/security\f[R] قرار دارد.
.PP
هر ابزار مقدار \f[CR]keystore.type\f[R] را دریافت کرده و سپس تمامی ارائه‌دهندگان نصب‌شده را بررسی می‌کند تا ارائه‌دهنده‌ای را بیابد که keystoreهایی از آن نوع را پیاده‌سازی می‌کند.
سپس از پیاده‌سازی keystore مربوط به آن ارائه‌دهنده استفاده می‌نماید.
.PP
کلاس \f[CR]KeyStore\f[R] یک متد ایستا به نام \f[CR]getDefaultType\f[R] تعریف می‌کند که به برنامه‌ها امکان بازیابی مقدار ویژگی \f[CR]keystore.type\f[R] را می‌دهد.
خط کد زیر، یک نمونه از نوع پیش‌فرض keystore را بر اساس آنچه در ویژگی \f[CR]keystore.type\f[R] مشخص شده، ایجاد می‌کند:
.RS
.PP
\f[CR]KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());\f[R]
.RE
.PP
نوع پیش‌فرض keystore مقدار \f[CR]pkcs12\f[R] است، که یک مخزن کلید چندسکویی بر پایه استاندارد RSA PKCS12 Personal Information Exchange Syntax می‌باشد.
این موضوع با خط زیر در فایل ویژگی‌های امنیتی مشخص شده است:
.RS
.PP
\f[CR]keystore.type=pkcs12\f[R]
.RE
.PP
بزرگی و کوچکی حروف در نام‌گذاری نوع keystore اهمیتی ندارد.
به عنوان مثال، \f[CR]JKS\f[R] با \f[CR]jks\f[R] یکسان است.
.PP
برای اینکه ابزارها از پیاده‌سازی دیگری از keystore به غیر از حالت پیش‌فرض استفاده کنند، می‌توانید آن خط را تغییر داده تا نوع دیگری از keystore مشخص شود.
به عنوان مثال، اگر می‌خواهید از پیاده‌سازی keystore نوع \f[CR]jks\f[R] متعلق به Oracle استفاده کنید، آن خط را به صورت زیر تغییر دهید:
.RS
.PP
\f[CR]keystore.type=jks\f[R]
.RE.SH "الگوریتم‌های پشتیبانی‌شده (SUPPORTED ALGORITHMS)"
به‌طور پیش‌فرض، دستور \f[CR]jarsigner\f[R] یک فایل JAR را بسته به نوع
و اندازه کلید خصوصی، با استفاده از یکی از الگوریتم‌ها و پسوندهای
فایل بلوک زیر امضا می‌کند:
.PP
الگوریتم‌های امضای پیش‌فرض و پسوندهای فایل بلوک
.TS
tab(@);
l l l l.
T{
keyalg
T}@T{
اندازه کلید
T}@T{
sigalg پیش‌فرض
T}@T{
پسوند فایل بلوک
T}
_
T{
DSA
T}@T{
هر اندازه‌ای
T}@T{
SHA256withDSA
T}@T{
\&.DSA
T}
T{
RSA
T}@T{
< 624
T}@T{
SHA256withRSA
T}@T{
\&.RSA
T}
T{
T}@T{
<= 7680
T}@T{
SHA384withRSA
T}@T{
T}
T{
T}@T{
> 7680
T}@T{
SHA512withRSA
T}@T{
T}
T{
EC
T}@T{
< 512
T}@T{
SHA384withECDSA
T}@T{
\&.EC
T}
T{
T}@T{
>= 512
T}@T{
SHA512withECDSA
T}@T{
T}
T{
RSASSA\-PSS[1]
T}@T{
< 624
T}@T{
RSASSA\-PSS (با SHA\-256)
T}@T{
\&.RSA
T}
T{
T}@T{
<= 7680
T}@T{
RSASSA\-PSS (با SHA\-384)
T}@T{
T}
T{
T}@T{
> 7680
T}@T{
RSASSA\-PSS (با SHA\-512)
T}@T{
T}
T{
EdDSA[2]
T}@T{
T}@T{
EdDSA
T}@T{
\&.EC
T}
T{
ML\-DSA[2]
T}@T{
T}@T{
ML\-DSA
T}@T{
\&.DSA
T}
.TE
.IP "1." 3
اگر یک کلید RSASSA\-PSS همراه با پارامترها کدگذاری شده باشد، jarsigner
از همان پارامترها در امضا استفاده خواهد کرد.
در غیر این صورت، jarsigner از پارامترهایی استفاده می‌کند که با توجه به
اندازه کلید طبق جدول بالا تعیین می‌شوند.
برای نمونه، یک کلید 3072 بیتی RSASSA\-PSS از RSASSA\-PSS به عنوان
الگوریتم امضا و از SHA\-384 به عنوان الگوریتم‌های هش و MGF1 استفاده خواهد کرد.
.IP "2." 3
الگوریتم‌های امضای دیجیتال مدرن مانند EdDSA و ML\-DSA از نام یکسانی
هم برای الگوریتم کلید و هم برای الگوریتم امضا استفاده می‌کنند.
تنها الگوریتم امضایی با همان نام می‌تواند با یک الگوریتم کلید مفروض
به کار گرفته شود.
مجموعه پارامترهای مشخص امضا (برای نمونه، Ed25519 یا Ed448 برای EdDSA)
همانند پارامترهای کلید است.
.PP
اگر الگوریتم یک کلید در این جدول فهرست نشده باشد، همواره از پسوند
فایل بلوک \f[CR].DSA\f[R] استفاده می‌شود.
.PP
این الگوریتم‌های امضای پیش‌فرض را می‌توان با استفاده از گزینهٔ
\f[CR]\-sigalg\f[R] بازنویسی کرد.
.PP
دستور \f[CR]jarsigner\f[R] از ویژگی‌های امنیتی
\f[CR]jdk.jar.disabledAlgorithms\f[R] و
\f[CR]jdk.security.legacyAlgorithms\f[R] برای تعیین این‌که کدام
الگوریتم‌ها یک مخاطره امنیتی به شمار می‌روند استفاده می‌کند.
اگر فایل JAR با هر یک از الگوریتم‌های غیرفعال‌شده امضا شده باشد، با آن
همانند یک فایل JAR امضانشده برخورد خواهد شد.
اگر فایل JAR با هر یک از الگوریتم‌های قدیمی (legacy) امضا شده باشد، با
آن به عنوان یک فایل امضاشده برخورد می‌شود، همراه با یک هشدار اطلاع‌رسانی
برای آگاه ساختن کاربران از این‌که الگوریتم قدیمی در به‌روزرسانی‌های
آینده غیرفعال خواهد شد.
برای دریافت خروجی اعتبارسنجی دقیق،
\f[CR]\-J\-Djava.security.debug=jar\f[R] را بگنجانید.
ویژگی‌های امنیتی \f[CR]jdk.jar.disabledAlgorithms\f[R] و
\f[CR]jdk.security.legacyAlgorithms\f[R] در فایل
\f[CR]java.security\f[R] (واقع در دایرکتوری
\f[CR]$JAVA_HOME/conf/security\f[R] مربوط به JDK) تعریف شده‌اند.
.PP
\f[B]نکته:\f[R]
.PP
برای ارتقای امنیت در حالت پیش‌فرض (out of the box)، اندازه کلید و نام‌های
الگوریتم امضای پیش‌فرض به طور دوره‌ای در هر انتشار JDK به مقادیر قوی‌تری
به‌روزرسانی می‌شوند.
اگر سازگاری با انتشار‌های قدیمی‌تر JDK اهمیت دارد، لطفاً مطمئن شوید
که مقادیر پیش‌فرض توسط آن نسخه‌ها پشتیبانی می‌شوند، یا در غیر این صورت،
با مسئولیت خودتان از گزینهٔ \f[CR]\-sigalg\f[R] برای بازنویسی مقادیر
پیش‌فرض استفاده کنید..SH "فایل JAR امضاشده (THE SIGNED JAR FILE)"
هنگامی که دستور \f[CR]jarsigner\f[R] برای امضای یک فایل JAR استفاده می‌شود، فایل JAR امضاشده‌ی خروجی دقیقاً همانند فایل JAR ورودی است، با این تفاوت که دو فایل اضافی در دایرکتوری META\-INF قرار می‌گیرند:
.IP \(bu 2
یک فایل امضا با پسوند \f[CR].SF\f[R]
.IP \(bu 2
یک فایل بلوک امضا با پسوند \f[CR].DSA\f[R]، \f[CR].RSA\f[R] یا
\f[CR].EC\f[R]
.PP
نام پایه برای این دو فایل از مقدار گزینهٔ
\f[CR]\-sigfile\f[R] گرفته می‌شود.
برای مثال، هنگامی که گزینه به‌صورت \f[CR]\-sigfile MKSIGN\f[R] باشد، فایل‌ها
\f[CR]MKSIGN.SF\f[R] و \f[CR]MKSIGN.RSA\f[R] نام‌گذاری می‌شوند.
در این مستند، فرض بر این است که امضاکننده همواره از یک کلید RSA استفاده می‌کند.
.PP
اگر گزینهٔ \f[CR]\-sigfile\f[R] در خط فرمان مشخص نشود، نام پایه برای فایل \f[CR].SF\f[R] و فایل‌های بلوک امضا، ۸ نویسهٔ نخست نام مستعار (alias) تعیین‌شده در خط فرمان خواهد بود که همگی به حروف بزرگ تبدیل می‌شوند.
اگر نام مستعار کمتر از ۸ نویسه داشته باشد، کل نام مستعار به کار می‌رود.
اگر نام مستعار دارای هرگونه نویسه‌ای باشد که در نام فایل امضا مجاز نیست، هر یک از این نویسه‌ها هنگام ایجاد نام فایل به نویسهٔ خط زیر (_) تبدیل می‌شوند.
نویسه‌های مجاز شامل حروف، ارقام، خط زیر و خط تیره هستند.
.SH "فایل امضا (SIGNATURE FILE)"
یک فایل امضا (فایل \f[CR].SF\f[R]) ساختاری شبیه به فایل مانیفست دارد که همواره در زمان استفاده از دستور \f[CR]jarsigner\f[R] برای امضای فایل، در فایل JAR گنجانده می‌شود.
به ازای هر فایل مبدأ موجود در فایل JAR، فایل \f[CR].SF\f[R] همانند فایل مانیفست دارای دو خط است که موارد زیر را فهرست می‌کند:
.IP \(bu 2
نام فایل
.IP \(bu 2
نام الگوریتم چکیده‌ساز (SHA)
.IP \(bu 2
مقدار چکیدهٔ SHA
.PP
\f[B]نکته:\f[R]
.PP
نام الگوریتم چکیده‌ساز (SHA) و مقدار چکیدهٔ SHA در یک خط قرار دارند.
.PP
در فایل مانیفست، مقدار چکیدهٔ SHA برای هر فایل مبدأ، چکیده (هش) داده‌های باینری درون آن فایل مبدأ است.
در فایل \f[CR].SF\f[R]، مقدار چکیده برای یک فایل مبدأ مشخص، هشِ دو خطِ مربوط به آن فایل مبدأ در فایل مانیفست است.
.PP
فایل امضا به‌طور پیش‌فرض شامل یک سرآیند (header) است که هش کل فایل مانیفست را در بر دارد.
این سرآیند همچنین حاوی هش سرآیند مانیفست است.
وجود این سرآیند بهینه‌سازی فرایند اعتبارسنجی را ممکن می‌سازد.
بخش \f[B]اعتبارسنجی فایل JAR (JAR File Verification)\f[R] را ببینید.
.SH "فایل بلوک امضا (SIGNATURE BLOCK FILE)"
فایل \f[CR].SF\f[R] امضا شده و امضا درون فایل بلوک امضا قرار می‌گیرد.
این فایل همچنین حاوی گواهی یا زنجیرهٔ گواهی کدگذاری‌شده از keystore است که کلید عمومی متناظر با کلید خصوصیِ استفاده‌شده برای امضا را احراز هویت می‌کند.
بسته به الگوریتم کلیدِ استفاده‌شده، این فایل دارای پسوند \f[CR].DSA\f[R]، \f[CR].RSA\f[R] یا
\f[CR].EC\f[R] است.
جدول موجود در بخش \f[B]Supported Algorithms\f[R] را ببینید.
.SH "برچسب زمانی امضا (SIGNATURE TIME STAMP)"
دستور \f[CR]jarsigner\f[R] در صورت استفاده با گزینه‌های زیر، هنگام امضای یک فایل JAR، یک برچسب زمانی امضا (timestamp) تولید و ذخیره می‌کند:
.IP \(bu 2
\f[CR]\-tsa\f[R] \f[I]url\f[R]
.IP \(bu 2
\f[CR]\-tsacert\f[R] \f[I]alias\f[R]
.IP \(bu 2
\f[CR]\-tsapolicyid\f[R] \f[I]policyid\f[R]
.IP \(bu 2
\f[CR]\-tsadigestalg\f[R] \f[I]algorithm\f[R]
.PP
بخش \f[B]Options for jarsigner\f[R] را ببینید.
.SH "اعتبارسنجی فایل JAR (JAR FILE VERIFICATION)"
اعتبارسنجی موفق فایل JAR زمانی رخ می‌دهد که امضاها معتبر باشند و هیچ‌یک از فایل‌هایی که هنگام تولید امضاها درون فایل JAR بوده‌اند، از آن زمان به بعد تغییر نکرده باشند.
اعتبارسنجی فایل JAR شامل مراحل زیر است:
.IP "1." 3
اعتبارسنجی امضای فایل \f[CR].SF\f[R].
.RS 4
.PP
این اعتبارسنجی اطمینان حاصل می‌کند که امضای ذخیره‌شده در هر فایل بلوک امضا، با استفاده از کلید خصوصی متناظر با کلید عمومی‌ای تولید شده است که گواهی (یا زنجیرهٔ گواهی) آن نیز در فایل بلوک امضا قرار دارد.
همچنین اطمینان می‌دهد که امضا، یک امضای معتبر از فایل امضای متناظر (\f[CR].SF\f[R]) است و در نتیجه فایل \f[CR].SF\f[R] دستکاری نشده است.
.RE
.IP "2." 3
اعتبارسنجی چکیدهٔ فهرست‌شده در هر مدخل فایل \f[CR].SF\f[R] با بخش متناظر آن در مانیفست.
.RS 4
.PP
فایل \f[CR].SF\f[R] به‌طور پیش‌فرض شامل سرآیندی است که حاوی هش کل فایل مانیفست است.
هنگامی که این سرآیند وجود دارد، اعتبارسنجی می‌تواند بررسی کند که آیا هش موجود در سرآیند با هش فایل مانیفست مطابقت دارد یا خیر.
در صورت تطابق، فرایند اعتبارسنجی به مرحلهٔ بعد می‌رود.
.PP
در صورت عدم تطابق، یک اعتبارسنجی با بهینه‌سازی کمتر مورد نیاز است تا اطمینان حاصل شود که هش موجود در بخش اطلاعات هر فایل مبدأ در فایل \f[CR].SF\f[R] با هش بخش متناظر آن در فایل مانیفست برابر است.
بخش \f[B]فایل امضا (SIGNATURE FILE)\f[R] را ببینید.
.PP
یک دلیل برای اینکه هش فایل مانیفست ذخیره‌شده در سرآیند فایل \f[CR].SF\f[R] ممکن است با هش فایل مانیفست فعلی برابر نباشد این است که مانیفست ممکن است حاوی بخش‌هایی برای فایل‌هایی باشد که پس از امضا شدن فایل، به آن اضافه شده‌اند.
برای مثال، فرض کنید یک یا چند فایل (با استفاده از ابزار \f[CR]jar\f[R]) به فایل JAR امضاشده‌ای اضافه شده‌اند که از پیش حاوی یک امضا و یک فایل \f[CR].SF\f[R] است.
اگر فایل JAR دوباره توسط امضاکنندهٔ دیگری امضا شود، فایل مانیفست تغییر می‌کند (بخش‌هایی برای فایل‌های جدید توسط ابزار \f[CR]jarsigner\f[R] به آن اضافه می‌شود) و یک فایل \f[CR].SF\f[R] جدید ایجاد می‌شود، اما فایل \f[CR].SF\f[R] اصلی بدون تغییر باقی می‌ماند.
اگر هیچ‌یک از فایل‌هایی که در زمان ایجاد امضای اولیه در فایل JAR بودند از آن زمان تغییر نکرده باشند، اعتبارسنجی همچنان موفق در نظر گرفته می‌شود.
دلیل این امر این است که هش‌های موجود در بخش‌های غیرسرآیند فایل \f[CR].SF\f[R] با هش‌های بخش‌های متناظر در فایل مانیفست برابر هستند.
.RE
.IP "3." 3
خواندن هر فایل در فایل JAR که مدخلی در فایل \f[CR].SF\f[R] دارد.
هنگام خواندن، چکیدهٔ فایل را محاسبه کرده و نتیجه را با چکیدهٔ این فایل در بخش مانیفست مقایسه کنید.
چکیده‌ها باید یکسان باشند، در غیر این صورت اعتبارسنجی با شکست مواجه می‌شود.
.RS 4
.PP
اگر هرگونه خطای جدی در طول فرایند اعتبارسنجی رخ دهد، فرایند متوقف شده و یک استثنای امنیتی (security exception) صادر می‌شود.
دستور \f[CR]jarsigner\f[R] این استثنا را دریافت کرده و نمایش می‌دهد.
.RE
.IP "4." 3
بررسی استفاده از الگوریتم‌های غیرفعال‌شده.
بخش \f[B]Supported Algorithms\f[R] را ببینید.
.PP
\f[B]نکته:\f[R]
.PP
شما باید هشدارهای اضافی (یا در صورت تعیین گزینهٔ \f[CR]\-strict\f[R]، خطاها) و همچنین محتوای گواهی را (با تعیین گزینه‌های \f[CR]\-verbose\f[R] و \f[CR]\-certs\f[R]) بررسی و مطالعه کنید تا مشخص شود که آیا می‌توان به امضا اعتماد کرد یا خیر..SH "چندین امضا برای یک فایل JAR (MULTIPLE SIGNATURES FOR A JAR FILE)"
یک فایل JAR می‌تواند توسط چندین نفر امضا شود؛ به این صورت که دستور
\f[CR]jarsigner\f[R] چندین بار بر روی فایل اجرا شده و هر بار نام مستعار (alias)
فرد متفاوتی مشخص گردد، به شرح زیر:
.IP
.EX
jarsigner myBundle.jar susan
jarsigner myBundle.jar kevin
.EE
.PP
هنگامی که یک فایل JAR چندین بار امضا می‌شود، چندین فایل \f[CR].SF\f[R] و بلوک
امضا در فایل JAR حاصل وجود خواهد داشت؛ یعنی یک جفت برای هر امضا.
در مثال قبلی، فایل JAR خروجی شامل فایل‌هایی با نام‌های زیر است:
.IP
.EX
SUSAN.SF
SUSAN.RSA
KEVIN.SF
KEVIN.RSA
.EE
.SH "گزینه‌های JARSIGNER (OPTIONS FOR JARSIGNER)"
بخش‌های زیر گزینه‌های \f[CR]jarsigner\f[R] را شرح می‌دهند.
از استانداردهای زیر آگاه باشید:
.IP \(bu 2
نام تمامی گزینه‌ها با یک علامت خط پیوند (\-) آغاز می‌شود.
.IP \(bu 2
گزینه‌ها را می‌توان به هر ترتیبی ارائه داد.
.IP \(bu 2
مواردی که با حروف کج (ایتالیک) یا زیرخط‌دار مشخص شده‌اند (مقادیر گزینه‌ها) نشان‌دهنده
مقادیر واقعی هستند که باید وارد شوند.
.IP \(bu 2
گزینه‌های \f[CR]\-storepass\f[R]، \f[CR]\-keypass\f[R]، \f[CR]\-sigfile\f[R]،
\f[CR]\-sigalg\f[R]، \f[CR]\-digestalg\f[R]، \f[CR]\-signedjar\f[R] و گزینه‌های
مرتبط با TSA فقط هنگام امضای فایل JAR کاربرد دارند؛ آن‌ها هنگام اعتبارسنجی یک
فایل JAR امضاشده کاربردی ندارند.
گزینه \f[CR]\-keystore\f[R] برای امضا و اعتبارسنجی فایل JAR قابل استفاده است.
علاوه بر این، هنگام امضا و اعتبارسنجی فایل JAR، نام‌های مستعار نیز مشخص می‌شوند.
.TP
\f[CR]\-keystore\f[R] \f[I]url\f[R]
نشانی اینترنتی (URL) مکان keystore را مشخص می‌کند.
مقدار پیش‌فرض آن فایل \f[CR].keystore\f[R] در دایرکتوری خانگی کاربر است که
توسط ویژگی سیستمی \f[CR]user.home\f[R] تعیین می‌شود.
.RS
هنگام امضا کردن، وجود یک keystore الزامی است.
در صورتی که keystore پیش‌فرض وجود نداشته باشد یا بخواهید از keystore دیگری غیر
از پیش‌فرض استفاده کنید، باید صریحاً آن را مشخص نمایید.
هنگام اعتبارسنجی نیازی به keystore نیست، اما اگر keystore مشخص شده باشد یا
پیش‌فرض موجود باشد و گزینه \f[CR]\-verbose\f[R] نیز قید شده باشد، اطلاعات
بیشتری در خروجی نمایش داده می‌شود مبنی بر این‌که آیا گواهی‌های استفاده‌شده برای
اعتبارسنجی فایل JAR درون آن keystore موجود هستند یا خیر.
آرگومان \f[CR]\-keystore\f[R] می‌تواند به جای URL، یک نام فایل و مسیر مشخص
باشد که در این صورت مانند یک URL از نوع file: با آن رفتار می‌شود؛ برای مثال
موارد زیر معادل یکدیگر هستند:
.IP \(bu 2
\f[CR]\-keystore\f[R] \f[I]filePathAndName\f[R]
.IP \(bu 2
\f[CR]\-keystore file:\f[R]\f[I]filePathAndName\f[R]
اگر ارائه‌دهنده Sun PKCS #11 در فایل ویژگی‌های امنیتی \f[CR]java.security\f[R]
(واقع در دایرکتوری \f[CR]$JAVA_HOME/conf/security\f[R] متعلق به JDK) پیکربندی
شده باشد، ابزارهای \f[CR]keytool\f[R] و \f[CR]jarsigner\f[R] می‌توانند با
مشخص کردن این گزینه‌ها روی توکن PKCS #11 عمل کنند:
.RS
.PP
\f[CR]\-keystore NONE \-storetype PKCS11\f[R]
.RE
برای مثال، دستور زیر محتویات توکن PKCS#11 پیکربندی‌شده را فهرست می‌کند:
.RS
.PP
\f[CR]keytool \-keystore NONE \-storetype PKCS11 \-list\f[R]
.RE
.RE
.TP
\f[CR]\-storepass\f[R] [\f[CR]:env\f[R] | \f[CR]:file\f[R]] \f[I]argument\f[R]
گذرواژه‌ای را که برای دسترسی به keystore لازم است مشخص می‌کند.
این مورد فقط هنگام امضا کردن (نه اعتبارسنجی) یک فایل JAR مورد نیاز است.
در این صورت، اگر گزینه \f[CR]\-storepass\f[R] در خط فرمان ارائه نشود، از
کاربر خواسته می‌شود تا گذرواژه را وارد کند.
.RS
اگر اصلاح‌کننده \f[CR]env\f[R] یا \f[CR]file\f[R] مشخص نشده باشد، مقدار گذرواژه
برابر با \f[CR]argument\f[R] خواهد بود.
در غیر این صورت، گذرواژه به شرح زیر بازیابی می‌شود:
.IP \(bu 2
\f[CR]env\f[R]: گذرواژه را از متغیر محیطی با نام \f[I]argument\f[R] بازیابی می‌کند.
.IP \(bu 2
\f[CR]file\f[R]: گذرواژه را از فایلی با نام \f[I]argument\f[R] بازیابی می‌کند.
\f[B]نکته:\f[R]
گذرواژه نباید در خط فرمان یا در یک اسکریپت مشخص شود، مگر این‌که برای اهداف آزمایشی
بوده یا در یک سیستم امن قرار داشته باشید.
.RE
.TP
\f[CR]\-storetype\f[R] \f[I]storetype\f[R]
نوع keystore را که باید نمونه‌سازی شود مشخص می‌کند.
نوع پیش‌فرض keystore مقداری است که به عنوان مقدار ویژگی \f[CR]keystore.type\f[R]
در فایل ویژگی‌های امنیتی تعیین شده است و توسط متد ایستا \f[CR]getDefaultType\f[R]
در \f[CR]java.security.KeyStore\f[R] بازگردانده می‌شود.
.RS
پین (PIN) برای یک توکن PKCS #11 نیز می‌تواند با گزینه \f[CR]\-storepass\f[R]
مشخص شود.
اگر چیزی مشخص نشود، دستورهای \f[CR]keytool\f[R] و \f[CR]jarsigner\f[R] پین
توکن را درخواست می‌کنند.
اگر توکن دارای مسیر احراز هویت محافظت‌شده باشد (مانند یک صفحه کلید اختصاصی PIN
یا حسگر بیومتریک)، باید گزینه \f[CR]\-protected\f[R] مشخص شود و هیچ گزینه
گذرواژه‌ای نمی‌تواند تعیین گردد.
.RE
.TP
\f[CR]\-keypass\f[R] [\f[CR]:env\f[R] | \f[CR]:file\f[R]] \f[I]argument\f[R] \f[CR]\-certchain\f[R] \f[I]file\f[R]
گذرواژه مورد استفاده برای محافظت از کلید خصوصی مدخل keystore را که با نام مستعار
مشخص‌شده در خط فرمان آدرس‌دهی می‌شود، مشخص می‌کند.
هنگام استفاده از \f[CR]jarsigner\f[R] برای امضا کردن یک فایل JAR، این گذرواژه
الزامی است.
اگر هیچ گذرواژه‌ای در خط فرمان ارائه نشود و گذرواژه مورد نیاز با گذرواژه keystore
متفاوت باشد، از کاربر خواسته می‌شود آن را وارد کند.
.RS
اگر اصلاح‌کننده \f[CR]env\f[R] یا \f[CR]file\f[R] مشخص نشده باشد، مقدار گذرواژه
برابر با \f[CR]argument\f[R] خواهد بود.
در غیر این صورت، گذرواژه به شرح زیر بازیابی می‌شود:
.IP \(bu 2
\f[CR]env\f[R]: گذرواژه را از متغیر محیطی با نام \f[I]argument\f[R] بازیابی می‌کند.
.IP \(bu 2
\f[CR]file\f[R]: گذرواژه را از فایلی با نام \f[I]argument\f[R] بازیابی می‌کند.
\f[B]نکته:\f[R]
گذرواژه نباید در خط فرمان یا در یک اسکریپت مشخص شود، مگر این‌که برای اهداف آزمایشی
بوده یا در یک سیستم امن قرار داشته باشید.
.RE
.TP
\f[CR]\-certchain\f[R] \f[I]file\f[R]
زنجیره گواهی مورد استفاده را در زمانی که زنجیره گواهی مرتبط با کلید خصوصی مدخل
keystore (که با نام مستعار ارائه‌شده در خط فرمان آدرس‌دهی شده) کامل نیست،
مشخص می‌کند.
این حالت زمانی رخ می‌دهد که keystore روی یک توکن سخت‌افزاری قرار داشته باشد و
ظرفیت کافی برای نگهداری زنجیره گواهی کامل وجود نداشته باشد.
فایل می‌تواند توالی‌ای از گواهی‌های الحاق‌شده‌ی X.509 یا یک بلوک داده با قالب
PKCS#7 باشد، چه در قالب کدگذاری باینری و چه در قالب کدگذاری قابل‌چاپ (که به
نام کدگذاری Base64 نیز شناخته می‌شود) آن‌گونه که توسط
\f[B]Internet RFC 1421 Certificate Encoding Standard\f[R]
[http://tools.ietf.org/html/rfc1421] تعریف شده است.
.TP
\f[CR]\-sigfile\f[R] \f[I]file\f[R]
نام فایل پایه‌ای را که باید برای فایل‌های \f[CR].SF\f[R] و بلوک امضای تولیدشده
استفاده شود مشخص می‌کند.
برای مثال، اگر file برابر با \f[CR]DUKESIGN\f[R] باشد، فایل‌های \f[CR].SF\f[R]
و بلوک امضای تولیدشده با نام‌های \f[CR]DUKESIGN.SF\f[R] و \f[CR]DUKESIGN.RSA\f[R]
نام‌گذاری شده و در دایرکتوری \f[CR]META\-INF\f[R] فایل JAR امضاشده قرار می‌گیرند.
.RS
نویسه‌های موجود در file باید از مجموعه \f[CR]a\-zA\-Z0\-9_\-\f[R] باشند.
تنها حروف، اعداد، زیرخط و خط پیوند مجاز هستند.
تمامی نویسه‌های کوچک برای نام‌های فایل‌های \f[CR].SF\f[R] و بلوک امضا به حروف
بزرگ تبدیل می‌شوند.
اگر گزینه \f[CR]\-sigfile\f[R] در خط فرمان مشخص نشود، نام فایل پایه برای
فایل‌های \f[CR].SF\f[R] و بلوک امضا، ۸ نویسه اول نام مستعار مشخص‌شده در خط
فرمان خواهد بود که همگی به حروف بزرگ تبدیل می‌شوند.
اگر نام مستعار کمتر از ۸ نویسه داشته باشد، کل نام مستعار استفاده می‌شود.
اگر نام مستعار شامل نویسه‌هایی باشد که در نام فایل امضا معتبر نیستند، هر یک از
این نویسه‌ها برای تشکیل نام فایل به یک نویسه زیرخط (_) تبدیل می‌شوند.
.RE
.TP
\f[CR]\-signedjar\f[R] \f[I]file\f[R]
نام فایل JAR امضاشده را مشخص می‌کند.
.TP
\f[CR]\-digestalg\f[R] \f[I]algorithm\f[R]
نام الگوریتم خلاصه پیام را برای استفاده هنگام خلاصه‌سازی مدخل‌های یک فایل JAR
مشخص می‌کند.
.RS
برای فهرستی از نام‌های استاندارد الگوریتم‌های خلاصه پیام، به Java Security
Standard Algorithm Names Specification مراجعه کنید.
اگر این گزینه مشخص نشود، از \f[CR]SHA\-384\f[R] استفاده می‌شود.
باید یا یک ارائه‌دهنده که به صورت ایستا نصب شده پیاده‌سازی الگوریتم مشخص‌شده را
فراهم کند، یا کاربر باید با گزینه‌های \f[CR]\-addprovider\f[R] یا
\f[CR]\-providerClass\f[R] یکی را مشخص کند؛ در غیر این صورت، دستور با موفقیت
اجرا نخواهد شد.
.RE.TP
\f[CR]\-sigalg\f[R] \f[I]algorithm\f[R]
نام الگوریتم امضا را برای استفاده جهت امضای فایل JAR مشخص می‌کند.
.RS
این الگوریتم باید با کلید خصوصی به‌کاررفته برای امضای فایل JAR سازگار باشد.
اگر این گزینه مشخص نشود، از یک الگوریتم پیش‌فرض متناسب با کلید خصوصی، همان‌طور که در بخش \f[B]Supported Algorithms\f[R] شرح داده شده است، استفاده می‌شود.
باید یا یک ارائه‌دهنده (provider) به‌صورت ایستا نصب شده باشد که پیاده‌سازی الگوریتم مشخص‌شده را ارائه دهد، یا باید ارائه‌دهنده‌ای را با گزینهٔ \f[CR]\-addprovider\f[R] یا \f[CR]\-providerClass\f[R] مشخص کنید؛ در غیر این صورت دستور با موفقیت اجرا نخواهد شد.
برای مشاهدهٔ فهرستی از نام‌های استاندارد الگوریتم‌های امضا، به مشخصات Java Security Standard Algorithm Names Specification مراجعه کنید.
.RE
.TP
\f[CR]\-verify\f[R]
یک فایل JAR امضاشده را وارسی می‌کند.
.TP
\f[CR]\-verbose\f[R][\f[CR]:\f[R]\f[I]suboptions\f[R]]
هنگامی که گزینهٔ \f[CR]\-verbose\f[R] در خط فرمان مشخص شود، نشان می‌دهد که \f[CR]jarsigner\f[R] در زمان امضا یا وارسی از حالت پرگو استفاده می‌کند، که در آن زیرگزینه‌ها میزان اطلاعات ارائه‌شده را مشخص می‌کنند.
این کار باعث می‌شود که \f[CR]jarsigner\f[R] اطلاعات بیشتری دربارهٔ روند پیشرفت امضا یا وارسی JAR ارائه دهد.
زیرگزینه‌ها (\f[I]suboptions\f[R]) می‌توانند \f[CR]all\f[R]، \f[CR]grouped\f[R] یا \f[CR]summary\f[R] باشند.
.RS
اگر گزینهٔ \f[CR]\-certs\f[R] نیز مشخص شده باشد، حالت پیش‌فرض (یا زیرگزینهٔ \f[CR]all\f[R]) هر ورودی را در حین پردازش، و پس از آن، اطلاعات گواهی هر امضاکنندهٔ فایل JAR را نمایش می‌دهد.
اگر گزینهٔ \f[CR]\-certs\f[R] و زیرگزینهٔ \f[CR]\-verbose:grouped\f[R] مشخص شده باشند، ورودی‌های دارای اطلاعات امضاکنندهٔ یکسان گروه‌بندی شده و همراه با اطلاعات گواهی‌شان با هم نمایش داده می‌شوند.
اگر گزینهٔ \f[CR]\-certs\f[R] و زیرگزینهٔ \f[CR]\-verbose:summary\f[R] مشخص شده باشند، ورودی‌های دارای اطلاعات امضاکنندهٔ یکسان گروه‌بندی شده و همراه با اطلاعات گواهی‌شان نمایش داده می‌شوند.
جزئیات مربوط به هر ورودی خلاصه‌سازی شده و به‌صورت \f[I]one entry (and more)\f[R] نمایش می‌یابد.
بخش‌های \f[B]Example of Verifying a Signed JAR File\f[R] و \f[B]Example of Verification with Certificate Information\f[R] را ببینید.
.RE
.TP
\f[CR]\-certs\f[R]
اگر گزینهٔ \f[CR]\-certs\f[R] همراه با گزینه‌های \f[CR]\-verify\f[R] و \f[CR]\-verbose\f[R] در خط فرمان ظاهر شود، خروجی شامل اطلاعات گواهی برای هر امضاکنندهٔ فایل JAR خواهد بود.
این اطلاعات شامل نام نوع گواهی (ذخیره‌شده در فایل بلوک امضا) است که کلید عمومی امضاکننده را تأیید می‌کند، و در صورتی که گواهی از نوع X.509 باشد (نمونه‌ای از \f[CR]java.security.cert.X509Certificate\f[R])، نام متمایز (distinguished name) امضاکننده را نیز در بر می‌گیرد.
.RS
مخزن کلید (keystore) نیز بررسی می‌شود.
اگر هیچ مقداری برای مخزن کلید در خط فرمان تعیین نشده باشد، فایل پیش‌فرض مخزن کلید (در صورت وجود) بررسی می‌شود.
اگر گواهی کلید عمومیِ یک امضاکننده با ورودی‌ای در مخزن کلید مطابقت داشته باشد، نام مستعار (alias) آن ورودی در مخزن کلید برای آن امضاکننده درون پرانتز نمایش داده می‌شود.
.RE
.TP
\f[CR]\-revCheck\f[R]
این گزینه بررسی ابطال گواهی‌ها را هنگام امضا یا وارسی یک فایل JAR فعال می‌کند.
اگر گزینهٔ \f[CR]\-revCheck\f[R] در خط فرمان مشخص شده باشد، دستور \f[CR]jarsigner\f[R] تلاش می‌کند تا برای واکشی پاسخ‌های OCSP و CRLها اتصالات شبکه‌ای برقرار کند.
توجه داشته باشید که بررسی‌های ابطال فعال نمی‌شوند مگر اینکه این گزینه مشخص شده باشد.
.TP
\f[CR]\-tsa\f[R] \f[I]url\f[R]
اگر \f[CR]\-tsa http://example.tsa.url\f[R] در هنگام امضای یک فایل JAR در خط فرمان ظاهر شود، یک برچسب زمان (time stamp) برای امضا تولید می‌شود.
نشانی اینترنتی \f[CR]http://example.tsa.url\f[R] مکان مرجع برچسب‌گذاری زمان (TSA) را مشخص می‌کند و بر هر نشانی یافت‌شده توسط گزینهٔ \f[CR]\-tsacert\f[R] اولویت دارد.
گزینهٔ \f[CR]\-tsa\f[R] نیازی به وجود گواهی کلید عمومی TSA در مخزن کلید ندارد.
.RS
برای تولید برچسب زمان، \f[CR]jarsigner\f[R] با استفاده از پروتکل برچسب زمانی (Time\-Stamp Protocol یا TSP) تعریف‌شده در RFC 3161 با TSA ارتباط برقرار می‌کند.
در صورت موفقیت، توکن برچسب زمانِ بازگردانده‌شده از TSA همراه با امضا در فایل بلوک امضا ذخیره می‌شود.
.RE
.TP
\f[CR]\-tsacert\f[R] \f[I]alias\f[R]
هنگامی که \f[CR]\-tsacert\f[R] \f[I]alias\f[R] در زمان امضای یک فایل JAR در خط فرمان مشخص شود، یک برچسب زمان برای امضا تولید می‌شود.
نام مستعار (alias)، گواهی کلید عمومی TSA را در مخزن کلید فعال مشخص می‌کند.
گواهیِ ورودی برای یافتن افزونهٔ Subject Information Access که حاوی یک نشانی اینترنتی جهت تعیین مکان TSA است، بررسی می‌شود.
.RS
هنگام استفاده از گزینهٔ \f[CR]\-tsacert\f[R]، گواهی کلید عمومی TSA باید در مخزن کلید موجود باشد.
.RE
.TP
\f[CR]\-tsapolicyid\f[R] \f[I]policyid\f[R]
شناسهٔ شیء (OID) را مشخص می‌کند که شناسهٔ خط‌مشی ارسالی به کارساز TSA را تعیین می‌نماید.
اگر این گزینه مشخص نشود، هیچ شناسهٔ خط‌مشی‌ای ارسال نمی‌شود و کارساز TSA یک شناسهٔ خط‌مشی پیش‌فرض را انتخاب خواهد کرد.
.RS
شناسه‌های شیء توسط X.696 تعریف شده‌اند که یک استاندارد بخش استانداردسازی مخابرات ITU (به‌اختصار ITU\-T) است.
این شناسه‌ها معمولاً مجموعه‌هایی از ارقام غیرمنفی جداشده با نقطه هستند؛ مانند \f[CR]1.2.3.4\f[R].
.RE
.TP
\f[CR]\-tsadigestalg\f[R] \f[I]algorithm\f[R]
الگوریتم خلاصهٔ پیام (message digest) را که برای ایجاد نقش پیام ارسالی به کارساز TSA استفاده می‌شود، مشخص می‌کند.
اگر این گزینه مشخص نشود، از SHA\-384 استفاده خواهد شد.
.RS
بخش \f[B]Supported Algorithms\f[R] را ببینید.
برای مشاهدهٔ فهرستی از نام‌های استاندارد الگوریتم‌های خلاصهٔ پیام، به مشخصات Java Security Standard Algorithm Names Specification مراجعه کنید.
.RE
.TP
\f[CR]\-internalsf\f[R]
در گذشته، فایل بلوک امضا که هنگام امضای فایل JAR تولید می‌شد، شامل یک نسخهٔ رمزگذاری‌شدهٔ کامل از فایل \f[CR].SF\f[R] (فایل امضا) بود که آن نیز تولید می‌شد.
این رفتار تغییر یافته است.
به منظور کاهش حجم کلی فایل JAR خروجی، فایل بلوک امضا به‌طور پیش‌فرض دیگر حاوی نسخه‌ای از فایل \f[CR].SF\f[R] نیست.
اگر \f[CR]\-internalsf\f[R] در خط فرمان مشخص شود، از رفتار قدیمی استفاده خواهد شد.
این گزینه برای آزمایش کاربرد دارد.
در عمل، از گزینهٔ \f[CR]\-internalsf\f[R] استفاده نکنید زیرا سربار بیشتری را تحمیل می‌کند.
.TP
\f[CR]\-sectionsonly\f[R]
اگر گزینهٔ \f[CR]\-sectionsonly\f[R] در خط فرمان مشخص شود، فایل \f[CR].SF\f[R] (فایل امضا) که هنگام امضای فایل JAR تولید می‌شود، شامل سرآیندی که حاوی هش کل فایل مانیفست است نخواهد بود.
این فایل تنها شامل اطلاعات و هش‌های مربوط به هر یک از فایل‌های مبدأ موجود در فایل JAR خواهد بود.
بخش Signature File را ببینید.
.RS
به‌طور پیش‌فرض، این سرآیند جهت بهینه‌سازی افزوده می‌شود.
هنگامی که سرآیند وجود دارد، هر بار که فایل JAR وارسی می‌شود، وارسی می‌تواند ابتدا بررسی کند که آیا هش موجود در سرآیند با هش کل فایل مانیفست مطابقت دارد یا خیر.
در صورت تطابق، وارسی به مرحلهٔ بعد می‌رود.
در صورت عدم تطابق، لازم است وارسیِ کم‌تر بهینه‌ای انجام شود تا بررسی گردد که آیا هشِ بخشِ اطلاعاتِ هر فایل مبدأ در فایل \f[CR].SF\f[R] با هش بخش متناظر آن در فایل مانیفست برابر است یا خیر.
بخش \f[B]JAR File Verification\f[R] را ببینید.
گزینهٔ \f[CR]\-sectionsonly\f[R] عمدتاً برای آزمایش استفاده می‌شود.
این گزینه نباید برای مقاصدی غیر از آزمایش استفاده شود، زیرا استفاده از آن سربار بالاتری در پی دارد.
.RE
.TP
\f[CR]\-protected\f[R]
مقادیر می‌توانند \f[CR]true\f[R] یا \f[CR]false\f[R] باشند.
هنگامی که گذرواژه باید از طریق یک مسیر احراز هویت محافظت‌شده مانند یک PINخوان اختصاصی مشخص شود، مقدار \f[CR]true\f[R] را تعیین کنید.
.TP
\f[CR]\-providerName\f[R] \f[I]providerName\f[R]
اگر بیش از یک ارائه‌دهنده در فایل ویژگی‌های امنیتی \f[CR]java.security\f[R] پیکربندی شده باشد، می‌توانید از گزینهٔ \f[CR]\-providerName\f[R] برای هدف قرار دادن یک نمونه ارائه‌دهندهٔ خاص استفاده کنید.
آرگومان این گزینه نام ارائه‌دهنده است.
.RS
برای ارائه‌دهندهٔ Oracle PKCS #11، مقدار \f[I]providerName\f[R] به‌صورت \f[CR]SunPKCS11\-\f[R]\f[I]TokenName\f[R] است، که در آن \f[I]TokenName\f[R] پسوند نامی است که نمونه ارائه‌دهنده با آن پیکربندی شده است، همان‌طور که در جدول ویژگی‌های پیکربندی با جزئیات آمده است.
برای نمونه، دستور زیر محتویات نمونه ارائه‌دهندهٔ مخزن کلید \f[CR]PKCS #11\f[R] با پسوند نام \f[CR]SmartCard\f[R] را فهرست می‌کند:
.RS.PP
\f[CR]jarsigner \-keystore NONE \-storetype PKCS11 \-providerName SunPKCS11\-SmartCard \-list\f[R]
.RE
.RE
.TP
\f[CR]\-addprovider\f[R] \f[I]name\f[R] [\f[CR]\-providerArg\f[R] \f[I]arg\f[R]]
یک ارائه‌دهنده امنیتی را بر اساس نام (مانند SunPKCS11) و یک آرگومان پیکربندی اختیاری اضافه می‌کند.
مقدار ارائه‌دهنده امنیتی، نام ارائه‌دهنده‌ای امنیتی است که در یک ماژول تعریف شده است.
.RS
در صورت استفاده به همراه گزینهٔ \f[CR]\-providerArg ConfigFilePath\f[R]،
ابزارهای \f[CR]keytool\f[R] و \f[CR]jarsigner\f[R] ارائه‌دهنده را به‌صورت پویا نصب کرده
و از \f[CR]ConfigFilePath\f[R] برای مسیر فایل پیکربندی توکن استفاده می‌کنند.
مثال زیر دستوری را برای فهرست کردن یک \f[CR]PKCS #11\f[R] keystore نشان می‌دهد،
در شرایطی که ارائه‌دهندهٔ Oracle PKCS #11 در فایل ویژگی‌های امنیتی پیکربندی نشده باشد.
.RS
.PP
\f[CR]jarsigner \-keystore NONE \-storetype PKCS11 \-addprovider SunPKCS11 \-providerArg /mydir1/mydir2/token.config\f[R]
.RE
.RE
.TP
\f[CR]\-providerClass\f[R] \f[I]provider\-class\-name\f[R] [\f[CR]\-providerArg\f[R] \f[I]arg\f[R]]
برای مشخص کردن نام فایل کلاس اصلی (master class) ارائه‌دهندهٔ خدمات رمزنگاری به کار می‌رود،
در حالتی که ارائه‌دهندهٔ خدمات در فایل ویژگی‌های امنیتی \f[CR]java.security\f[R] فهرست نشده باشد.
یک ارائه‌دهنده امنیتی را با نام کامل کلاس (fully\-qualified class name) و یک آرگومان پیکربندی اختیاری اضافه می‌کند.
.RS
\f[B]نکته:\f[R]
روش ترجیحی برای بارگذاری PKCS11 استفاده از ماژول‌ها است.
گزینهٔ \f[CR]\-addprovider\f[R] را ببینید.
.RE
.TP
\f[CR]\-providerPath\f[R] \f[I]classpath\f[R]
برای تعیین classpath ارائه‌دهندگانی که با گزینهٔ \f[CR]\-providerClass\f[R] مشخص شده‌اند استفاده می‌شود.
چندین مسیر باید با نویسهٔ جداکنندهٔ مسیر وابسته به سیستم از یکدیگر جدا شوند.
.TP
\f[CR]\-J\f[R]\f[I]javaoption\f[R]
رشتهٔ \f[I]javaoption\f[R] مشخص‌شده را مستقیماً به مفسر Java ارسال می‌کند.
دستور \f[CR]jarsigner\f[R] یک لفاف (wrapper) برای این مفسر است.
این گزینه نباید شامل هیچ فاصله‌ای باشد.
این گزینه برای تنظیم محیط اجرا یا میزان حافظهٔ مصرفی مفید است.
برای مشاهدهٔ فهرستی از گزینه‌های ممکن مفسر، عبارت \f[CR]java \-h\f[R] یا
\f[CR]java \-X\f[R] را در خط فرمان وارد کنید.
.TP
\f[CR]\-strict\f[R]
در طول فرایند امضا یا اعتبارسنجی، ممکن است دستور پیام‌های هشداری صادر کند.
اگر این گزینه را مشخص کنید، وضعیت خروج این ابزار نشان‌دهندهٔ پیام‌های هشدار شدیدی خواهد بود که این دستور با آن‌ها مواجه شده است.
بخش \f[B]خطاها و هشدارها (ERRORS AND WARNINGS)\f[R] را ببینید.
.TP
\f[CR]\-conf\f[R] \f[I]url\f[R]
یک فایل گزینه‌های از پیش‌پیکربندی‌شده را مشخص می‌کند.
برای جزئیات بیشتر، \f[B]مستندات keytool\f[R] را مطالعه کنید.
کلیدهای ویژگی پشتیبانی‌شده عبارتند از: \(dqjarsigner.all\(dq برای تمام عملیات‌ها،
\(dqjarsigner.sign\(dq برای امضا کردن، و \(dqjarsigner.verify\(dq برای اعتبارسنجی.
آرگومان‌های \f[CR]jarsigner\f[R] از جمله نام فایل JAR و نام(های) مستعار (alias) را نمی‌توان در این فایل تنظیم کرد.
.TP
\f[CR]\-version\f[R]
نسخهٔ برنامه را چاپ می‌کند.
.SH "خطاها و هشدارها (ERRORS AND WARNINGS)"
در طول فرایند امضا یا اعتبارسنجی، دستور \f[CR]jarsigner\f[R]
ممکن است خطاها یا هشدارهای مختلفی صادر کند.
.PP
اگر شکستی رخ دهد، دستور \f[CR]jarsigner\f[R] با کد ۱ خارج می‌شود.
اگر شکستی در کار نباشد اما یک یا چند هشدار شدید وجود داشته باشد، چنانچه گزینهٔ
\f[CR]\-strict\f[R] مشخص \f[B]نشده\f[R] باشد دستور \f[CR]jarsigner\f[R] با کد ۰ خارج می‌شود،
یا در صورت مشخص شدن \f[CR]\-strict\f[R]، با حاصل OR بیتیِ کدهای هشدار خارج خواهد شد.
اگر تنها هشدارهای اطلاعاتی وجود داشته باشد یا اصلاً هشداری نباشد،
دستور همواره با کد ۰ خارج می‌شود.
.PP
برای نمونه، اگر گواهی مورد استفاده برای امضای یک مدخل منقضی شده باشد و دارای افزونهٔ
KeyUsage باشد که اجازهٔ امضای فایل را به آن ندهد، در صورت تعیین گزینهٔ
\f[CR]\-strict\f[R]، دستور \f[CR]jarsigner\f[R] با کد ۱۲ (=۴+۸) خارج می‌شود.
.PP
\f[B]نکته:\f[R] کدهای خروج مجدداً استفاده می‌شوند، زیرا در Linux و macOS تنها مقادیر بین ۰ تا
۲۵۵ مجاز هستند.
.PP
بخش‌های زیر نام‌ها، کدها و توضیحات مربوط به خطاها و هشدارهایی را که دستور \f[CR]jarsigner\f[R] می‌تواند صادر کند، شرح می‌دهند..SH "شکست (FAILURE)"
دلایلی که موجب شکست فرمان \f[CR]jarsigner\f[R] می‌شوند شامل مواردی مانند خطای تجزیه خط فرمان، ناتوانی در یافتن جفت‌کلید برای امضای فایل JAR، یا شکست در اعتبارسنجی یک JAR امضاشده است (اما به این موارد محدود نمی‌شود).
.TP
failure
کد 1.
عملیات امضا یا اعتبارسنجی با شکست مواجه می‌شود.
.SH "هشدارهای جدی (SEVERE WARNINGS)"
\f[B]نکته:\f[R]
.PP
اگر گزینه \f[CR]\-strict\f[R] را مشخص کنید، هشدارهای جدی به عنوان خطا گزارش می‌شوند.
.PP
دلایلی که موجب صدور یک هشدار جدی توسط فرمان \f[CR]jarsigner\f[R] می‌شوند شامل مواردی است مانند وجود خطا در گواهی استفاده‌شده برای امضای فایل JAR یا وجود مشکلات دیگر در فایل JAR امضاشده.
.TP
hasExpiredCert
کد 4.
این JAR حاوی مدخل‌هایی است که گواهی امضاکننده آن‌ها منقضی شده است.
.TP
hasExpiredTsaCert
کد 4.
برچسب زمانی منقضی شده است.
.TP
notYetValidCert
کد 4.
این JAR حاوی مدخل‌هایی است که گواهی امضاکننده آن‌ها هنوز معتبر نیست.
.TP
chainNotValidated
کد 4.
این JAR حاوی مدخل‌هایی است که زنجیره گواهی آن‌ها اعتبارسنجی نشده است.
.TP
tsaChainNotValidated
کد 64.
برچسب زمانی نامعتبر است.
.TP
signerSelfSigned
کد 4.
این JAR حاوی مدخل‌هایی است که گواهی امضاکننده آن‌ها خودامضا (self-signed) است.
.TP
disabledAlg
کد 4.
الگوریتم استفاده‌شده یک خطر امنیتی به شمار رفته و غیرفعال شده است.
.TP
badKeyUsage
کد 8.
این JAR حاوی مدخل‌هایی است که افزونه KeyUsage گواهی امضاکننده آن‌ها اجازه امضای کد را نمی‌دهد.
.TP
badExtendedKeyUsage
کد 8.
این JAR حاوی مدخل‌هایی است که افزونه ExtendedKeyUsage گواهی امضاکننده آن‌ها اجازه امضای کد را نمی‌دهد.
.TP
badNetscapeCertType
کد 8.
این JAR حاوی مدخل‌هایی است که افزونه NetscapeCertType گواهی امضاکننده آن‌ها اجازه امضای کد را نمی‌دهد.
.TP
hasUnsignedEntry
کد 16.
این JAR حاوی مدخل‌های امضانشده‌ای است که یکپارچگی آن‌ها بررسی نشده است.
.TP
notSignedByAlias
کد 32.
این JAR حاوی مدخل‌های امضاشده‌ای است که توسط نام(های) مستعار (alias) مشخص‌شده امضا نشده‌اند.
.TP
aliasNotInStore
کد 32.
این JAR حاوی مدخل‌های امضاشده‌ای است که توسط هیچ نام مستعاری (alias) در این keystore امضا نشده‌اند.
.TP
tsaChainNotValidated
کد 64.
این JAR حاوی مدخل‌هایی است که زنجیره گواهی TSA آن‌ها نامعتبر است..SH "هشدارهای اطلاعاتی (INFORMATIONAL WARNINGS)"
هشدارهای اطلاعاتی شامل مواردی می‌شوند که خطا نیستند، اما به عنوان شیوه‌های نامناسب تلقی می‌شوند.
این هشدارها فاقد کد هستند.
.TP
extraAttributesDetected
مجوزهای فایل POSIX و/یا ویژگی‌های پیوند نمادین (symlink) هنگام امضا یا اعتبارسنجی فایل JAR شناسایی شده‌اند.
ابزار \f[CR]jarsigner\f[R] این ویژگی‌ها را در فایل تازه امضاشده حفظ می‌کند، اما هشدار می‌دهد که این مشخصه‌ها امضا نشده‌اند و توسط امضا محافظت نمی‌شوند.
.TP
hasExpiringCert
این JAR شامل مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها ظرف شش ماه آینده منقضی می‌شود.
.TP
hasExpiringTsaCert
برچسب زمانی در تاریخ \f[CR]YYYY\-MM\-DD\f[R] ظرف یک سال آینده منقضی خواهد شد.
.TP
hasMultipleManifests
این JAR حاوی چندین فایل مانیفست بود.
هنگام امضا، یکی از فایل‌ها انتخاب شد و باقی کنار گذاشته شدند.
.TP
hasNonexistentEntries
این JAR شامل مدخل‌های امضاشده‌ای برای فایل‌هایی است که وجود ندارند.
.TP
internalInconsistenciesDetected
این JAR حاوی ناسازگاری‌های درونی کشف‌شده هنگام اعتبارسنجی است که ممکن است هنگام خواندن از طریق JarFile و JarInputStream منجر به دریافت محتویات متفاوتی شود.
.TP
legacyAlg
الگوریتم استفاده‌شده یک ریسک امنیتی تلقی می‌شود، اما غیرفعال نشده است.
.TP
noTimestamp
این JAR شامل امضاهایی است که فاقد برچسب زمانی هستند.
بدون برچسب زمانی، کاربران ممکن است پس از تاریخ انقضای گواهی امضاکننده (\f[CR]YYYY\-MM\-DD\f[R]) یا پس از هر تاریخ ابطال در آینده، قادر به اعتبارسنجی این فایل JAR نباشند.
.SH "مثال امضای یک فایل JAR (EXAMPLE OF SIGNING A JAR FILE)"
برای امضای \f[CR]bundle.jar\f[R] با کلید خصوصی کاربری که نام مستعار (alias) آن در مخزن کلید \f[CR]jane\f[R] است، در یک مخزن کلید (keystore) با نام \f[CR]mystore\f[R] واقع در دایرکتوری \f[CR]working\f[R] و نام‌گذاری فایل JAR امضاشده به \f[CR]sbundle.jar\f[R]، از دستور زیر استفاده کنید:
.RS
.PP
\f[CR]jarsigner \-keystore /working/mystore \-storepass\f[R]
\f[I]keystore_password\f[R] \f[CR]\-keypass\f[R]
\f[I]private_key_password\f[R]
\f[CR]\-signedjar sbundle.jar bundle.jar jane\f[R]
.RE
.PP
در دستور قبلی هیچ \f[CR]\-sigfile\f[R] مشخص نشده است؛ بنابراین فایل‌های تولیدشدهٔ \f[CR].SF\f[R] و بلوک امضا که در فایل JAR امضاشده قرار می‌گیرند، نام‌های پیش‌فرضی بر اساس نام مستعار خواهند داشت.
آن‌ها \f[CR]JANE.SF\f[R] و \f[CR]JANE.RSA\f[R] نام‌گذاری می‌شوند.
.PP
اگر می‌خواهید برای گذرواژهٔ مخزن و گذرواژهٔ کلید خصوصی اعلان دریافت کنید (از شما پرسیده شود)، می‌توانید دستور قبلی را به شکل زیر کوتاه کنید:
.RS
.PP
\f[CR]jarsigner \-keystore /working/mystore \-signedjar sbundle.jar bundle.jar jane\f[R]
.RE
.PP
اگر \f[CR]keystore\f[R] همان مخزن کلید پیش‌فرض باشد (\f[CR].keystore\f[R] در پوشهٔ خانگی شما)، نیازی به تعیین یک \f[CR]keystore\f[R] ندارید؛ به این صورت:
.RS
.PP
\f[CR]jarsigner \-signedjar sbundle.jar bundle.jar jane\f[R]
.RE
.PP
اگر می‌خواهید فایل JAR امضاشده جایگزین فایل JAR ورودی (\f[CR]bundle.jar\f[R]) شود، نیازی به تعیین گزینهٔ \f[CR]\-signedjar\f[R] ندارید؛ به این صورت:
.RS
.PP
\f[CR]jarsigner bundle.jar jane\f[R]
.RE.SH "مثالی از اعتبارسنجی یک فایل JAR امضاشده (EXAMPLE OF VERIFYING A SIGNED JAR FILE)"
برای اعتبارسنجی یک فایل JAR امضاشده جهت اطمینان از معتبر بودن امضا و دستکاری نشدن فایل JAR، از دستوری مشابه زیر استفاده کنید:
.RS
.PP
\f[CR]jarsigner \-verify ButtonDemo.jar\f[R]
.RE
.PP
هنگامی که اعتبارسنجی موفقیت‌آمیز باشد، عبارت \f[CR]jar verified\f[R] نمایش
داده می‌شود.
در غیر این صورت، یک پیام خطا نمایش داده می‌شود.
با استفاده از گزینهٔ \f[CR]\-verbose\f[R] می‌توانید اطلاعات بیشتری دریافت
کنید.
نمونه‌ای از کاربرد \f[CR]jarsigner\f[R] با گزینهٔ \f[CR]\-verbose\f[R] در
ادامه آمده است:
.IP
.EX
jarsigner \-verify \-verbose ButtonDemo.jar

s       866 Tue Sep 12 20:08:48 EDT 2017 META\-INF/MANIFEST.MF
        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/
sm      523 Tue Sep 12 20:07:16 EDT 2017 components/ButtonDemo$1.class
sm     3440 Tue Sep 12 20:07:16 EDT 2017 components/ButtonDemo.class
sm     2346 Tue Sep 12 20:07:16 EDT 2017 components/ButtonDemo.jnlp
sm      172 Tue Sep 12 20:07:16 EDT 2017 components/images/left.gif
sm      235 Tue Sep 12 20:07:16 EDT 2017 components/images/middle.gif
sm      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 \(dqCN=\(dqOracle America, Inc.\(dq, OU=Software Engineering, O=\(dqOracle America, Inc.\(dq, L=Redwood City, ST=California, C=US\(dq
    Digest algorithm: SHA\-256
    Signature algorithm: SHA256withRSA, 2048\-bit key
  Timestamped by \(dqCN=Symantec Time Stamping Services Signer \- G4, O=Symantec Corporation, C=US\(dq 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.
.EE
.SH "مثالی از اعتبارسنجی با اطلاعات گواهی (EXAMPLE OF VERIFICATION WITH CERTIFICATE INFORMATION)"
اگر گزینهٔ \f[CR]\-certs\f[R] را به همراه گزینه‌های \f[CR]\-verify\f[R] و
\f[CR]\-verbose\f[R] مشخص کنید، خروجی شامل اطلاعات گواهی برای هر یک از
امضاکنندگان فایل JAR خواهد بود.
این اطلاعات شامل نوع گواهی، اطلاعات نام متمایز (distinguished name) امضاکننده
(زمانی که گواهی X.509 است)، و درون پرانتز، نام مستعار (alias) در keystore برای
امضاکننده خواهد بود (در صورتی که گواهی کلید عمومی موجود در فایل JAR با یکی از
مدخل‌های keystore مطابقت داشته باشد)؛ برای نمونه:
.IP
.EX
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=\(dqOracle America, Inc.\(dq, OU=Software Engineering, O=\(dqOracle America, Inc.\(dq, 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=\(dq(c) 2006 VeriSign, Inc. \- For authorized use only\(dq, OU=VeriSign Trust Network, O=\(dqVeriSign, Inc.\(dq, 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=\(dqOracle America, Inc.\(dq, OU=Software Engineering, O=\(dqOracle America, Inc.\(dq, 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=\(dq(c) 2006 VeriSign, Inc. \- For authorized use only\(dq, OU=VeriSign Trust Network, O=\(dqVeriSign, Inc.\(dq, 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 \(dqCN=\(dqOracle America, Inc.\(dq, OU=Software Engineering, O=\(dqOracle America, Inc.\(dq, L=Redwood City, ST=California, C=US\(dq
    Digest algorithm: SHA\-256
    Signature algorithm: SHA256withRSA, 2048\-bit key
  Timestamped by \(dqCN=Symantec Time Stamping Services Signer \- G4, O=Symantec Corporation, C=US\(dq 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.
.EE
.PP
اگر گواهی یک امضاکننده از نوع گواهی X.509 نباشد، هیچ اطلاعاتی دربارهٔ نام متمایز
(distinguished name) وجود نخواهد داشت.
در این حالت، فقط نوع گواهی و نام مستعار نمایش داده می‌شوند.
برای نمونه، اگر گواهی از نوع گواهی PGP باشد و نام مستعار \f[CR]bob\f[R] باشد،
خروجی به صورت \f[CR]PGP, (bob)\f[R] خواهد بود.