JARSIGNER(1) دستورات JDK JARSIGNER(1)

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

jarsigner [گزینه‌ها] jar-file alias

jarsigner -verify [گزینه‌ها] jar-file [alias ...]

jarsigner -version

گزینه‌ها
گزینه‌های خط فرمان. بخش گزینه‌های JARSIGNER را ببینید.
گزینه -verify می‌تواند صفر یا چند نام مستعار مخزن کلید (keystore alias) را بعد از نام فایل JAR دریافت کند. هنگامی که گزینه -verify مشخص می‌شود، دستور jarsigner بررسی می‌کند که گواهی استفاده‌شده برای اعتبارسنجی هر مدخل امضاشده در فایل JAR با یکی از نام‌های مستعار مخزن کلید مطابقت داشته باشد. نام‌های مستعار در مخزن کلید مشخص‌شده با -keystore یا در مخزن کلید پیش‌فرض تعریف شده‌اند.
اگر گزینه -strict را نیز مشخص کنید و دستور jarsigner هشدارهای شدیدی شناسایی کند، پیام "jar verified, with signer errors" نمایش داده می‌شود.
فایل JAR که باید امضا شود.
اگر گزینه -strict را نیز مشخص کرده باشید و دستور jarsigner هشدارهای شدیدی شناسایی کند، پیام "jar signed, with signer errors" نمایش داده می‌شود.
نام‌های مستعار در مخزن کلید تعیین‌شده توسط -keystore یا در مخزن کلید پیش‌فرض تعریف می‌شوند.
گزینه -version نسخه برنامه jarsigner را چاپ می‌کند.

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

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

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

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

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

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

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

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

در حال حاضر دستور jarsigner فقط می‌تواند فایل‌های JAR ایجادشده توسط دستور jar یا فایل‌های ZIP را امضا کند. فایل‌های بسته‌بندی ارائه‌شده با سایر قالب‌های بسته‌بندی را نمی‌توان امضا کرد.

تمام ورودی‌های مخزن کلید با استفاده از نام‌های مستعار منحصربه‌فرد قابل دسترسی هستند. هنگام استفاده از دستور jarsigner برای امضای یک فایل JAR، باید نام مستعار مدخل مخزن کلید حاوی کلید خصوصی مورد نیاز برای تولید امضا را مشخص کنید. برای مثال، دستور زیر از کلید خصوصی مرتبط با نام مستعار working در مخزن کلید پیش‌فرض برای امضای فایل JAR به نام bundle.jar استفاده می‌کند:

jarsigner bundle.jar working

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

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

ورودی از URL به متد KeyStore.load ارسال می‌شود. اگر NONE به عنوان URL مشخص شود، یک مخزن کلید بدون فایل مقداردهی اولیه می‌شود؛ برای مثال، زمانی که مخزن کلید در یک توکن سخت‌افزاری توزیع‌شده قرار دارد.

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

در حال حاضر دو ابزار خط فرمان از پیاده‌سازی‌های مخزن کلید استفاده می‌کنند: keytool و jarsigner. پیاده‌سازی پیش‌فرض مخزن کلید PKCS12 است که یک فرمت مخزن کلید مبتنی بر استاندارد بین‌المللی بر پایه استاندارد RSA PKCS12 Personal Information Exchange Syntax Standard است.

دستور jarsigner می‌تواند از مخزن کلید مبتنی بر فایل یا هر نوع دیگری از پیاده‌سازی مخزن کلید استفاده کند. به عنوان مثال، هنگام دسترسی به یک توکن سخت‌افزاری PKCS#11، می‌توانید گزینه -keystore NONE و گزینه -storetype PKCS11 را برای هدایت دستور jarsigner به مخزن کلید توکن سخت‌افزاری مشخص کنید.

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

دستور jarsigner همچنین از نوع مخزن کلید KeychainStore در سیستم‌های macOS پشتیبانی می‌کند. این نوع مخزن کلید به دستور امکان می‌دهد به گواهی‌ها و کلیدهای خصوصی ذخیره‌شده در زنجیره کلید سیستم اپل دسترسی داشته باشد.

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

الگوریتم‌های امضای پیش‌فرض و پسوندهای فایل بلوک

