.\" Copyright (c) 1998, 2021, Oracle and/or its affiliates. All rights reserved.
.\" DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
.\"
.\" This code is free software; you can redistribute it and/or modify it
.\" under the terms of the GNU General Public License version 2 only, as
.\" published by the Free Software Foundation.
.\"
.\" This code is distributed in the hope that it will be useful, but WITHOUT
.\" ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
.\" FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
.\" version 2 for more details (a copy is included in the LICENSE file that
.\" accompanied this code).
.\"
.\" You should have received a copy of the GNU General Public License version
.\" 2 along with this work; if not, write to the Free Software Foundation,
.\" Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
.\"
.\" Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
.\" or visit www.oracle.com if you need additional information or have any
.\" questions.
.\"
.\"t
.\" Automatically generated by Pandoc 2.3.1
.\"
.TH "JARSIGNER" "1" "2021" "JDK 17" "JDK Commands"
.hy
.SH "نام (NAME)"
.PP
jarsigner \- امضا و اعتبارسنجی فایل‌های بایگانی جاوا (JAR)
.SH "خلاصه دستور (SYNOPSIS)"
.PP
\f[CB]jarsigner\f[R] [\f[I]options\f[R]] \f[I]jar\-file\f[R] \f[I]alias\f[R]
.PP
\f[CB]jarsigner\f[R] \f[CB]\-verify\f[R] [\f[I]options\f[R]]
\f[I]jar\-file\f[R] [\f[I]alias\f[R] ...]
.TP
.B \f[I]options\f[R]
گزینه‌های خط فرمان.
بخش \f[B]Options for jarsigner\f[R] را ببینید.
.RS
.RE
.TP
.B \f[CB]\-verify\f[R]
گزینهٔ \f[CB]\-verify\f[R] می‌تواند پس از نام فایل JAR، صفر یا چند نام مستعار (alias) از keystore را دریافت کند.
هنگامی که گزینهٔ \f[CB]\-verify\f[R] مشخص شود، دستور \f[CB]jarsigner\f[R] بررسی می‌کند که آیا گواهیِ استفاده‌شده برای اعتبارسنجی هر مدخلِ امضاشده در فایل JAR، با یکی از نام‌های مستعار keystore مطابقت دارد یا خیر.
نام‌های مستعار در keystore مشخص‌شده توسط \f[CB]\-keystore\f[R] یا keystore پیش‌فرض تعریف می‌شوند.
.RS
.PP
اگر گزینهٔ \f[CB]\-strict\f[R] را نیز مشخص کنید و دستور \f[CB]jarsigner\f[R] هشدارهای جدی تشخیص دهد، پیام «jar verified, with signer errors» نمایش داده می‌شود.
.RE
.TP
.B \f[I]jar\-file\f[R]
فایل JAR که باید امضا شود.
.RS
.PP
اگر گزینهٔ \f[CB]\-strict\f[R] را نیز مشخص کرده باشید و دستور \f[CB]jarsigner\f[R] هشدارهای جدی تشخیص دهد، پیام «jar signed, with signer errors» نمایش داده می‌شود.
.RE
.TP
.B \f[I]alias\f[R]
نام‌های مستعاری که در keystore مشخص‌شده توسط \f[CB]\-keystore\f[R] یا keystore پیش‌فرض تعریف شده‌اند.
.RS
.RE
.SH "توضیحات (DESCRIPTION)"
.PP
ابزار \f[CB]jarsigner\f[R] دو هدف را دنبال می‌کند:
.IP \[bu] 2
امضای فایل‌های بایگانی جاوا (JAR).
.IP \[bu] 2
اعتبارسنجی امضاها و بررسی یکپارچگی فایل‌های JAR امضاشده.
.PP
قابلیت JAR امکان بسته‌بندی فایل‌های کلاس، تصاویر، صداها و سایر داده‌های دیجیتال را در یک فایل واحد برای توزیع سریع‌تر و آسان‌تر فراهم می‌کند.
ابزاری به نام \f[CB]jar\f[R] به توسعه‌دهندگان امکان ایجاد فایل‌های JAR را می‌دهد.
(از نظر فنی، هر فایل ZIP را نیز می‌توان یک فایل JAR در نظر گرفت، اگرچه فایل‌های JAR در صورت ایجاد توسط دستور \f[CB]jar\f[R] یا پردازش توسط دستور \f[CB]jarsigner\f[R]، حاوی فایل \f[CB]META\-INF/MANIFEST.MF\f[R] نیز خواهند بود.)
.PP
امضای دیجیتال رشته‌ای از بیت‌ها است که از روی برخی داده‌ها (داده‌های در حال امضا) و کلید خصوصی یک موجودیت (یک شخص، شرکت و غیره) محاسبه می‌شود.
مشابه یک امضای دستی، امضای دیجیتال دارای ویژگی‌های مفید متعددی است:
.IP \[bu] 2
اصالت آن را می‌توان با محاسباتی که از کلید عمومی متناظر با کلید خصوصی تولیدکنندهٔ امضا استفاده می‌کند، اعتبارسنجی کرد.
.IP \[bu] 2
با فرض اینکه کلید خصوصی محرمانه بماند، جعل‌ناپذیر است.
.IP \[bu] 2
تابعی از داده‌های امضاشده است و بنابراین نمی‌توان ادعا کرد که امضای داده‌های دیگر نیز هست.
.IP \[bu] 2
داده‌های امضاشده قابل تغییر نیستند.
اگر داده‌ها تغییر کنند، اصالت امضا دیگر قابل اعتبارسنجی نخواهد بود.
.PP
برای ایجاد امضای یک موجودیت برای یک فایل، آن موجودیت باید ابتدا یک جفت‌کلید عمومی/خصوصی مرتبط با خود و یک یا چند گواهی که کلید عمومی آن را تأیید اصالت می‌کنند داشته باشد.
یک گواهی (certificate) بیانیه‌ای با امضای دیجیتال از سوی یک موجودیت است که بیان می‌دارد کلید عمومی موجودیتی دیگر دارای مقداری مشخص است.
.PP
دستور \f[CB]jarsigner\f[R] از اطلاعات کلید و گواهی موجود در یک keystore برای ایجاد امضاهای دیجیتال برای فایل‌های JAR استفاده می‌کند.
یک keystore پایگاه داده‌ای از کلیدهای خصوصی و زنجیره‌های گواهی X.509 مرتبط با آن‌ها است که کلیدهای عمومی متناظر را تأیید اصالت می‌کنند.
دستور \f[CB]keytool\f[R] برای ایجاد و مدیریت keystoreها به کار می‌رود.
.PP
دستور \f[CB]jarsigner\f[R] از کلید خصوصی یک موجودیت برای ایجاد امضا استفاده می‌کند.
فایل JAR امضاشده علاوه بر موارد دیگر، شامل یک نسخه از گواهیِ استخراج‌شده از keystore برای کلید عمومی متناظر با کلید خصوصی به‌کاررفته در امضای فایل است.
دستور \f[CB]jarsigner\f[R] می‌تواند امضای دیجیتال فایل JAR امضاشده را با استفاده از گواهی درون آن (در فایل بلوک امضای آن) اعتبارسنجی کند.
.PP
دستور \f[CB]jarsigner\f[R] می‌تواند امضاهایی شامل برچسب زمانی (timestamp) تولید کند که به سیستم‌ها یا مستقرکنندگان امکان می‌دهد بررسی کنند آیا فایل JAR در زمانی که گواهیِ امضاکننده هنوز معتبر بوده امضا شده است یا خیر.
.PP
علاوه بر این، رابط‌های برنامه‌نویسی (APIها) به برنامه‌ها اجازه می‌دهند اطلاعات برچسب زمانی را دریافت کنند.
.PP
در حال حاضر، دستور \f[CB]jarsigner\f[R] تنها می‌تواند فایل‌های JAR ایجادشده توسط دستور \f[CB]jar\f[R] یا فایل‌های zip را امضا کند.
فایل‌های JAR همانند فایل‌های zip هستند، با این تفاوت که دارای فایل \f[CB]META\-INF/MANIFEST.MF\f[R] نیز می‌باشند.
هنگامی که دستور \f[CB]jarsigner\f[R] یک فایل zip را امضا می‌کند، یک فایل \f[CB]META\-INF/MANIFEST.MF\f[R] ایجاد می‌شود.
.PP
رفتار پیش‌فرض دستور \f[CB]jarsigner\f[R] امضای یک فایل JAR یا zip است.
برای اعتبارسنجی یک فایل JAR امضاشده، از گزینهٔ \f[CB]\-verify\f[R] استفاده کنید.
.PP
دستور \f[CB]jarsigner\f[R] همچنین تلاش می‌کند پس از امضا یا اعتبارسنجی، گواهی امضاکننده را اعتبارسنجی کند.
در طول اعتبارسنجی، در صورت مشخص بودن گزینهٔ \f[CB]\-revCheck\f[R]، وضعیت ابطال هر گواهی در زنجیرهٔ گواهی‌های امضاکننده بررسی می‌شود.
در صورت وجود خطای اعتبارسنجی یا هر مشکل دیگری، این دستور پیام‌های هشدار تولید می‌کند.
اگر گزینهٔ \f[CB]\-strict\f[R] را مشخص کنید، دستور با هشدارهای جدی مانند خطا برخورد می‌کند.
بخش \f[B]Errors and Warnings\f[R] را ببینید..SH "نام‌های مستعار مخزن کلید (KEYSTORE ALIASES)"
.PP
دسترسی به تمام موجودیت‌های مخزن کلید (keystore) با نام‌های مستعار (alias) یکتا انجام می‌شود.
.PP
هنگامی که از دستور \f[CB]jarsigner\f[R] برای امضای یک فایل JAR استفاده می‌کنید، باید نام مستعار مدخلی در مخزن کلید را که حاوی کلید خصوصیِ مورد نیاز برای تولید امضا است مشخص نمایید.
اگر هیچ فایل خروجی مشخص نشود، فایل اصلی JAR با فایل JAR امضاشده بازنویسی خواهد شد.
.PP
مخازن کلید با یک گذرواژه محافظت می‌شوند، بنابراین گذرواژه مخزن باید مشخص شود.
چنانچه آن را در خط فرمان مشخص نکنید، برای وارد کردن آن از شما درخواست می‌شود.
به همین ترتیب، کلیدهای خصوصی در مخزن کلید با گذرواژه محافظت می‌شوند، بنابراین گذرواژه کلید خصوصی نیز باید مشخص شود، و در صورتی که آن را در خط فرمان تعیین نکنید و با گذرواژه مخزن یکسان نباشد، گذرواژه از شما پرسیده خواهد شد.
.SH "مکان مخزن کلید (KEYSTORE LOCATION)"
.PP
دستور \f[CB]jarsigner\f[R] دارای گزینه \f[CB]\-keystore\f[R] برای مشخص کردن URL مخزن کلید مورد استفاده است.
مخزن کلید به‌طور پیش‌فرض در فایلی به نام \f[CB]\&.keystore\f[R] در دایرکتوری خانگی کاربر، مطابق با مشخصه سیستمی \f[CB]user.home\f[R] ذخیره می‌شود.
.PP
\f[B]لینوکس و OS X:\f[R] مقدار پیش‌فرض \f[CB]user.home\f[R]، دایرکتوری خانگی کاربر است.
.PP
جریان ورودی از گزینه \f[CB]\-keystore\f[R] به متد \f[CB]KeyStore.load\f[R] ارسال می‌شود.
اگر \f[CB]NONE\f[R] به‌عنوان URL تعیین شود، یک جریان null به متد \f[CB]KeyStore.load\f[R] فرستاده خواهد شد.
مقدار \f[CB]NONE\f[R] باید زمانی مشخص شود که کلاس \f[CB]KeyStore\f[R] مبتنی بر فایل نیست؛ به‌عنوان مثال زمانی که روی یک دستگاه سخت‌افزاری توکن (hardware token) قرار دارد.
.SH "پیاده‌سازی مخزن کلید (KEYSTORE IMPLEMENTATION)"
.PP
کلاس \f[CB]KeyStore\f[R] ارائه‌شده در پکیج \f[CB]java.security\f[R]، چندین رابط (interface) مشخص را برای دسترسی و تغییر اطلاعات درون یک مخزن کلید فراهم می‌کند.
می‌توانید چندین پیاده‌سازی عینی (concrete) مختلف داشته باشید که هر یک برای نوع خاصی از مخزن کلید هستند.
.PP
در حال حاضر، دو ابزار خط فرمانی وجود دارند که از پیاده‌سازی‌های مخزن کلید استفاده می‌کنند (\f[CB]keytool\f[R] و \f[CB]jarsigner\f[R]).
.PP
پیاده‌سازی پیش‌فرض مخزن کلید، \f[CB]PKCS12\f[R] است.
این یک مخزن کلید چندسکویی بر پایه استاندارد RSA PKCS12 Personal Information Exchange Syntax است.
این استاندارد در درجه اول برای ذخیره‌سازی یا انتقال کلیدهای خصوصی، گواهی‌ها و سایر داده‌های محرمانه کاربر در نظر گرفته شده است.
یک پیاده‌سازی توکار دیگر نیز وجود دارد که توسط Oracle ارائه شده است.
این پیاده‌سازی، مخزن کلید را در قالب یک فایل با نوع (قالب) اختصاصی مخزن کلید به نام \f[CB]JKS\f[R] پیاده می‌کند.
این قالب از هر کلید خصوصی با گذرواژه اختصاصی خودش محافظت می‌کند، و همچنین یکپارچگی کل مخزن کلید را با یک گذرواژه (احتمالاً متفاوت) تأمین می‌نماید.
.PP
پیاده‌سازی‌های مخزن کلید مبتنی بر ارائه‌دهنده (provider-based) هستند؛ بدین معنا که رابط‌های کاربردی ارائه‌شده توسط کلاس \f[CB]KeyStore\f[R] بر پایه یک واسط ارائه‌دهنده سرویس (Service Provider Interface یا SPI) پیاده‌سازی شده‌اند.
یک کلاس انتزاعی متناظر به نام \f[CB]KeystoreSpi\f[R] نیز در پکیج \f[CB]java.security\f[R] وجود دارد که متدهای واسط ارائه‌دهنده سرویس را که ارائه‌دهندگان باید پیاده‌سازی کنند، تعریف می‌کند.
اصطلاح ارائه‌دهنده (provider) به یک پکیج یا مجموعه‌ای از پکیج‌ها اشاره دارد که پیاده‌سازی عینی زیرمجموعه‌ای از سرویس‌های قابل‌دسترس از طریق Java Security API را فراهم می‌کنند.
برای ارائه یک پیاده‌سازی مخزن کلید، کلاینت‌ها باید یک ارائه‌دهنده را پیاده‌سازی کرده و پیاده‌سازی زیرکلاسی از \f[CB]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/11/tools&id=JSSEC\-GUID\-2BCFDD85\-D533\-4E6C\-8CE9\-29990DEB0190]
شرح داده شده است.
.PP
برنامه‌ها می‌توانند انواع متفاوتی از پیاده‌سازی‌های مخزن کلید را از ارائه‌دهندگان گوناگون، با استفاده از متد کارخانه‌ای \f[CB]getInstance\f[R] در کلاس \f[CB]KeyStore\f[R] برگزینند.
نوع مخزن کلید، قالب ذخیره‌سازی و داده‌ایِ اطلاعات مخزن کلید و الگوریتم‌های به‌کاررفته برای محافظت از کلیدهای خصوصی در مخزن کلید و همچنین یکپارچگی خود مخزن کلید را مشخص می‌کند.
پیاده‌سازی‌های انواع مختلف مخزن کلید با یکدیگر سازگار نیستند.
.PP
دستورهای \f[CB]jarsigner\f[R] می‌توانند مخازن کلید مبتنی بر فایل را از هر مکانی که بتوان با یک URL مشخص کرد بخوانند.
علاوه بر این، این دستورها قادرند مخازن کلید غیرمبتنی بر فایل، مانند مخازن ارائه‌شده توسط MSCAPI در Windows و PKCS11 را در تمامی پلتفرم‌ها بخوانند.
.PP
برای دستورهای \f[CB]jarsigner\f[R] و \f[CB]keytool\f[R]، می‌توانید با استفاده از گزینه \f[CB]\-storetype\f[R] در خط فرمان، نوع مخزن کلید را مشخص کنید.
.PP
اگر نوع مخزن کلید را به‌طور صریح مشخص نکنید، ابزارها پیاده‌سازی مخزن کلید را بر اساس مقدار مشخصه \f[CB]keystore.type\f[R] تعیین‌شده در فایل مشخصات امنیتی برمی‌گزینند.
فایل مشخصات امنیتی \f[CB]java.security\f[R] نام دارد و در دایرکتوری مشخصات امنیتی JDK به نشانی \f[CB]java.home/conf/security\f[R] قرار دارد.
.PP
هر ابزار مقدار \f[CB]keystore.type\f[R] را دریافت کرده و سپس تمام ارائه‌دهندگان نصب‌شده را بررسی می‌کند تا ارائه‌دهنده‌ای را بیابد که مخازن کلید آن نوع را پیاده‌سازی می‌کند.
سپس از پیاده‌سازی مخزن کلید مربوط به آن ارائه‌دهنده استفاده می‌کند.
.PP
کلاس \f[CB]KeyStore\f[R] متد استاتیکی به نام \f[CB]getDefaultType\f[R] تعریف می‌کند که به برنامه‌ها اجازه می‌دهد مقدار مشخصه \f[CB]keystore.type\f[R] را بازیابی کنند.
خط کد زیر، نمونه‌ای از نوع پیش‌فرض مخزن کلید را همان‌طور که در مشخصه \f[CB]keystore.type\f[R] تعیین شده ایجاد می‌کند:
.RS
.PP
\f[CB]KeyStore\ keyStore\ =\ KeyStore.getInstance(KeyStore.getDefaultType());\f[R]
.RE
.PP
نوع پیش‌فرض مخزن کلید، \f[CB]pkcs12\f[R] است که یک مخزن کلید چندسکویی مبتنی بر استاندارد RSA PKCS12 Personal Information Exchange Syntax می‌باشد.
این مقدار با خط زیر در فایل مشخصات امنیتی تعیین می‌شود:
.RS
.PP
\f[CB]keystore.type=pkcs12\f[R]
.RE
.PP
بزرگی یا کوچکی حروف در مشخص کردن نوع مخزن کلید تأثیری ندارد.
برای مثال، \f[CB]JKS\f[R] تفاوتی با \f[CB]jks\f[R] ندارد.
.PP
برای این‌که ابزارها از پیاده‌سازی متفاوتی به جز نوع پیش‌فرض مخزن کلید استفاده کنند، می‌توانید آن خط را تغییر دهید تا نوع دیگری از مخزن کلید مشخص شود.
به‌عنوان نمونه، اگر می‌خواهید از پیاده‌سازی مخزن کلید \f[CB]jks\f[R] متعلق به Oracle استفاده کنید، خط مذکور را به شکل زیر تغییر دهید:
.RS
.PP
\f[CB]keystore.type=jks\f[R]
.RE.SH "الگوریتم‌های پشتیبانی‌شده (SUPPORTED ALGORITHMS)"
.PP
به‌طور پیش‌فرض، دستور \f[CB]jarsigner\f[R] بسته به نوع و اندازه کلید خصوصی، یک فایل JAR را با استفاده از یکی از الگوریتم‌ها و پسوندهای فایل بلوک زیر امضا می‌کند:
.PP
.TS
tab(@);
l l l l.
T{
keyalg
T}@T{
keysize
T}@T{
sigalg پیش‌فرض
T}@T{
پسوند فایل بلوک
T}
_
T{
DSA
T}@T{
هر اندازه‌ای
T}@T{
SHA256withDSA
T}@T{
\&.DSA
T}
T{
RSA
T}@T{
<= 3072
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{
< 384
T}@T{
SHA256withECDSA
T}@T{
\&.EC
T}
T{
T}@T{
< 512
T}@T{
SHA384withECDSA
T}@T{
T}
T{
T}@T{
= 512
T}@T{
SHA512withECDSA
T}@T{
T}
T{
RSASSA\-PSS
T}@T{
<= 3072
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
T}@T{
255
T}@T{
Ed25519
T}@T{
\&.EC
T}
T{
T}@T{
448
T}@T{
Ed448
T}@T{
T}
.TE
.IP \[bu] 2
اگر یک کلید RSASSA\-PSS همراه با پارامترها کدگذاری شده باشد، \f[CB]jarsigner\f[R] از همان پارامترها در امضا استفاده خواهد کرد.
در غیر این صورت، \f[CB]jarsigner\f[R] از پارامترهایی استفاده می‌کند که بر اساس اندازه کلید و مطابق با جدول بالا تعیین می‌شوند.
برای نمونه، یک کلید 3072\-بیتی RSASSA\-PSS از RSASSA\-PSS به عنوان الگوریتم امضا و از SHA\-256 به عنوان الگوریتم‌های درهم‌سازی (هش) و MGF1 استفاده خواهد کرد.
.PP
این الگوریتم‌های امضای پیش‌فرض را می‌توان با استفاده از گزینه \f[CB]\-sigalg\f[R] جایگزین کرد.
.PP
دستور \f[CB]jarsigner\f[R] از ویژگی‌های امنیتی
\f[CB]jdk.jar.disabledAlgorithms\f[R] و
\f[CB]jdk.security.legacyAlgorithms\f[R] برای تعیین این‌که کدام الگوریتم‌ها یک ریسک امنیتی به شمار می‌روند، استفاده می‌کند.
اگر فایل JAR با الگوریتمی امضا شده باشد که غیرفعال است، با آن مانند یک فایل JAR امضانشده رفتار خواهد شد.
اگر فایل JAR با هر یک از الگوریتم‌های منسوخ‌شده (legacy) امضا شده باشد، فایل امضاشده تلقی شده اما همراه با یک هشدار اطلاع‌رسانی خواهد بود تا به کاربران اعلام کند که این الگوریتم قدیمی در به‌روزرسانی‌های آینده غیرفعال خواهد شد.
برای مشاهده خروجی اعتبارسنجی با جزئیات کامل، گزینه \f[CB]\-J\-Djava.security.debug=jar\f[R] را اضافه کنید.
ویژگی‌های امنیتی \f[CB]jdk.jar.disabledAlgorithms\f[R] و
\f[CB]jdk.security.legacyAlgorithms\f[R] در فایل \f[CB]java.security\f[R] (واقع در دایرکتوری \f[CB]$JAVA_HOME/conf/security\f[R] متعلق به JDK) تعریف شده‌اند.
.PP
\f[B]نکته:\f[R]
.PP
به منظور بهبود امنیت پیش‌فرض، اندازه کلید و نام الگوریتم‌های امضای پیش‌فرض با هر انتشار JDK به مقادیر قوی‌تر به‌روزرسانی می‌شوند.
اگر سازگاری متقابل با نسخه‌های قدیمی‌تر JDK اهمیت دارد، لطفاً اطمینان حاصل کنید که مقادیر پیش‌فرض توسط آن نسخه‌ها پشتیبانی می‌شوند، یا در غیر این صورت با مسئولیت خودتان از گزینه \f[CB]\-sigalg\f[R] برای جایگزینی مقادیر پیش‌فرض استفاده کنید..SH "فایل JAR امضاشده (THE SIGNED JAR FILE)"
.PP
هنگامی که از دستور \f[CB]jarsigner\f[R] برای امضای یک فایل JAR استفاده می‌شود، فایل JAR امضاشده در خروجی دقیقاً همانند فایل JAR ورودی است، با این تفاوت که دو فایل اضافی در دایرکتوری META\-INF قرار می‌گیرد:
.IP \[bu] 2
یک فایل امضا با پسوند \f[CB]\&.SF\f[R]
.IP \[bu] 2
یک فایل بلوک امضا با پسوند \f[CB]\&.DSA\f[R]، \f[CB]\&.RSA\f[R] یا \f[CB]\&.EC\f[R]
.PP
نام پایه این دو فایل از مقدار گزینه \f[CB]\-sigfile\f[R] گرفته می‌شود.
برای مثال، هنگامی که این گزینه به‌صورت \f[CB]\-sigfile\ MKSIGN\f[R] باشد، فایل‌ها \f[CB]MKSIGN.SF\f[R] و \f[CB]MKSIGN.RSA\f[R] نام‌گذاری می‌شوند.
در این سند، فرض می‌کنیم که امضاکننده همیشه از یک کلید RSA استفاده می‌کند.
.PP
اگر گزینه \f[CB]\-sigfile\f[R] در خط فرمان مشخص نشده باشد، نام پایه فایل‌های \f[CB]\&.SF\f[R] و بلوک امضا، برابر با ۸ نویسه نخست از نام مستعار (alias) مشخص‌شده در خط فرمان خواهد بود که همگی به حروف بزرگ تبدیل شده‌اند.
اگر نام مستعار کمتر از ۸ نویسه داشته باشد، کل نام مستعار به کار می‌رود.
اگر نام مستعار شامل نویسه‌هایی باشد که در نام فایل امضا مجاز نیستند، هنگام ساخت نام فایل، هر یک از این نویسه‌ها به نویسه خط زیرین (_) تبدیل می‌شوند.
نویسه‌های مجاز شامل حروف، ارقام، خط زیرین و خط پیوند (\-) هستند.
.SH "فایل امضا (SIGNATURE FILE)"
.PP
یک فایل امضا (فایل \f[CB]\&.SF\f[R]) ساختاری شبیه به فایل manifest دارد؛ همان فایلی که در زمان امضا با دستور \f[CB]jarsigner\f[R]، همواره در فایل JAR گنجانده می‌شود.
به ازای هر فایل منبع موجود در فایل JAR، فایل \f[CB]\&.SF\f[R] همانند فایل manifest دارای دو خط است که موارد زیر را فهرست می‌کنند:
.IP \[bu] 2
نام فایل
.IP \[bu] 2
نام الگوریتم چکیده (SHA)
.IP \[bu] 2
مقدار چکیده SHA
.PP
\f[B]نکته:\f[R]
.PP
نام الگوریتم چکیده (SHA) و مقدار چکیده SHA در یک خط قرار دارند.
.PP
در فایل manifest، مقدار چکیده SHA برای هر فایل منبع، چکیده (هش) داده‌های باینری درون آن فایل منبع است.
در فایل \f[CB]\&.SF\f[R]، مقدار چکیده برای یک فایل منبع مشخص، هش دو خط مربوط به آن فایل منبع در فایل manifest است.
.PP
فایل امضا به‌طور پیش‌فرض شامل یک سرآیند حاوی هش کل فایل manifest است.
این سرآیند همچنین حاوی هشی از سرآیند فایل manifest است.
وجود این سرآیند بهینه‌سازی فرایند اعتبارسنجی را ممکن می‌سازد.
بخش \f[B]JAR File Verification\f[R] را ببینید.
.SH "فایل بلوک امضا (SIGNATURE BLOCK FILE)"
.PP
فایل \f[CB]\&.SF\f[R] امضا شده و این امضا در فایل بلوک امضا قرار می‌گیرد.
این فایل همچنین حاوی گواهی یا زنجیره گواهی کدگذاری‌شده از keystore است که کلید عمومی متناظر با کلید خصوصی به‌کاررفته برای امضا را احراز اصالت می‌کند.
بسته به الگوریتم کلید مورد استفاده، این فایل دارای پسوند \f[CB]\&.DSA\f[R]، \f[CB]\&.RSA\f[R] یا \f[CB]\&.EC\f[R] خواهد بود.
جدول موجود در بخش \f[B]Supported Algorithms\f[R] را ببینید.
.SH "برچسب زمانی امضا (SIGNATURE TIME STAMP)"
.PP
دستور \f[CB]jarsigner\f[R] در صورت استفاده با گزینه‌های زیر، هنگام امضای یک فایل JAR یک برچسب زمانی امضا تولید و ذخیره می‌کند:
.IP \[bu] 2
\f[CB]\-tsa\f[R] \f[I]url\f[R]
.IP \[bu] 2
\f[CB]\-tsacert\f[R] \f[I]alias\f[R]
.IP \[bu] 2
\f[CB]\-tsapolicyid\f[R] \f[I]policyid\f[R]
.IP \[bu] 2
\f[CB]\-tsadigestalg\f[R] \f[I]algorithm\f[R]
.PP
بخش \f[B]Options for jarsigner\f[R] را ببینید..SH "اعتبارسنجی فایل JAR (JAR FILE VERIFICATION)"
.PP
یک اعتبارسنجی موفق فایل JAR زمانی رخ می‌دهد که امضاها معتبر باشند و هیچ‌یک از فایل‌هایی که هنگام تولید امضاها در فایل JAR وجود داشته‌اند، از آن زمان به بعد تغییر نکرده باشند.
اعتبارسنجی فایل JAR شامل مراحل زیر است:
.IP "1." 3
اعتبارسنجی امضای فایل \f[CB]\&.SF\f[R].
.RS 4
.PP
این اعتبارسنجی تضمین می‌کند که امضای ذخیره‌شده در هر فایل بلوک امضا با استفاده از کلید خصوصی مربوط به کلید عمومی‌ای تولید شده است که گواهی (یا زنجیره گواهی) آن نیز در فایل بلوک امضا قرار دارد.
همچنین تضمین می‌کند که امضا، یک امضای معتبر از فایل امضای متناظر (\f[CB]\&.SF\f[R]) است، و در نتیجه در فایل \f[CB]\&.SF\f[R] دستکاری صورت نگرفته است.
.RE
.IP "2." 3
اعتبارسنجی خلاصه (digest) درج‌شده در هر مدخل فایل \f[CB]\&.SF\f[R] با بخش متناظر آن در مانیفست.
.RS 4
.PP
فایل \f[CB]\&.SF\f[R] به‌طور پیش‌فرض شامل سرایندی است که حاوی هش کل فایل مانیفست می‌باشد.
هنگامی که سرایند وجود داشته باشد، اعتبارسنجی می‌تواند بررسی کند که آیا هش موجود در سرایند با هش فایل مانیفست مطابقت دارد یا خیر.
در صورت وجود مطابقت، اعتبارسنجی به مرحله بعد می‌رود.
.PP
اگر مطابقتی وجود نداشته باشد، اعتبارسنجی با بهینه‌سازی کمتری مورد نیاز است تا اطمینان حاصل شود که هش موجود در هر بخش اطلاعات فایل منبع در فایل \f[CB]\&.SF\f[R] برابر با هش بخش متناظر آن در فایل مانیفست است.
بخش Signature File را ببینید.
.PP
یکی از دلایلی که ممکن است هش فایل مانیفست ذخیره‌شده در سرایند فایل \f[CB]\&.SF\f[R] با هش فایل مانیفست فعلی برابر نباشد این است که ممکن است پس از امضا شدن فایل، بخش‌هایی برای فایل‌های تازه اضافه‌شده به آن افزوده شده باشد.
برای مثال، فرض کنید یک یا چند فایل (با استفاده از ابزار \f[CB]jar\f[R]) به فایل JAR امضاشده‌ای که قبلاً حاوی یک امضا و یک فایل \f[CB]\&.SF\f[R] بوده است، افزوده شده باشند.
اگر فایل JAR دوباره توسط یک امضاکننده دیگر امضا شود، فایل مانیفست تغییر می‌کند (بخش‌هایی برای فایل‌های جدید توسط ابزار \f[CB]jarsigner\f[R] به آن اضافه می‌شود) و یک فایل \f[CB]\&.SF\f[R] جدید ایجاد می‌شود، اما فایل \f[CB]\&.SF\f[R] اصلی دست‌نخورده باقی می‌ماند.
اگر هیچ‌یک از فایل‌هایی که هنگام تولید امضای اولیه در فایل JAR وجود داشته‌اند از آن زمان تغییر نکرده باشند، اعتبارسنجی همچنان موفق در نظر گرفته می‌شود.
دلیل این امر این است که هش‌های موجود در بخش‌های غیرسرایند فایل \f[CB]\&.SF\f[R] با هش‌های بخش‌های متناظر در فایل مانیفست برابر هستند.
.RE
.IP "3." 3
خواندن هر فایلی در فایل JAR که در فایل \f[CB]\&.SF\f[R] مدخلی دارد.
هنگام خواندن، خلاصه (digest) فایل را محاسبه کرده و نتیجه را با خلاصه این فایل در بخش مانیفست مقایسه کنید.
خلاصه‌ها باید یکسان باشند، در غیر این صورت اعتبارسنجی با شکست مواجه می‌شود.
.RS 4
.PP
اگر در طول فرایند اعتبارسنجی هرگونه شکست جدی در اعتبارسنجی رخ دهد، فرایند متوقف شده و یک استثنای امنیتی (security exception) صادر می‌شود.
دستور \f[CB]jarsigner\f[R] این استثنا را دریافت کرده و نمایش می‌دهد.
.RE
.IP "4." 3
بررسی برای استفاده از الگوریتم‌های غیرفعال‌شده.
بخش \f[B]Supported Algorithms\f[R] را ببینید.
.PP
\f[B]نکته:\f[R]
.PP
شما باید هرگونه هشدارهای اضافی (یا خطاها در صورت مشخص کردن گزینه \f[CB]\-strict\f[R]) و همچنین محتوای گواهی را (با مشخص کردن گزینه‌های \f[CB]\-verbose\f[R] و \f[CB]\-certs\f[R]) بخوانید تا مشخص کنید آیا می‌توان به امضا اعتماد کرد یا خیر.
.SH "چندین امضا برای یک فایل JAR (MULTIPLE SIGNATURES FOR A JAR FILE)"
.PP
یک فایل JAR را می‌توان با اجرای چندباره دستور \f[CB]jarsigner\f[R] بر روی فایل و مشخص کردن نام مستعار (alias) فردی متفاوت در هر بار، توسط چندین نفر امضا کرد؛ به صورت زیر:
.IP
.nf
\f[CB]
jarsigner\ myBundle.jar\ susan
jarsigner\ myBundle.jar\ kevin
\f[R]
.fi
.PP
هنگامی که یک فایل JAR چندین بار امضا می‌شود، چندین فایل \f[CB]\&.SF\f[R] و فایل بلوک امضا در فایل JAR حاصل وجود خواهد داشت؛ یک جفت برای هر امضا.
در مثال قبلی، فایل JAR خروجی شامل فایل‌هایی با نام‌های زیر خواهد بود:
.IP
.nf
\f[CB]
SUSAN.SF
SUSAN.RSA
KEVIN.SF
KEVIN.RSA
\f[R]
.fi.SH "گزینه‌های JARSIGNER (OPTIONS FOR JARSIGNER)"
.PP
بخش‌های زیر گزینه‌های مربوط به \f[CB]jarsigner\f[R] را شرح می‌دهند.
به استانداردهای زیر توجه داشته باشید:
.IP \[bu] 2
نام تمام گزینه‌ها با یک خط پیوند (\-) آغاز می‌شود.
.IP \[bu] 2
گزینه‌ها را می‌توان به هر ترتیبی ارائه داد.
.IP \[bu] 2
مواردی که با حروف کج یا زیرخط‌دار نمایش داده شده‌اند (مقادیر گزینه‌ها)، نشان‌دهنده مقادیر واقعی هستند که باید مشخص شوند.
.IP \[bu] 2
گزینه‌های \f[CB]\-storepass\f[R]، \f[CB]\-keypass\f[R]، \f[CB]\-sigfile\f[R]،
\f[CB]\-sigalg\f[R]، \f[CB]\-digestalg\f[R]، \f[CB]\-signedjar\f[R] و گزینه‌های
مرتبط با TSA تنها هنگام امضا کردن فایل JAR کاربرد دارند؛ این گزینه‌ها
هنگام اعتبارسنجی فایل JAR امضاشده کاربردی ندارند.
گزینه \f[CB]\-keystore\f[R] برای هر دو حالت امضا و اعتبارسنجی فایل JAR
مرتبط و کاربردی است.
علاوه بر این، نام‌های مستعار (aliasها) هنگام امضا و اعتبارسنجی فایل JAR
تعیین می‌شوند.
.TP
.B \f[CB]\-keystore\f[R] \f[I]url\f[R]
نشانی اینترنتی (URL) مکان keystore را تعیین می‌کند.
مقدار پیش‌فرض آن فایل \f[CB]\&.keystore\f[R] در دایرکتوری خانگی کاربر
است که توسط ویژگی سیستمی \f[CB]user.home\f[R] تعیین می‌شود.
.RS
.PP
هنگام امضا کردن، وجود یک keystore الزامی است.
در صورتی که keystore پیش‌فرض وجود نداشته باشد یا بخواهید از موردی به جز
پیش‌فرض استفاده کنید، باید صراحتاً یک keystore مشخص نمایید.
.PP
هنگام اعتبارسنجی نیازی به keystore نیست، اما اگر keystoreای مشخص شده باشد یا
مورد پیش‌فرض موجود باشد و گزینه \f[CB]\-verbose\f[R] نیز قید شده باشد، اطلاعات
بیشتری در خروجی نمایش داده می‌شود مبنی بر اینکه آیا هر یک از گواهی‌های استفاده‌شده
برای اعتبارسنجی فایل JAR، در آن keystore موجود هستند یا خیر.
.PP
آرگومان \f[CB]\-keystore\f[R] می‌تواند به‌جای URL، یک نام فایل و مسیر باشد؛
در این صورت رفتاری مشابه با یک URL از نوع :file خواهد داشت. برای مثال موارد
زیر معادل یکدیگر هستند:
.IP \[bu] 2
\f[CB]\-keystore\f[R] \f[I]filePathAndName\f[R]
.IP \[bu] 2
\f[CB]\-keystore\ file:\f[R]\f[I]filePathAndName\f[R]
.PP
اگر ارائه‌دهنده Sun PKCS #11 در فایل ویژگی‌های امنیتی \f[CB]java.security\f[R]
(واقع در پوشه \f[CB]$JAVA_HOME/conf/security\f[R] مربوط به JDK) پیکربندی شده باشد،
ابزارهای \f[CB]keytool\f[R] و \f[CB]jarsigner\f[R] می‌توانند با تعیین این گزینه‌ها
روی توکن PKCS #11 عملیات انجام دهند:
.RS
.PP
\f[CB]\-keystore\ NONE\ \-storetype\ PKCS11\f[R]
.RE
.PP
برای نمونه، دستور زیر محتویات توکن PKCS#11 پیکربندی‌شده را فهرست می‌کند:
.RS
.PP
\f[CB]keytool\ \-keystore\ NONE\ \-storetype\ PKCS11\ \-list\f[R]
.RE
.RE
.TP
.B \f[CB]\-storepass\f[R] [\f[CB]:env\f[R] | \f[CB]:file\f[R]] \f[I]argument\f[R]
گذرواژه مورد نیاز برای دسترسی به keystore را تعیین می‌کند.
این مورد تنها هنگام امضا کردن (نه اعتبارسنجی) یک فایل JAR لازم است.
در این حالت، اگر گزینه \f[CB]\-storepass\f[R] در خط فرمان مشخص نشده باشد،
گذرواژه از کاربر پرسیده می‌شود.
.RS
.PP
اگر اصلاح‌کننده \f[CB]env\f[R] یا \f[CB]file\f[R] مشخص نشده باشد، مقدار گذرواژه
همان \f[CB]argument\f[R] در نظر گرفته می‌شود.
در غیر این صورت، گذرواژه به شیوه زیر دریافت می‌گردد:
.IP \[bu] 2
\f[CB]env\f[R]: دریافت گذرواژه از متغیر محیطی با نام \f[I]argument\f[R].
.IP \[bu] 2
\f[CB]file\f[R]: دریافت گذرواژه از فایل با نام \f[I]argument\f[R].
.PP
\f[B]نکته:\f[R]
.PP
گذرواژه نباید در خط فرمان یا در یک اسکریپت وارد شود مگر اینکه صرفاً برای
اهداف آزمایشی باشد یا در یک سیستم امن قرار داشته باشید.
.RE
.TP
.B \f[CB]\-storetype\f[R] \f[I]storetype\f[R]
نوع keystore مورد نظر را برای نمونه‌سازی تعیین می‌کند.
نوع پیش‌فرض keystore همان مقداری است که به عنوان ویژگی \f[CB]keystore.type\f[R]
در فایل ویژگی‌های امنیتی تعیین شده و توسط متد ایستا \f[CB]getDefaultType\f[R]
در \f[CB]java.security.KeyStore\f[R] برگردانده می‌شود.
.RS
.PP
شناسه PIN برای توکن PKCS #11 را نیز می‌توان با استفاده از گزینه
\f[CB]\-storepass\f[R] تعیین کرد.
اگر مقداری مشخص نشود، دستورهای \f[CB]keytool\f[R] و \f[CB]jarsigner\f[R]
ورود PIN توکن را درخواست می‌کنند.
اگر توکن دارای مسیر احراز هویت محافظت‌شده باشد (مانند یک صفحه کلید PIN اختصاصی
یا حسگر زیست‌سنجی)، در این صورت باید گزینه \f[CB]\-protected\f[R] مشخص شود
و هیچ گزینه گذرواژه‌ای نباید وارد گردد.
.RE
.TP
.B \f[CB]\-keypass\f[R] [\f[CB]:env\f[R] | \f[CB]:file\f[R]] \f[I]argument\f[R] \f[CB]\-certchain\f[R] \f[I]file\f[R]
گذرواژه مورد استفاده برای محافظت از کلید خصوصی مدخل keystore را که با
نام مستعار مشخص‌شده در خط فرمان آدرس‌دهی می‌شود، تعیین می‌کند.
این گذرواژه هنگام استفاده از \f[CB]jarsigner\f[R] برای امضا کردن یک فایل
JAR الزامی است.
اگر هیچ گذرواژه‌ای در خط فرمان ارائه نشود، و گذرواژه مورد نیاز با گذرواژه
مخزن (store password) تفاوت داشته باشد، از کاربر خواسته می‌شود تا آن را وارد کند.
.RS
.PP
اگر اصلاح‌کننده \f[CB]env\f[R] یا \f[CB]file\f[R] مشخص نشده باشد، مقدار گذرواژه
همان \f[CB]argument\f[R] خواهد بود.
در غیر این صورت، گذرواژه به این روش بازیابی می‌شود:
.IP \[bu] 2
\f[CB]env\f[R]: بازیابی گذرواژه از متغیر محیطی با نام \f[I]argument\f[R].
.IP \[bu] 2
\f[CB]file\f[R]: بازیابی گذرواژه از فایل با نام \f[I]argument\f[R].
.PP
\f[B]نکته:\f[R]
.PP
گذرواژه نباید در خط فرمان یا درون اسکریپت مشخص شود، مگر برای اهداف آزمایشی،
یا اینکه بر روی یک سیستم کاملاً امن قرار داشته باشید.
.RE
.TP
.B \f[CB]\-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].
.RS
.RE
.TP
.B \f[CB]\-sigfile\f[R] \f[I]file\f[R]
نام پایه فایل را برای تولید فایل‌های \f[CB]\&.SF\f[R] و فایل‌های بلوک امضا
مشخص می‌کند.
برای مثال، اگر file برابر با \f[CB]DUKESIGN\f[R] باشد، فایل‌های \f[CB]\&.SF\f[R]
و بلوک امضای تولیدشده \f[CB]DUKESIGN.SF\f[R] و \f[CB]DUKESIGN.RSA\f[R] نام‌گذاری
شده و در پوشه \f[CB]META\-INF\f[R] از فایل JAR امضاشده قرار می‌گیرند.
.RS
.PP
نویسه‌های موجود در فایل باید از مجموعه \f[CB]a\-zA\-Z0\-9_\-\f[R] باشند.
تنها حروف، اعداد، خط زیر (_) و خط پیوند (\-) مجاز هستند.
تمام نویسه‌های کوچک برای نام فایل‌های \f[CB]\&.SF\f[R] و بلوک امضا به
حروف بزرگ تبدیل می‌شوند.
.PP
اگر گزینه \f[CB]\-sigfile\f[R] در خط فرمان وارد نشود، نام پایه برای فایل‌های
\f[CB]\&.SF\f[R] و بلوک امضا برابر با ۸ نویسه ابتدایی نام مستعار مشخص‌شده در
خط فرمان خواهد بود که تماماً به حروف بزرگ تبدیل می‌شوند.
اگر نام مستعار کمتر از ۸ نویسه داشته باشد، کل نام مستعار به کار می‌رود.
اگر نام مستعار حاوی نویسه‌هایی باشد که در نام فایل امضا مجاز نیستند، هر یک
از آن نویسه‌ها به نویسه خط زیر (_) تبدیل می‌شوند تا نام فایل شکل گیرد.
.RE
.TP
.B \f[CB]\-signedjar\f[R] \f[I]file\f[R]
نام فایل JAR امضاشده را مشخص می‌کند.
.RS
.RE
.TP
.B \f[CB]\-digestalg\f[R] \f[I]algorithm\f[R]
نام الگوریتم خلاصه پیام (message digest) را برای استفاده در هنگام خلاصه کردن
مدخل‌های یک فایل JAR مشخص می‌کند.
.RS
.PP
برای مشاهده فهرستی از نام‌های استاندارد الگوریتم خلاصه پیام، به
Java Security Standard Algorithm Names مراجعه کنید..PP
اگر این گزینه مشخص نشود، از \f[CB]SHA256\f[R] استفاده می‌شود.
باید یا یک ارائه‌دهندهٔ نصب‌شده به‌صورت ایستا وجود داشته باشد که پیاده‌سازی الگوریتم مشخص‌شده را ارائه دهد یا کاربر باید ارائه‌دهنده‌ای را با گزینه‌های \f[CB]\-addprovider\f[R] یا \f[CB]\-providerClass\f[R] مشخص کند؛ در غیر این صورت، دستور موفق نخواهد بود.
.RE
.TP
.B \f[CB]\-sigalg\f[R] \f[I]algorithm\f[R]
نام الگوریتم امضا را برای استفاده در امضای فایل JAR مشخص می‌کند.
.RS
.PP
این الگوریتم باید با کلید خصوصی به‌کاررفته برای امضای فایل JAR سازگار باشد.
اگر این گزینه مشخص نشود، از یک الگوریتم پیش‌فرض متناسب با کلید خصوصی، همان‌طور که در بخش \f[B]Supported Algorithms\f[R] شرح داده شده است، استفاده می‌شود.
باید یا یک ارائه‌دهنده به‌صورت ایستا نصب شده باشد که پیاده‌سازی الگوریتم مشخص‌شده را فراهم کند یا باید یکی را با گزینهٔ \f[CB]\-addprovider\f[R] یا \f[CB]\-providerClass\f[R] مشخص کنید؛ در غیر این صورت، دستور موفق نمی‌شود.
.PP
برای فهرستی از نام‌های استاندارد الگوریتم‌های خلاصهٔ پیام، به Java Security Standard Algorithm Names مراجعه کنید.
.RE
.TP
.B \f[CB]\-verify\f[R]
یک فایل JAR امضاشده را اعتبارسنجی می‌کند.
.RS
.RE
.TP
.B \f[CB]\-verbose\f[R][\f[CB]:\f[R]\f[I]suboptions\f[R]]
وقتی گزینهٔ \f[CB]\-verbose\f[R] در خط فرمان بیاید، نشان می‌دهد که \f[CB]jarsigner\f[R] هنگام امضا یا اعتبارسنجی از حالت پرگو (verbose) استفاده کند که زیرگزینه‌ها تعیین می‌کنند چه میزان اطلاعات نمایش داده شود.
این امر باعث می‌شود \f[CB]jarsigner\f[R] اطلاعات اضافی دربارهٔ پیشرفت امضا یا اعتبارسنجی JAR چاپ کند.
مقدار \f[I]suboptions\f[R] می‌تواند \f[CB]all\f[R]، \f[CB]grouped\f[R] یا \f[CB]summary\f[R] باشد.
.RS
.PP
اگر گزینهٔ \f[CB]\-certs\f[R] نیز مشخص شده باشد، حالت پیش‌فرض (یا زیرگزینهٔ \f[CB]all\f[R]) هر مدخل را هنگام پردازش، و پس از آن، اطلاعات گواهی را برای هر امضاکنندهٔ فایل JAR نمایش می‌دهد.
.PP
اگر گزینهٔ \f[CB]\-certs\f[R] و زیرگزینهٔ \f[CB]\-verbose:grouped\f[R] مشخص شوند، مدخل‌های دارای اطلاعات امضاکنندهٔ یکسان گروه‌بندی شده و به همراه اطلاعات گواهی‌شان با هم نمایش داده می‌شوند.
.PP
اگر \f[CB]\-certs\f[R] و زیرگزینهٔ \f[CB]\-verbose:summary\f[R] مشخص شوند، مدخل‌های دارای اطلاعات امضاکنندهٔ یکسان گروه‌بندی شده و به همراه اطلاعات گواهی‌شان نمایش داده می‌شوند.
.PP
جزئیات مربوط به هر مدخل خلاصه شده و به‌صورت \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
.B \f[CB]\-certs\f[R]
اگر گزینهٔ \f[CB]\-certs\f[R] همراه با گزینه‌های \f[CB]\-verify\f[R] و \f[CB]\-verbose\f[R] در خط فرمان بیاید، خروجی شامل اطلاعات گواهی برای هر امضاکنندهٔ فایل JAR خواهد بود.
این اطلاعات شامل نام نوع گواهی (ذخیره‌شده در فایل بلوک امضا) است که کلید عمومی امضاکننده را تأیید می‌کند، و چنانچه گواهی یک گواهی X.509 باشد (نمونه‌ای از \f[CB]java.security.cert.X509Certificate\f[R])، نام متمایز (distinguished name) امضاکننده را نیز در بر می‌گیرد.
.RS
.PP
همچنین keystore بررسی می‌شود.
اگر هیچ مقداری برای keystore در خط فرمان مشخص نشده باشد، فایل پیش‌فرض keystore (در صورت وجود) بررسی می‌شود.
اگر گواهی کلید عمومیِ یک امضاکننده با مدخلی در keystore مطابقت داشته باشد، نام مستعار مدخل keystore برای آن امضاکننده در پرانتز نمایش داده می‌شود.
.RE
.TP
.B \f[CB]\-revCheck\f[R]
این گزینه بررسی ابطال گواهی‌ها را هنگام امضا یا اعتبارسنجی یک فایل JAR فعال می‌کند.
اگر گزینهٔ \f[CB]\-revCheck\f[R] در خط فرمان مشخص شده باشد، دستور \f[CB]jarsigner\f[R] تلاش می‌کند برای دریافت پاسخ‌های OCSP و CRLها ارتباطات شبکه‌ای برقرار کند.
توجه داشته باشید که بررسی‌های ابطال فعال نیستند مگر اینکه این گزینه مشخص شود.
.RS
.RE
.TP
.B \f[CB]\-tsa\f[R] \f[I]url\f[R]
اگر \f[CB]\-tsa\ http://example.tsa.url\f[R] هنگام امضای یک فایل JAR در خط فرمان بیاید، یک برچسب زمانی برای امضا تولید می‌شود.
نشانی اینترنتی \f[CB]http://example.tsa.url\f[R]، مکان مرجع برچسب‌گذاری زمانی (TSA) را مشخص می‌کند و بر هر نشانی یافت‌شده با گزینهٔ \f[CB]\-tsacert\f[R] اولویت دارد.
گزینهٔ \f[CB]\-tsa\f[R] نیازی به حضور گواهی کلید عمومی TSA در keystore ندارد.
.RS
.PP
برای تولید برچسب زمانی، \f[CB]jarsigner\f[R] با استفاده از پروتکل برچسب‌گذاری زمانی (TSP) تعریف‌شده در RFC 3161 با TSA ارتباط برقرار می‌کند.
در صورت موفقیت، توکن برچسب زمانی بازگردانده‌شده توسط TSA به همراه امضا در فایل بلوک امضا ذخیره می‌شود.
.RE
.TP
.B \f[CB]\-tsacert\f[R] \f[I]alias\f[R]
هنگامی که \f[CB]\-tsacert\f[R] \f[I]alias\f[R] در زمان امضای فایل JAR در خط فرمان بیاید، یک برچسب زمانی برای امضا تولید می‌شود.
این نام مستعار، گواهی کلید عمومی TSA فعال را در keystore مشخص می‌کند.
گواهیِ این مدخل برای یافتن افزونهٔ Subject Information Access که حاوی یک نشانی اینترنتی برای مشخص‌کردن مکان TSA است بررسی می‌شود.
.RS
.PP
هنگام استفاده از گزینهٔ \f[CB]\-tsacert\f[R]، گواهی کلید عمومی TSA باید در keystore موجود باشد.
.RE
.TP
.B \f[CB]\-tsapolicyid\f[R] \f[I]policyid\f[R]
شناسه شیء (OID) را مشخص می‌کند که شناسه خط‌مشی ارسالی به کارساز TSA را تعیین می‌کند.
اگر این گزینه مشخص نشود، هیچ شناسه خط‌مشی‌ای ارسال نمی‌شود و کارساز TSA یک شناسه خط‌مشی پیش‌فرض انتخاب خواهد کرد.
.RS
.PP
شناسه‌های شیء توسط X.696 که یک استاندارد بخش استانداردسازی مخابرات ITU (به‌اختصار ITU\-T) است تعریف می‌شوند.
این شناسه‌ها معمولاً مجموعه‌هایی از ارقام نامنفی هستند که با نقطه از هم جدا شده‌اند، مانند \f[CB]1.2.3.4\f[R].
.RE
.TP
.B \f[CB]\-tsadigestalg\f[R] \f[I]algorithm\f[R]
الگوریتم خلاصهٔ پیام را مشخص می‌کند که برای ایجاد نقش پیام (message imprint) ارسالی به کارساز TSA استفاده می‌شود.
اگر این گزینه مشخص نشود، از SHA\-256 استفاده خواهد شد.
.RS
.PP
به \f[B]Supported Algorithms\f[R] مراجعه کنید.
.PP
برای فهرستی از نام‌های استاندارد الگوریتم‌های خلاصهٔ پیام، به Java Security Standard Algorithm Names مراجعه کنید.
.RE
.TP
.B \f[CB]\-internalsf\f[R]
در گذشته، فایل بلوک امضا که هنگام امضای یک فایل JAR تولید می‌شد، شامل یک رونوشت کامل و کدگذاری‌شده از فایل \f[CB]\&.SF\f[R] (فایل امضا) بود که آن نیز ایجاد می‌شد.
این رفتار تغییر یافته است.
برای کاهش اندازهٔ کلی فایل JAR خروجی، فایل بلوک امضا به‌طور پیش‌فرض دیگر حاوی نسخه‌ای از فایل \f[CB]\&.SF\f[R] نیست.
اگر \f[CB]\-internalsf\f[R] در خط فرمان بیاید، از رفتار قدیمی استفاده می‌شود.
این گزینه برای آزمودن مفید است.
در عمل، از گزینهٔ \f[CB]\-internalsf\f[R] استفاده نکنید زیرا سربار بیشتری به همراه دارد.
.RS
.RE
.TP
.B \f[CB]\-sectionsonly\f[R]
اگر گزینهٔ \f[CB]\-sectionsonly\f[R] در خط فرمان بیاید، فایل \f[CB]\&.SF\f[R] (فایل امضا) که هنگام امضای یک فایل JAR تولید می‌شود، شامل سرآیندی نخواهد بود که حاوی هش کل فایل manifest باشد.
این فایل فقط شامل اطلاعات و هش‌های مربوط به هر فایل منبع مجزا است که در فایل JAR قرار دارد.
به بخش Signature File مراجعه کنید.
.RS
.PP
به‌طور پیش‌فرض، این سرآیند به‌عنوان یک بهینه‌سازی اضافه می‌شود.
هنگامی که این سرآیند وجود دارد، هر زمان که فایل JAR اعتبارسنجی شود، فرآیند اعتبارسنجی می‌تواند ابتدا بررسی کند که آیا هش موجود در سرآیند با هش کل فایل manifest مطابقت دارد یا خیر.
در صورت وجود تطابق، اعتبارسنجی به مرحلهٔ بعدی می‌رود.
در صورت عدم تطابق، لازم است یک اعتبارسنجی کمتر بهینه‌شده انجام شود تا بررسی شود آیا هش موجود در بخش اطلاعات هر فایل منبع در فایل \f[CB]\&.SF\f[R] با هش بخش متناظر آن در فایل manifest برابر است یا خیر.
به \f[B]JAR File Verification\f[R] مراجعه کنید..PP
گزینهٔ \f[CB]\-sectionsonly\f[R] اساساً برای آزمایش استفاده می‌شود.
نباید برای مقاصدی جز آزمایش استفاده شود، زیرا استفاده از آن بار اضافی بیشتری تحمیل می‌کند.
.RE
.TP
.B \f[CB]\-protected\f[R]
مقادیر می‌توانند \f[CB]true\f[R] یا \f[CB]false\f[R] باشند.
هنگامی مقدار \f[CB]true\f[R] را تعیین کنید که گذرواژه باید از طریق یک مسیر احراز هویت حفاظت‌شده مانند یک پین‌خوان اختصاصی مشخص شود.
.RS
.RE
.TP
.B \f[CB]\-providerName\f[R] \f[I]providerName\f[R]
اگر بیش از یک ارائه‌دهنده در فایل ویژگی‌های امنیتی \f[CB]java.security\f[R] پیکربندی شده باشد، می‌توانید از گزینهٔ \f[CB]\-providerName\f[R] برای هدف قرار دادن یک نمونه ارائه‌دهندهٔ خاص استفاده کنید.
آرگومان این گزینه نام ارائه‌دهنده است.
.RS
.PP
برای ارائه‌دهندهٔ Oracle PKCS #11، مقدار \f[I]providerName\f[R] به شکل \f[CB]SunPKCS11\-\f[R]\f[I]TokenName\f[R] است، که در آن \f[I]TokenName\f[R] پسوند نامی است که نمونهٔ ارائه‌دهنده با آن پیکربندی شده است، همان‌طور که در جدول ویژگی‌های پیکربندی شرح داده شده است.
به عنوان مثال، دستور زیر محتویات نمونهٔ ارائه‌دهندهٔ مخزن کلید \f[CB]PKCS\ #11\f[R] را با پسوند نام \f[CB]SmartCard\f[R] فهرست می‌کند:
.RS
.PP
\f[CB]jarsigner\ \-keystore\ NONE\ \-storetype\ PKCS11\ \-providerName\ SunPKCS11\-SmartCard\ \-list\f[R]
.RE
.RE
.TP
.B \f[CB]\-addprovider\f[R] \f[I]name\f[R] [\f[CB]\-providerArg\f[R] \f[I]arg\f[R]]
یک ارائه‌دهندهٔ امنیتی را بر اساس نام (مانند SunPKCS11) و یک آرگومان پیکربندی اختیاری اضافه می‌کند.
مقدار ارائه‌دهندهٔ امنیتی، نام ارائه‌دهنده‌ای است که در یک ماژول تعریف شده است.
.RS
.PP
در صورت استفاده با گزینهٔ \f[CB]\-providerArg\ ConfigFilePath\f[R]، ابزارهای \f[CB]keytool\f[R] و \f[CB]jarsigner\f[R] ارائه‌دهنده را به‌صورت پویا نصب کرده و از \f[CB]ConfigFilePath\f[R] به عنوان مسیر فایل پیکربندی توکن استفاده می‌کنند.
مثال زیر دستوری را برای فهرست کردن یک مخزن کلید \f[CB]PKCS\ #11\f[R] در حالتی نشان می‌دهد که ارائه‌دهندهٔ Oracle PKCS #11 در فایل ویژگی‌های امنیتی پیکربندی نشده بود.
.RS
.PP
\f[CB]jarsigner\ \-keystore\ NONE\ \-storetype\ PKCS11\ \-addprovider\ SunPKCS11\ \-providerArg\ /mydir1/mydir2/token.config\f[R]
.RE
.RE
.TP
.B \f[CB]\-providerClass\f[R] \f[I]provider\-class\-name\f[R] [\f[CB]\-providerArg\f[R] \f[I]arg\f[R]]
برای مشخص کردن نام فایل کلاس اصلیِ ارائه‌دهندهٔ خدمات رمزنگاری در زمانی که ارائه‌دهندهٔ خدمات در فایل ویژگی‌های امنیتی \f[CB]java.security\f[R] فهرست نشده باشد استفاده می‌شود.
یک ارائه‌دهندهٔ امنیتی را بر اساس نام کامل کلاس (fully\-qualified) و یک آرگومان پیکربندی اختیاری اضافه می‌کند.
.RS
.PP
\f[B]نکته:\f[R]
.PP
روش ارجح برای بارگذاری PKCS11 استفاده از ماژول‌ها است.
\f[CB]\-addprovider\f[R] را ببینید.
.RE
.TP
.B \f[CB]\-J\f[R]\f[I]javaoption\f[R]
رشتهٔ \f[I]javaoption\f[R] مشخص‌شده را مستقیماً به مفسر Java منتقل می‌کند.
دستور \f[CB]jarsigner\f[R] یک پوشش (wrapper) بر روی مفسر است.
این گزینه نباید شامل هیچ فاصله‌ای باشد.
برای تنظیم محیط اجرا یا میزان مصرف حافظه مفید است.
برای مشاهدهٔ فهرست گزینه‌های ممکن برای مفسر، دستور \f[CB]java\ \-h\f[R] یا \f[CB]java\ \-X\f[R] را در خط فرمان وارد کنید.
.RS
.RE
.TP
.B \f[CB]\-strict\f[R]
در طول فرایند امضا یا اعتبارسنجی، ممکن است دستور پیام‌های هشدار صادر کند.
اگر این گزینه را مشخص کنید، کد خروج ابزار نشان‌دهندهٔ پیام‌های هشدار شدیدی خواهد بود که توسط این دستور پیدا شده است.
بخش \f[B]خطاها و هشدارها (Errors and Warnings)\f[R] را ببینید.
.RS
.RE
.TP
.B \f[CB]\-conf\f[R] \f[I]url\f[R]
یک فایل گزینه‌های از پیش‌پیکربندی‌شده را مشخص می‌کند.
برای جزئیات بیشتر، \f[B]مستندات keytool\f[R] را مطالعه کنید.
کلیدهای ویژگی پشتیبانی‌شده عبارتند از "jarsigner.all" برای همهٔ اقدامات، "jarsigner.sign" برای امضا کردن، و "jarsigner.verify" برای اعتبارسنجی.
آرگومان‌های \f[CB]jarsigner\f[R] شامل نام فایل JAR و نام(های) مستعار را نمی‌توان در این فایل تنظیم کرد.
.RS
.RE.SH "گزینه‌های منسوخ‌شده (DEPRECATED OPTIONS)"
.PP
گزینه‌های زیر در \f[CB]jarsigner\f[R] از JDK 9 منسوخ شده‌اند و ممکن است در انتشار‌های آیندهٔ JDK حذف شوند.
.TP
.B \f[CB]\-altsigner\f[R] \f[I]class\f[R]
این گزینه یک سازوکار امضای جایگزین را مشخص می‌کند.
نام کامل کلاس (fully qualified class name)، فایل کلاسی را مشخص می‌کند که از کلاس انتزاعی \f[CB]com.sun.jarsigner.ContentSigner\f[R] مشتق شده است.
مسیر منتهی به این فایل کلاس توسط گزینهٔ \f[CB]\-altsignerpath\f[R] تعیین می‌شود.
اگر گزینهٔ \f[CB]\-altsigner\f[R] استفاده شود، دستور \f[CB]jarsigner\f[R] از سازوکار امضای ارائه‌شده توسط کلاس مشخص‌شده استفاده می‌کند.
در غیر این صورت، دستور \f[CB]jarsigner\f[R] از سازوکار امضای پیش‌فرض خود بهره می‌گیرد.
.RS
.PP
برای نمونه، جهت استفاده از سازوکار امضای ارائه‌شده توسط کلاسی با نام \f[CB]com.sun.sun.jarsigner.AuthSigner\f[R]، از گزینهٔ \f[CB]\-altsigner\ com.sun.jarsigner.AuthSigner\f[R] در \f[CB]jarsigner\f[R] استفاده کنید.
.RE
.TP
.B \f[CB]\-altsignerpath\f[R] \f[I]classpathlist\f[R]
مسیر منتهی به فایل کلاس و هر فایل JAR وابسته به آن را مشخص می‌کند.
نام فایل کلاس با گزینهٔ \f[CB]\-altsigner\f[R] مشخص می‌شود.
اگر فایل کلاس درون یک فایل JAR باشد، این گزینه مسیر منتهی به آن فایل JAR را مشخص می‌کند.
.RS
.PP
می‌توان یک مسیر مطلق یا مسیری نسبت به دایرکتوری جاری را مشخص کرد.
اگر \f[I]classpathlist\f[R] شامل چندین مسیر یا فایل JAR باشد، باید با نویسه‌های زیر از یکدیگر جدا شوند:
.IP \[bu] 2
دو‌نقطه (\f[CB]:\f[R]) در Linux و macOS
.IP \[bu] 2
نقطه‌ویرگول (\f[CB];\f[R]) در Windows
.PP
هنگامی که کلاس از قبل در مسیر جستجو موجود باشد، نیازی به این گزینه نیست.
.PP
مثال زیر نحوهٔ تعیین مسیر به یک فایل JAR حاوی فایل کلاس را نشان می‌دهد.
نام فایل JAR نیز در مسیر گنجانده شده است.
.RS
.PP
\f[CB]\-altsignerpath\ /home/user/lib/authsigner.jar\f[R]
.RE
.PP
مثال زیر نحوهٔ تعیین مسیر به فایل JAR حاوی فایل کلاس را نشان می‌دهد.
نام فایل JAR حذف شده است.
.RS
.PP
\f[CB]\-altsignerpath\ /home/user/classes/com/sun/tools/jarsigner/\f[R]
.RE
.RE
.SH "خطاها و هشدارها (ERRORS AND WARNINGS)"
.PP
در طول فرایند امضا یا اعتبارسنجی، دستور \f[CB]jarsigner\f[R] ممکن است خطاها یا هشدارهای گوناگونی صادر کند.
.PP
در صورت بروز شکست، دستور \f[CB]jarsigner\f[R] با کد ۱ خارج می‌شود.
اگر شکستی رخ ندهد اما یک یا چند هشدار جدی وجود داشته باشد، در صورتی که گزینهٔ \f[CB]\-strict\f[R] مشخص \f[B]نشده\f[R] باشد دستور \f[CB]jarsigner\f[R] با کد ۰ خارج می‌شود، و در صورت مشخص بودن \f[CB]\-strict\f[R]، با حاصل OR بیتی کدهای هشدار خارج می‌شود.
اگر فقط هشدارهای اطلاع‌رسانی وجود داشته باشد یا هیچ هشداری وجود نداشته باشد، این دستور همواره با کد ۰ خارج می‌شود.
.PP
برای نمونه، اگر گواهیِ استفاده‌شده برای امضای یک مدخل منقضی شده باشد و دارای افزونهٔ KeyUsage باشد که اجازهٔ امضای فایل را نمی‌دهد، هنگام مشخص بودن گزینهٔ \f[CB]\-strict\f[R]، دستور \f[CB]jarsigner\f[R] با کد 12 (=4+8) خارج می‌شود.
.PP
\f[B]نکته:\f[R] کدهای خروج دوباره استفاده می‌شوند (هم‌پوشانی دارند)، زیرا در Linux و OS X تنها مقادیر بین 0 تا 255 معتبر و مجاز هستند.
.PP
بخش‌های زیر نام‌ها، کدها و توضیحات مربوط به خطاها و هشدارهایی را شرح می‌دهند که دستور \f[CB]jarsigner\f[R] می‌تواند صادر کند..SH "شکست (FAILURE)"
.PP
دلایلی که ممکن است باعث شکست دستور \f[CB]jarsigner\f[R] شوند شامل (اما نه
محدود به) خطای تجزیهٔ خط فرمان، ناتوانی در یافتن جفت‌کلید برای امضای فایل
JAR، یا شکست در اعتبارسنجی یک فایل JAR امضاشده است.
.TP
.B failure
کد 1.
امضا یا اعتبارسنجی با شکست مواجه می‌شود.
.RS
.RE
.SH "هشدارهای جدی (SEVERE WARNINGS)"
.PP
\f[B]نکته:\f[R]
.PP
اگر گزینهٔ \f[CB]\-strict\f[R] را مشخص کنید، هشدارهای جدی به عنوان خطا
گزارش می‌شوند.
.PP
دلایلی که باعث صدور یک هشدار جدی توسط دستور \f[CB]jarsigner\f[R] می‌شوند
شامل وجود خطا در گواهی استفاده‌شده برای امضای فایل JAR یا وجود سایر مشکلات
در فایل JAR امضاشده است.
.TP
.B hasExpiredCert
کد 4.
این JAR حاوی مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها منقضی شده است.
.RS
.RE
.TP
.B hasExpiredTsaCert
کد 4.
برچسب زمانی منقضی شده است.
.RS
.RE
.TP
.B notYetValidCert
کد 4.
این JAR حاوی مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها هنوز معتبر نیست.
.RS
.RE
.TP
.B chainNotValidated
کد 4.
این JAR حاوی مدخل‌هایی است که زنجیرهٔ گواهی آن‌ها اعتبارسنجی نشده است.
.RS
.RE
.TP
.B tsaChainNotValidated
کد 64.
برچسب زمانی نامعتبر است.
.RS
.RE
.TP
.B signerSelfSigned
کد 4.
این JAR حاوی مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها خودامضاشده است.
.RS
.RE
.TP
.B disabledAlg
کد 4.
الگوریتم استفاده‌شده یک ریسک امنیتی تلقی شده و غیرفعال است.
.RS
.RE
.TP
.B badKeyUsage
کد 8.
این JAR حاوی مدخل‌هایی است که افزونهٔ KeyUsage در گواهی امضاکنندهٔ آن‌ها اجازهٔ
امضای کد را نمی‌دهد.
.RS
.RE
.TP
.B badExtendedKeyUsage
کد 8.
این JAR حاوی مدخل‌هایی است که افزونهٔ ExtendedKeyUsage در گواهی امضاکنندهٔ
آن‌ها اجازهٔ امضای کد را نمی‌دهد.
.RS
.RE
.TP
.B badNetscapeCertType
کد 8.
این JAR حاوی مدخل‌هایی است که افزونهٔ NetscapeCertType در گواهی امضاکنندهٔ
آن‌ها اجازهٔ امضای کد را نمی‌دهد.
.RS
.RE
.TP
.B hasUnsignedEntry
کد 16.
این JAR حاوی مدخل‌های امضانشده‌ای است که بررسی یکپارچگی روی آن‌ها انجام
نشده است.
.RS
.RE
.TP
.B notSignedByAlias
کد 32.
این JAR حاوی مدخل‌های امضاشده‌ای است که توسط نام(های) مستعار مشخص‌شده
امضا نشده‌اند.
.RS
.RE
.TP
.B aliasNotInStore
کد 32.
این JAR حاوی مدخل‌های امضاشده‌ای است که توسط نام مستعار موجود در این
keystore امضا نشده‌اند.
.RS
.RE
.TP
.B tsaChainNotValidated
کد 64.
این JAR حاوی مدخل‌هایی است که زنجیرهٔ گواهی TSA آن‌ها نامعتبر است.
.RS
.RE.SH "هشدارهای اطلاعاتی (INFORMATIONAL WARNINGS)"
.PP
هشدارهای اطلاعاتی شامل مواردی هستند که خطای قطعی محسوب نمی‌شوند اما به عنوان شیوه‌ای نادرست در نظر گرفته می‌شوند.
این هشدارها فاقد کد هستند.
.TP
.B extraAttributesDetected
مجوزهای فایل POSIX و/یا ویژگی‌های پیوند نمادین (symlink) هنگام امضا یا اعتبارسنجی یک فایل JAR شناسایی شده‌اند.
ابزار \f[CB]jarsigner\f[R] این ویژگی‌ها را در فایل تازه امضاشده حفظ می‌کند، اما هشدار می‌دهد که این ویژگی‌ها امضا نشده‌اند و تحت حفاظت امضا قرار ندارند.
.RS
.RE
.TP
.B hasExpiringCert
این JAR حاوی مدخل‌هایی است که گواهی امضاکنندهٔ آن‌ها ظرف شش ماه منقضی می‌شود.
.RS
.RE
.TP
.B hasExpiringTsaCert
برچسب زمانی (timestamp) ظرف یک سال در تاریخ \f[CB]YYYY\-MM\-DD\f[R] منقضی خواهد شد.
.RS
.RE
.TP
.B internalInconsistenciesDetected
این JAR حاوی ناهماهنگی‌های درونی شناسایی‌شده در حین اعتبارسنجی است که ممکن است هنگام خواندن از طریق JarFile و JarInputStream به محتوای متفاوتی منجر شود.
.RS
.RE
.TP
.B legacyAlg
یک الگوریتم استفاده‌شده وجود دارد که مخاطرهٔ امنیتی در نظر گرفته می‌شود اما غیرفعال نشده است.
.RS
.RE
.TP
.B noTimestamp
این JAR حاوی امضاهایی است که شامل برچسب زمانی نیستند.
بدون برچسب زمانی، کاربران ممکن است نتوانند پس از تاریخ انقضای گواهی امضاکننده (\f[CB]YYYY\-MM\-DD\f[R]) یا پس از هر تاریخ ابطال در آینده، این فایل JAR را اعتبارسنجی کنند.
.RS
.RE
.SH "مثال امضای یک فایل JAR (EXAMPLE OF SIGNING A JAR FILE)"
.PP
برای امضای \f[CB]bundle.jar\f[R] با کلید خصوصی کاربری که نام مستعار keystore آن \f[CB]jane\f[R] است در یک keystore به نام \f[CB]mystore\f[R] در دایرکتوری \f[CB]working\f[R] و نام‌گذاری فایل JAR امضاشده به \f[CB]sbundle.jar\f[R]، از دستور زیر استفاده کنید:
.RS
.PP
\f[CB]jarsigner\ \-keystore\ /working/mystore\ \-storepass\f[R]
\f[I]keystore_password\f[R] \f[CB]\-keypass\f[R]
\f[I]private_key_password\f[R]
\f[CB]\-signedjar\ sbundle.jar\ bundle.jar\ jane\f[R]
.RE
.PP
در دستور قبلی هیچ \f[CB]\-sigfile\f[R] مشخص نشده است، بنابراین فایل‌های تولیدشدهٔ \f[CB]\&.SF\f[R] و فایل‌های بلوک امضا که در فایل JAR امضاشده قرار می‌گیرند، نام‌های پیش‌فرضی بر اساس نام مستعار خواهند داشت.
آن‌ها \f[CB]JANE.SF\f[R] و \f[CB]JANE.RSA\f[R] نام‌گذاری می‌شوند.
.PP
اگر می‌خواهید برای گذرواژهٔ store و گذرواژهٔ کلید خصوصی اعلان دریافت کنید (از شما پرسیده شود)، می‌توانید دستور قبلی را به شکل زیر کوتاه کنید:
.RS
.PP
\f[CB]jarsigner\ \-keystore\ /working/mystore\ \-signedjar\ sbundle.jar\ bundle.jar\ jane\f[R]
.RE
.PP
اگر \f[CB]keystore\f[R] همان \f[CB]keystore\f[R] پیش‌فرض باشد (\f[CB]\&.keystore\f[R] در دایرکتوری خانگی شما)، نیازی به مشخص کردن یک \f[CB]keystore\f[R] ندارید، به صورت زیر:
.RS
.PP
\f[CB]jarsigner\ \-signedjar\ sbundle.jar\ bundle.jar\ jane\f[R]
.RE
.PP
اگر می‌خواهید فایل JAR امضاشده جایگزین فایل JAR ورودی (\f[CB]bundle.jar\f[R]) شود، نیازی به مشخص کردن گزینهٔ \f[CB]\-signedjar\f[R] ندارید، به صورت زیر:
.RS
.PP
\f[CB]jarsigner\ bundle.jar\ jane\f[R]
.RE.SH "مثال از اعتبارسنجی یک فایل JAR امضاشده (EXAMPLE OF VERIFYING A SIGNED JAR FILE)"
.PP
برای اعتبارسنجی یک فایل JAR امضاشده جهت اطمینان از معتبر بودن امضا و
دست‌نخورده بودن فایل JAR، از دستوری مانند زیر استفاده کنید:
.RS
.PP
\f[CB]jarsigner\ \-verify\ ButtonDemo.jar\f[R]
.RE
.PP
در صورت موفقیت‌آمیز بودن اعتبارسنجی، \f[CB]jar\ verified\f[R] نمایش داده
می‌شود.
در غیر این صورت، یک پیام خطا نمایش داده خواهد شد.
با استفاده از گزینهٔ \f[CB]\-verbose\f[R] می‌توانید اطلاعات بیشتری به دست آورید.
نمونه‌ای از استفاده از \f[CB]jarsigner\f[R] با گزینهٔ \f[CB]\-verbose\f[R]
در ادامه آمده است:
.IP
.nf
\f[CB]
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\ "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.
\f[R]
.fi
.SH "مثال از اعتبارسنجی با اطلاعات گواهی (EXAMPLE OF VERIFICATION WITH CERTIFICATE INFORMATION)"
.PP
اگر گزینهٔ \f[CB]\-certs\f[R] را همراه با گزینه‌های \f[CB]\-verify\f[R]
و \f[CB]\-verbose\f[R] مشخص کنید، خروجی شامل اطلاعات گواهی برای هر امضاکنندهٔ
فایل JAR خواهد بود.
این اطلاعات شامل نوع گواهی، اطلاعات نام متمایز (distinguished name) امضاکننده
(در صورتی که گواهی X.509 باشد)، و در پرانتز، نام مستعار (alias) آن در keystore
(در صورتی که گواهی کلید عمومی فایل JAR با مدخلی در keystore تطابق داشته باشد) خواهد بود؛
برای مثال:
.IP
.nf
\f[CB]
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.
\f[R]
.fi
.PP
اگر گواهی یک امضاکننده از نوع گواهی X.509 نباشد، هیچ اطلاعاتی از نام متمایز (distinguished name) وجود نخواهد داشت.
در این حالت، فقط نوع گواهی و نام مستعار نمایش داده می‌شوند.
برای نمونه، اگر گواهی یک گواهی PGP باشد و نام مستعار \f[CB]bob\f[R] باشد،
خروجی به صورت \f[CB]PGP,\ (bob)\f[R] خواهد بود.