keyalg key size default sigalg block file extension
DSA هر اندازه‌ای SHA256withDSA .DSA
RSA < 624 SHA256withRSA .RSA
<= 7680 SHA384withRSA
> 7680 SHA512withRSA
EC < 512 SHA384withECDSA .EC
>= 512 SHA512withECDSA
RSASSA-PSS < 624 RSASSA-PSS (with SHA-256) .RSA
<= 7680 RSASSA-PSS (with SHA-384)
> 7680 RSASSA-PSS (with SHA-512)
EdDSA 255 Ed25519 .EC
448 Ed448
  • اگر یک کلید RSASSA-PSS با پارامترها کدگذاری شده باشد، jarsigner از همان پارامترها در امضا استفاده خواهد کرد. در غیر این صورت، jarsigner از پارامترهایی استفاده می‌کند که بر اساس اندازه کلید طبق جدول بالا تعیین می‌شوند. به عنوان مثال، یک کلید ۳۰۷۲ بیتی RSASSA-PSS از RSASSA-PSS به عنوان الگوریتم امضا و SHA-384 به عنوان الگوریتم‌های هش و MGF1 استفاده خواهد کرد.
  • اگر الگوریتم کلید در این جدول فهرست نشده باشد، هنگام امضای یک فایل JAR از پسوند .DSA استفاده می‌شود.

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

دستور jarsigner از ویژگی‌های امنیتی jdk.jar.disabledAlgorithms و jdk.security.legacyAlgorithms برای تعیین اینکه کدام الگوریتم‌ها یک خطر امنیتی در نظر گرفته می‌شوند استفاده می‌کند. اگر فایل JAR با هر الگوریتمی که غیرفعال شده است امضا شده باشد، مانند یک فایل JAR امضانشده با آن رفتار خواهد شد. اگر فایل JAR با هر یک از الگوریتم‌های موروثی (legacy) امضا شده باشد، به عنوان امضاشده همراه با یک هشدار اطلاع‌رسانی در نظر گرفته می‌شود تا به کاربران اطلاع دهد که الگوریتم موروثی در یک به‌روزرسانی آینده غیرفعال خواهد شد. برای دریافت خروجی اعتبارسنجی با جزئیات کامل، گزینه -J-Djava.security.debug=jar را بگنجانید. ویژگی‌های امنیتی jdk.jar.disabledAlgorithms و jdk.security.legacyAlgorithms در فایل java.security (واقع در دایرکتوری $JAVA_HOME/conf/security متعلق به JDK) تعریف شده‌اند.

نکته:

به منظور بهبود امنیت پیش‌فرض، اندازه کلید پیش‌فرض و نام‌های الگوریتم امضا به طور دوره‌ای با هر نسخه جدید JDK به مقادیر قوی‌تر به‌روزرسانی می‌شوند. اگر قابلیت همکاری با نسخه‌های قدیمی‌تر JDK اهمیت دارد، لطفاً اطمینان حاصل کنید که مقادیر پیش‌فرض توسط آن نسخه‌ها پشتیبانی می‌شوند، یا در غیر این صورت با مسئولیت خود از گزینه -sigalg برای لغو مقادیر پیش‌فرض استفاده کنید.

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

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

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

اگر نام مستعار طولانی‌تر از ۸ کاراکتر باشد یا حاوی کاراکترهایی باشد که در نام فایل مجاز نیستند، نام فایل کوتاه یا تبدیل می‌شود.

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

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

فایل امضا می‌تواند شامل اطلاعات اضافی مانند تاریخ و زمان امضا نیز باشد.

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

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

تولید برچسب زمانی با اتصال به یک مرجع برچسب زمانی (Time Stamping Authority یا TSA) از طریق گزینه‌های -tsa یا -tsacert انجام می‌شود. اطلاعات برچسب زمانی در فایل بلوک امضا ذخیره می‌شود.

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

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

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

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

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

هر امضا دارای فایل‌های .SF و بلوک امضای مجزای خود در دایرکتوری META-INF خواهد بود.

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

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

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

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

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

  • -keystore filePathAndName
  • -keystore file:filePathAndName

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

-keystore NONE -storetype PKCS11

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

keytool -keystore NONE -storetype PKCS11 -list

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

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

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

نکته:

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

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

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

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

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

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

نکته:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

جزئیات هر مدخل خلاصه‌سازی شده و به صورت one entry (and more) نمایش داده می‌شود. بخش‌های مثال اعتبارسنجی فایل JAR امضاشده و مثال اعتبارسنجی همراه با اطلاعات گواهی را ببینید.

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

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

این گزینه بررسی وضعیت ابطال گواهی‌ها را هنگام امضا یا اعتبارسنجی فایل JAR فعال می‌کند. در صورت مشخص شدن گزینه -revCheck در خط فرمان، دستور jarsigner تلاش می‌کند اتصالات شبکه‌ای برای واکشی پاسخ‌های OCSP و لیست‌های ابطال گواهی (CRL) برقرار کند. توجه داشته باشید که بررسی‌های ابطال فعال نمی‌شوند مگر اینکه این گزینه صریحاً مشخص شده باشد.
اگر -tsa http://example.tsa.url هنگام امضای فایل JAR در خط فرمان مشخص شود، یک برچسب زمانی برای امضا تولید می‌گردد. آدرس URL، مکان مرجع برچسب‌گذاری زمانی (TSA) را مشخص کرده و هرگونه URL یافت‌شده با گزینه -tsacert را بازنویسی می‌کند. گزینه -tsa نیازی به وجود گواهی کلید عمومی TSA در مخزن کلید ندارد.

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

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

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

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

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

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

بخش الگوریتم‌های پشتیبانی‌شده را ببینید.

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

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

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

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

مقادیر می‌توانند true یا false باشند. هنگامی که گذرواژه باید از طریق یک مسیر احراز هویت محافظت‌شده مانند یک دستگاه کارت‌خوان PIN اختصاصی مشخص شود، مقدار true را تعیین کنید.
اگر بیش از یک ارائه‌دهنده در فایل ویژگی‌های امنیتی java.security پیکربندی شده باشد، می‌توانید از گزینه -providerName برای هدف قرار دادن یک نمونه ارائه‌دهنده خاص استفاده کنید. آرگومان این گزینه نام ارائه‌دهنده است.

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

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

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

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

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

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

نکته:

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

برای تعیین مسیر کلاس (classpath) برای ارائه‌دهندگان مشخص‌شده توسط گزینه -providerClass استفاده می‌شود. مسیرهای متعدد باید با کاراکتر جداکننده مسیر وابسته به سیستم جدا شوند.
رشته javaoption مشخص‌شده را مستقیماً به مفسر جاوا ارسال می‌کند. دستور jarsigner پوششی پیرامون مفسر است. این گزینه نباید شامل هیچ فاصله‌ای باشد. این گزینه برای تنظیم محیط اجرا یا میزان استفاده از حافظه مفید است. برای مشاهده فهرستی از گزینه‌های ممکن مفسر، عبارت java -h یا java -X را در خط فرمان وارد کنید.
در طول فرآیند امضا یا اعتبارسنجی، دستور ممکن است پیام‌های هشدار صادر کند. اگر این گزینه را مشخص کنید، کد خروج ابزار منعکس‌کننده پیام‌های هشدار شدیدی خواهد بود که دستور یافته است. بخش خطاها و هشدارها را ببینید.
یک فایل گزینه‌های از پیش پیکربندی‌شده را مشخص می‌کند. برای جزئیات بیشتر، مستندات keytool را بخوانید. کلیدهای ویژگی پشتیبانی‌شده عبارتند از "jarsigner.all" برای همه اقدامات، "jarsigner.sign" برای امضا و "jarsigner.verify" برای اعتبارسنجی. آرگومان‌های jarsigner از جمله نام فایل JAR و نام(های) مستعار را نمی‌توان در این فایل تنظیم کرد.
نسخه برنامه را چاپ می‌کند.

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

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

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

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

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

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

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

نکته:

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

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

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

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

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

jarsigner -keystore /working/mystore -storepass keystore_password -keypass private_key_password -signedjar sbundle.jar bundle.jar jane

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

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

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

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

jarsigner -signedjar sbundle.jar bundle.jar jane

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

jarsigner bundle.jar jane

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

jarsigner -verify ButtonDemo.jar

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


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.

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


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:08:48 EDT 2017 components/ButtonDemo.class
...
smk    2346 Tue Sep 12 20:08:48 EDT 2017 components/ButtonDemo.jnlp
...
smk     172 Tue Sep 12 20:08:48 EDT 2017 components/images/left.gif
...
smk     235 Tue Sep 12 20:08:48 EDT 2017 components/images/middle.gif
...
smk     172 Tue Sep 12 20:08:48 EDT 2017 components/images/right.gif
...
  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
- Signed by "CN="Oracle America, Inc.", OU=Software Engineering, O="Oracle America, Inc.", L=Redwood City, ST=California, C=US"
    Digest algorithm: SHA-256
    Signature algorithm: SHA256withRSA, 2048-bit key
  Timestamped by "CN=Symantec Time Stamping Services Signer - G4, O=Symantec Corporation, C=US" on Tue Sep 12 20:08:49 UTC 2017
    Timestamp digest algorithm: SHA-1
    Timestamp signature algorithm: SHA1withRSA, 2048-bit key
jar verified.
The signer certificate expired on 2018-02-01. However, the JAR will be valid until the timestamp expires on 2020-12-29.

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

2026 JDK 25.0.4.1