Java Keytool দিয়ে একটি Code Signing Certificate-এর জন্য কীভাবে CSR তৈরি করবেন

Java Development Kit (JDK)-এর সাথে দেওয়া keytool ইউটিলিটি একটি Java কীস্টোরের ভেতরে একটি কী পেয়ার তৈরি করে এবং সেটিকে একটি CSR (Certificate Signing Request)-এ রূপান্তরিত করে, যা একটি এনকোড করা ব্লক যা Certificate Authority (CA) সার্টিফিকেট ইস্যু করার আগে আপনাকে শনাক্ত করতে পড়ে। কোড সাইনিংয়ের ক্ষেত্রে, keytool কীভাবে বৈধভাবে ব্যবহার করা যেতে পারে তা 1 জুন, 2023-এ পরিবর্তিত হয়েছে। এই গাইডটি প্রথমে নিয়মটি বলে দেয়, তারপর সেই keytool কমান্ডগুলো ধাপে ধাপে ব্যাখ্যা করে যেগুলো এখনও সঠিক: অভ্যন্তরীণ সাইনিংয়ের জন্য একটি সফটওয়্যার কীস্টোরের বিপরীতে, এবং PKCS#11-এর মাধ্যমে একটি হার্ডওয়্যার টোকেন বা HSM-এর বিপরীতে।

কোড সাইনিং কী অবশ্যই হার্ডওয়্যারে তৈরি করতে হবে

1 জুন, 2023 থেকে, CA/Browser Forum Code Signing Baseline Requirements-এ প্রতিটি পাবলিকলি ট্রাস্টেড কোড সাইনিং সার্টিফিকেটের প্রাইভেট কী একটি হার্ডওয়্যার ক্রিপ্টো মডিউলে তৈরি ও সংরক্ষণ করার প্রয়োজন হয়েছে, যা FIPS 140-2 Level 2, Common Criteria EAL4+, বা সমমানের একটি স্ট্যান্ডার্ড পূরণ করে। কীটি অবশ্যই নন-এক্সপোর্টেবল হতে হবে। এটি স্ট্যান্ডার্ড (Organization Validation) সার্টিফিকেট এবং Extended Validation সার্টিফিকেট উভয়ের ক্ষেত্রেই প্রযোজ্য। EV কোড সাইনিংয়ের জন্য সবসময়ই হার্ডওয়্যারের প্রয়োজন হত; 2023 সালের পরিবর্তনটি একই নিয়ম স্ট্যান্ডার্ড সার্টিফিকেটের জন্যও প্রসারিত করেছে। একই প্রয়োজনীয়তাগুলোতে কোড সাইনিং সার্টিফিকেটের জন্য ন্যূনতম কী সাইজ RSA 3072 নির্ধারণ করা হয়েছে, যা 1 জুন, 2021 থেকে কার্যকর।

এই পৃষ্ঠার জন্য এর ফলাফল সরাসরি। আপনার ল্যাপটপ বা সার্ভারে keytool দিয়ে তৈরি একটি কীস্টোর ফাইল, তা PKCS12 হোক বা পুরনো JKS ফরম্যাট, একটি সফটওয়্যার কী ধারণ করে। এর থেকে তৈরি একটি CSR পাবলিক Certificate Authority দ্বারা কোড সাইনিং সার্টিফিকেটের জন্য গ্রহণ করা হয় না। Certificate Authorityগুলো এই পণ্যগুলোর জন্য ব্রাউজার-ভিত্তিক কী জেনারেশন এবং ডাউনলোডযোগ্য কী ফাইল সমর্থন করা বন্ধ করে দিয়েছে। এখন আপনার কী দুটি জায়গার একটি থেকে আসে:

• CA আপনাকে পাঠানো একটি প্রি-কনফিগার করা টোকেন। CA নিজের পক্ষ থেকে একটি সার্টিফাইড USB টোকেনে কী পেয়ার এবং CSR তৈরি করে, ইস্যু করা সার্টিফিকেট তাতে লোড করে, এবং টোকেনটি আপনাকে মেইল করে পাঠায়। এখানে আপনার নিজে থেকে কোনো CSR তৈরি করার প্রয়োজন নেই।
• আপনার নিজের HSM বা টোকেন, কী অ্যাটেস্টেশন সহ। আপনি ডিভাইসের ভেতরে কী তৈরি করেন, তা থেকে একটি CSR তৈরি করেন, এবং একটি অ্যাটেস্টেশন ফাইল জমা দেন যা CA-কে প্রমাণ করে যে কীটি কমপ্লায়েন্ট হার্ডওয়্যারে তৈরি হয়েছে এবং এক্সপোর্ট করা যায় না। উভয় অংশই প্রয়োজন; বৈধ অ্যাটেস্টেশন ছাড়া একটি CSR প্রত্যাখ্যাত হয়।

কোন পদ্ধতি প্রযোজ্য তা আপনি অর্ডার করার সময় নির্ধারিত হয়। তুলনার জন্য, কোড সাইনিং সার্টিফিকেট ডেলিভারি মেথড দেখুন। যদি আপনার কাছে ইতিমধ্যে কমপ্লায়েন্ট হার্ডওয়্যার থাকে, তাহলে আপনার ডিভাইসের জন্য গাইড অনুসরণ করুন: YubiKey 5 FIPS CSR জেনারেশন এবং অ্যাটেস্টেশন অথবা Luna Network Attached HSM v7.x CSR এবং অ্যাটেস্টেশন গাইড।

keytool এখনও যেখানে উপযুক্ত

উপরের কোনোটিই keytool-কে বাতিল করে না। এটি তিনটি পরিস্থিতিতে এখনও সঠিক টুল, এবং শুধুমাত্র প্রথমটি একটি CSR তৈরি করে যা আপনি পাবলিক CA-কে পাঠাতে পারেন:

• আপনার টোকেন বা HSM-এর জন্য একটি PKCS#11 ফ্রন্ট এন্ড হিসেবে। keytool স্বাভাবিকভাবেই PKCS#11 বোঝে। আপনার ভেন্ডরের PKCS#11 লাইব্রেরির দিকে এটিকে নির্দেশ করুন এবং কীটি কখনও ডিভাইস ছেড়ে যায় না, যখন পরিচিত -certreq কমান্ডটি এখনও CSR তৈরি করে। কমান্ডগুলো নিচের হার্ডওয়্যার সেকশনে দেওয়া আছে।
• অভ্যন্তরীণ বা এন্টারপ্রাইজ সাইনিংয়ের জন্য। যদি আপনি আপনার প্রতিষ্ঠানের নিজস্ব CA দিয়ে ইন-হাউস সফটওয়্যার সাইন করেন, তাহলে আপনার অভ্যন্তরীণ নীতি কী স্টোরেজ নিয়ন্ত্রণ করে, পাবলিক Baseline Requirements নয়। সেখানে একটি সফটওয়্যার কীস্টোর একটি স্বাভাবিক পছন্দ।
• রিহার্সালের জন্য। যদি আপনি একবার একটি ফেলে দেওয়া কীস্টোরের বিরুদ্ধে প্রম্পটগুলো চালিয়ে থাকেন, তাহলে প্রথম চেষ্টায় সাবজেক্ট নাম সঠিকভাবে পাওয়া সহজ হয়।

শুরু করার আগে জানা উচিত এমন একটি সীমাবদ্ধতা: keytool কী অ্যাটেস্টেশন তৈরি করে না। অ্যাটেস্টেশন তৈরি হয় টোকেন বা HSM ভেন্ডরের নিজস্ব টুলিং দ্বারা, তাই PKCS#11 পথেও আপনি সেই ফাইলের জন্য ভেন্ডর ইউটিলিটি ব্যবহার করবেন এবং শুধুমাত্র CSR-এর জন্য keytool ব্যবহার করবেন।

keytool দিয়ে CSR জেনারেট করুন

যদি আপনি ইতিমধ্যে আপনার CSR তৈরি করে থাকেন এবং Certificate Authority সার্টিফিকেট ইস্যু করে থাকে, তাহলে CA-এর রিপ্লাই ইম্পোর্ট করার ধাপে চলে যান, যে ধাপটি অ্যালিয়াস মিলে না গেলে নীরবে ব্যর্থ হয়।

keytool JDK-এর সাথে আসে, তাই প্রথমে যদি আপনার কাছে বর্তমান JDK না থাকে তবে সেটি ইনস্টল করুন। JDK 25 বর্তমান লং-টার্ম সাপোর্ট রিলিজ এবং JDK 26 বর্তমান শর্ট-টার্ম রিলিজ। নিচের কমান্ডগুলো JDK 17 এবং তার পরের সংস্করণে চলে, এবং যেখানে গুরুত্বপূর্ণ সংস্করণ পার্থক্য দেখা দেয় সেখানে তা উল্লেখ করা হয়েছে। টুলটি আপনার পাথে আছে কিনা তা নিশ্চিত করুন:

java -version
keytool -help
jarsigner -version

শুধু একটি Java Runtime Environment থাকা যথেষ্ট নয়, এবং একটি কার্যকর keytool থাকা মানেই আপনার কাছে JDK আছে তার প্রমাণ নয়: পুরনো Oracle JRE 8-তে keytool আছে কিন্তু jarsigner নেই। এখনই তিনটি কমান্ডই চালান। যদি প্রথম দুটি উত্তর দেয় এবং তৃতীয়টি না দেয়, তাহলে আপনি একটি JRE ব্যবহার করছেন, এবং সেই মুহূর্তে একটি JDK ইনস্টল করা সাইন করতে গিয়ে সেটা আবিষ্কার করার চেয়ে অনেক সহজ।

ধাপ 1: কীস্টোর এবং কী পেয়ার তৈরি করুন

টার্মিনালে, অথবা Windows-এ Command Prompt বা PowerShell-এ, যে ডিরেক্টরিতে আপনি কীস্টোর ফাইল রাখতে চান সেখান থেকে এটি চালান:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -storetype PKCS12 -keystore codesign.p12

সেই কমান্ডের চারটি বিবরণ পুরনো নির্দেশনা থেকে আলাদা, এবং প্রতিটিই গুরুত্বপূর্ণ:

• -genkeypair, -genkey নয়। পুরনো -genkey বানানটি এখনও চলে এবং keytool এ বিষয়ে কোনো সতর্কতা প্রদর্শন করে না, তবে এটি শুধুমাত্র সোর্সে একটি লিগ্যাসি অ্যালিয়াস হিসেবে রাখা হয়েছে এবং এটি আর JDK ডকুমেন্টেশনে কোথাও দেখা যায় না। -genkeypair লিখুন।
• -storetype PKCS12, JKS নয়। JKS হলো Oracle-এর মালিকানাধীন কীস্টোর ফরম্যাট। PKCS12 হলো ইন্ডাস্ট্রি স্ট্যান্ডার্ড এবং এটি Java 9 থেকে JDK ডিফল্ট। যদি আপনি তবুও একটি JKS কীস্টোর তৈরি করেন, তাহলে keytool এটি স্পর্শ করা প্রতিটি কমান্ডে সতর্ক করে: “The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format.”
• ফাইলের নাম ফরম্যাট নির্ধারণ করে না। একটি ফাইলকে keystore.jks নাম দিলে এটি JKS কীস্টোর হয়ে যায় না। keytool টাইপ নেয় -storetype থেকে, অথবা যখন এটি বাদ দেওয়া হয় তখন JDK-এর সিকিউরিটি ফাইলের keystore.type প্রপার্টি থেকে। JDK 9 এবং তার পরের সংস্করণে সেই প্রপার্টিটি pkcs12, তাই -storetype ছাড়া keystore.jks-এ লেখা একটি কমান্ড নীরবে একটি বিভ্রান্তিকর নামসহ একটি PKCS12 ফাইল তৈরি করে।
• -keysize 3072, 2048 নয়। Baseline Requirements কোড সাইনিংয়ের জন্য RSA 3072 ন্যূনতম হিসেবে নির্ধারণ করেছে, তাই একটি 2048-বিটের অনুরোধ প্রত্যাখ্যান করা হয়। বর্তমান JDKগুলো RSA-এর জন্য ডিফল্ট 3072, কিন্তু JDK 17 এবং তার আগের সংস্করণে ডিফল্ট হলো 2048, তাই অপশনটি স্পষ্টভাবে পাস করুন এবং কমান্ডটি সর্বত্র একইভাবে আচরণ করবে।

উদাহরণে codesign, অ্যালিয়াসটি হলো কীস্টোরের ভেতরে এই এন্ট্রির লেবেল। এমন কিছু বেছে নিন যা আপনি চিনতে পারবেন, এবং এটি লিখে রাখুন: পরবর্তী প্রতিটি কমান্ডের এটি প্রয়োজন, এবং একটি অমিলই সেই কারণ যা নিচে বর্ণিত সার্টিফিকেট ইম্পোর্টকে ভেঙে দেয়।

একটি ECDSA কীও অনুমোদিত। আপনি যদি P-256 পছন্দ করেন তাহলে RSA অপশনগুলোর পরিবর্তে -keyalg EC -groupname secp256r1 প্রতিস্থাপন করুন, এবং আপনার CA-এর সাথে নিশ্চিত করুন যে আপনার অর্ডার করা পণ্যটি ECDSA সমর্থন করে।

ধাপ 2: আপনার ডিস্টিংগুইশড নেম তৈরি করে এমন প্রম্পটগুলোর উত্তর দিন

keytool দুইবার একটি কীস্টোর পাসওয়ার্ড জিজ্ঞাসা করে, তারপর ঠিক এই ক্রমে ছয়টি প্রশ্ন জিজ্ঞাসা করে। ক্রমটি গুরুত্বপূর্ণ: দ্বিতীয় প্রম্পটে অর্গানাইজেশনাল ইউনিট জিজ্ঞাসা করা হয়, অর্গানাইজেশন নয়, এবং পুরনো গাইডগুলো এটি ভুলভাবে তালিকাভুক্ত করে, তাই যে পাঠক সেখানে কোম্পানির নাম টাইপ করেন তা নামের ভুল উপাদানে বসিয়ে ফেলেন।

• আপনার প্রথম এবং শেষ নাম কী? শব্দগুলো সত্ত্বেও, এটি Common Name (CN) হয়ে যায়। একটি কোড সাইনিং সার্টিফিকেটের জন্য, CN হলো পাবলিশার আইডেন্টিটি যা ব্যবহারকারীরা দেখবে, তাই আপনার প্রতিষ্ঠানের সঠিক আইনগত নাম লিখুন, অথবা একটি ব্যক্তিগত সার্টিফিকেটের জন্য আপনার নিজের পূর্ণ আইনগত নাম। এখানে একটি ডোমেইন নাম লিখবেন না।
• আপনার অর্গানাইজেশনাল ইউনিটের নাম কী? বিভাগ, উদাহরণস্বরূপ IT। এটি স্কিপ করতে Enter চাপবেন না: keytool তখন নামে আক্ষরিক মান Unknown লিখে দেয়, এবং OU=Unknown আপনার CSR-এ শেষ হয়। যদি আপনি একেবারেই কোনো অর্গানাইজেশনাল ইউনিট না চান, তাহলে নিচের -dname ফর্ম ব্যবহার করুন এবং স্ট্রিং থেকে OU উপাদানটি বাদ দিন।
• আপনার অর্গানাইজেশনের নাম কী? নিবন্ধিত আইনগত নাম, সরকারি রেকর্ডে যেভাবে দেখা যায় সেভাবে বানান করা। CA পাবলিক রেজিস্ট্রির বিরুদ্ধে এটি যাচাই করে।
• আপনার শহর বা এলাকার নাম কী? নিবন্ধনের শহর, সম্পূর্ণরূপে লেখা।
• আপনার রাজ্য বা প্রদেশের নাম কী? সম্পূর্ণ নাম, সংক্ষিপ্ত রূপ নয়।
• এই ইউনিটের জন্য দুই অক্ষরের দেশ কোড কী? ISO কোড, উদাহরণস্বরূপ US।

এরপর keytool একত্রিত নামটি ফেরত প্রিন্ট করে এবং আপনাকে এটি নিশ্চিত করতে বলে:

Is CN=Example LLC, OU=IT, O=Example LLC, L=Miami, ST=Florida, C=US correct?
  [no]:

ডিফল্ট উত্তর হলো no, তাই Enter চাপলে আপনি আবার ছয়টি প্রশ্ন দিয়ে ফিরে যাবেন। গ্রহণ করতে yes টাইপ করুন। প্রথমে লাইনটি সাবধানে পড়ুন: এটি সম্পূর্ণ ডিস্টিংগুইশড নেম, শুধু Common Name নয়, এবং এর প্রতিটি উপাদান CSR-এ যায়।

একটি PKCS12 কীস্টোরে আলাদা কোনো কী পাসওয়ার্ড নেই। পুরনো গাইডগুলো “কী-এর জন্য একটি পাসওয়ার্ড লিখুন” দিয়ে এই ধাপ শেষ করে, যা JKS আচরণ। একটি PKCS12 কীস্টোরে কী পাসওয়ার্ড হলো স্টোর পাসওয়ার্ড, এবং যদি আপনি একটি ভিন্ন মান সহ -keypass পাস করেন তাহলে keytool আপনাকে তা বলে দেয়: “Different store and key passwords not supported for PKCS12 KeyStores. Ignoring user-specified -keypass value.”

প্রম্পটগুলো সম্পূর্ণভাবে এড়াতে, -dname দিয়ে পুরো নামটি সরবরাহ করুন। মানটি এক জোড়া সোজা উদ্ধৃতি চিহ্নের মধ্যে রাখুন:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -storetype PKCS12 -keystore codesign.p12 -dname "CN=Example LLC, OU=IT, O=Example LLC, L=Miami, ST=Florida, C=US"

কমান্ড লাইনে -storepass বাদ দিন এবং keytool-কে এটির জন্য প্রম্পট করতে দিন। একটি আর্গুমেন্ট হিসেবে পাসওয়ার্ড পাস করা এটিকে আপনার শেল হিস্ট্রিতে লিখে ফেলে এবং যে কেউ চলমান প্রসেস দেখতে পারে তার কাছে এটি প্রকাশিত করে দেয়।

ধাপ 3: CSR তৈরি করুন

কীস্টোরে এখন একটি প্রাইভেট কী এবং একটি অস্থায়ী সেলফ-সাইনড সার্টিফিকেট আছে। সেই এন্ট্রিটিকে একটি সার্টিফিকেট রিকোয়েস্টে রূপান্তর করুন:

keytool -certreq -alias codesign -keystore codesign.p12 -file codesign.csr

প্রম্পট করা হলে কীস্টোর পাসওয়ার্ড লিখুন। এখানে আপনার -storetype এর প্রয়োজন নেই: keytool ইতিমধ্যে বিদ্যমান একটি কীস্টোর ফাইলের ফরম্যাট শনাক্ত করে। অ্যালিয়াসটি অবশ্যই ধাপ 1-এর হতে হবে, কারণ CSR সেই এন্ট্রির প্রাইভেট কী দ্বারা সাইন করা হয়।

এই কমান্ডটি একটি প্রাইভেট কী তৈরি করে না। কীটি ধাপ 1-এ তৈরি হয়েছিল এবং কীস্টোরের ভেতরেই থাকে, এই কারণেই কীস্টোর ফাইল এবং এর পাসওয়ার্ড এখন কী-এর মতোই সংবেদনশীল। যে কেউ উভয়টি ধারণ করে সে আপনার নামে সফটওয়্যার সাইন করতে পারে।

ধাপ 4: পাঠানোর আগে CSR চেক করুন

একটি প্রত্যাখ্যাত CSR-এর জন্য একটি ভ্যালিডেশন সাইকেল খরচ হয়, তাই এটি ডিকোড করে ফেরত পড়ুন:

keytool -printcertreq -file codesign.csr

আউটপুটে তিনটি জিনিস নিশ্চিত করুন। Subject লাইনে আপনার বিবরণ সঠিক উপাদানে তালিকাভুক্ত থাকা উচিত, O-তে আইনগত অর্গানাইজেশন নাম এবং CN-এ পাবলিশার আইডেন্টিটি সহ। পাবলিক কী লাইনে 3072-bit RSA key বা তার চেয়ে বড় লেখা থাকা উচিত। সিগনেচার অ্যালগরিদম একটি SHA-2 অ্যালগরিদম হওয়া উচিত: বর্তমান JDKগুলো একটি 3072-বিট RSA রিকোয়েস্ট SHA384withRSA দিয়ে সাইন করে এবং পুরনোগুলো SHA256withRSA ব্যবহার করে, এবং উভয়ই ঠিক আছে। সেই অ্যালগরিদমটি শুধুমাত্র প্রমাণ করে যে আপনার কাছে প্রাইভেট কী আছে, এবং এটি সেই অ্যালগরিদম নয় যা CA আপনার সার্টিফিকেট সাইন করার জন্য ব্যবহার করবে।

একটি ব্রাউজারে একই ফিল্ড পড়তে আপনি রিকোয়েস্টটি আমাদের CSR ডিকোডার-এ পেস্টও করতে পারেন।

আপনি যখন রিকোয়েস্ট জমা দেন, তখন ফাইলটি একটি প্লেইন-টেক্সট এডিটরে খুলুন এবং প্রথম ও শেষ লাইনসহ সবকিছু কপি করুন। keytool এই সঠিক মার্কারগুলো লেখে, প্রতিটি পাশে পাঁচটি হাইফেন সহ:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIID3TCCAkUCAQAwaDELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExDjAM
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

NEW CERTIFICATE REQUEST শব্দগুচ্ছটি keytool আউটপুটের জন্য স্বাভাবিক এবং এনরোলমেন্ট ফর্মগুলো এটি গ্রহণ করে। যদি আপনার এডিটর হাইফেনের কোনো ধারাবাহিকতাকে একটি লম্বা ড্যাশ দিয়ে প্রতিস্থাপন করে থাকে, তাহলে রিকোয়েস্টটি প্রত্যাখ্যান করা হবে: মার্কারগুলো সাধারণ হাইফেন হিসেবে পুনরায় টাইপ করুন অথবা একটি কোড এডিটর দিয়ে ফাইলটি কপি করুন।

keytool দিয়ে একটি টোকেন বা HSM-এ CSR তৈরি করুন

এটিই সেই পথ যা একটি CSR তৈরি করে যার উপর একটি পাবলিক CA কাজ করতে পারে। keytool SunPKCS11 প্রোভাইডারের মাধ্যমে একটি হার্ডওয়্যার টোকেনের সাথে কথা বলে, তাই কী পেয়ারটি ডিভাইসের ভেতরে তৈরি হয় এবং কখনও ফাইল হিসেবে বিদ্যমান থাকে না। একটি ছোট কনফিগারেশন ফাইল লিখে শুরু করুন, উদাহরণস্বরূপ token.cfg, যা আপনার টোকেনের নাম দেয় এবং আপনার ভেন্ডর ইনস্টল করা PKCS#11 লাইব্রেরির দিকে নির্দেশ করে:

name = token
library = /usr/local/lib/libeToken.so

সেই দুটি লাইন, name এবং library, একমাত্র প্রয়োজনীয়। লাইব্রেরি পাথটি ভেন্ডর-নির্দিষ্ট এবং অপারেটিং সিস্টেম অনুযায়ী ভিন্ন হয়, তাই এই উদাহরণ থেকে না নিয়ে আপনার টোকেন ডকুমেন্টেশন থেকে এটি নিন। Windows-এ এটি সিস্টেম ডিরেক্টরির অধীনে একটি DLL। কোনো slot লাইন না থাকলে, প্রোভাইডারটি ডিভাইস রিপোর্ট করা প্রথম স্লটের সাথে সংযুক্ত হয়, যা একক টোকেন প্লাগ ইন করা থাকলে আপনি চান। যদি আপনার একাধিক রিডার বা টোকেন থাকে, তাহলে হয় সেই তালিকায় অবস্থান সহ slotListIndex যোগ করুন, শূন্য থেকে গণনা করে, অথবা আপনার ভেন্ডর ইউটিলিটি প্রিন্ট করা সংখ্যাসূচক স্লট ID সহ slot যোগ করুন। ফাইলে এই দুটির মধ্যে শুধু একটি প্রদর্শিত হতে পারে, এবং একটি স্লট ID একটি তালিকা অবস্থানের সাথে একই সংখ্যা নয়, তাই slot = 0 অনুমান করবেন না।

ডিভাইসে কী আছে তার তালিকা তৈরি করুন। টোকেনটি অ্যালিয়াস সরবরাহ করে, তাই অন্য কিছুর আগে আপনার এটি প্রয়োজন:

keytool -list -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg

-keystore NONE প্রয়োজন যখনই কীস্টোর একটি ফাইল নয়, এবং পাসওয়ার্ড প্রম্পটটি টোকেন PIN চাইছে। keytool -providerClass এবং -providerArg জোড়ার পরিবর্তে -addprovider SunPKCS11 -providerarg token.cfg ও গ্রহণ করে; উভয় ফর্মই কাজ করে, এবং Certificate Authority ডকুমেন্টেশন সাধারণত পুরনোটি দেখায়।

অ্যালিয়াস হাতে থাকলে, ডিভাইসে কী তৈরি করুন এবং তারপর এর বিরুদ্ধে CSR অনুরোধ করুন:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -dname "CN=Example LLC, O=Example LLC, L=Miami, ST=Florida, C=US"

keytool -certreq -alias codesign -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -file codesign.csr

দুটি সতর্কতা প্রযোজ্য। কিছু টোকেন PKCS#11-এর মাধ্যমে কী জেনারেশন অনুমতি দেয় না এবং আপনার ভেন্ডরের নিজস্ব ইউটিলিটি ব্যবহার করার আশা করে, যা ঠিক আছে: keytool তবুও ভেন্ডর টুল দ্বারা তৈরি একটি কী-এর বিরুদ্ধে CSR তৈরি করতে পারে। এবং keytool আপনার CA যে অ্যাটেস্টেশন ফাইল চাইবে তা তৈরি করতে পারে না, তাই কী তৈরির সাথে সাথে ভেন্ডর টুলিং দিয়ে সেটি তৈরি করুন, YubiKey বা Luna HSM গাইড অনুসরণ করে।

CA রিপ্লাই একই অ্যালিয়াসে ইম্পোর্ট করুন

যখন সার্টিফিকেট আসে, এটিকে সেই এন্ট্রিতে ফিরে যেতে হবে যা CSR তৈরি করেছিল। এটি অন্য কোথাও ইম্পোর্ট করলে keytool তবুও সাফল্য রিপোর্ট করে, কিন্তু এমন একটি কীস্টোর তৈরি করে যা সাইন করতে পারে না, তাই কিছু চালানোর আগে এই সেকশনটি পড়ুন।

প্রথমে CA-এর রুট এবং যেকোনো ইন্টারমিডিয়েট সার্টিফিকেট ইম্পোর্ট করুন, প্রতিটি নিজস্ব অ্যালিয়াসের অধীনে:

keytool -importcert -trustcacerts -alias caroot -file root.crt -keystore codesign.p12

keytool যে সার্টিফিকেটটি সংরক্ষণ করতে চলেছে তা প্রিন্ট করে এবং জিজ্ঞাসা করে Trust this certificate?, ডিফল্ট হিসেবে no সহ, তাই yes টাইপ করুন। উত্তর দেওয়ার আগে আপনার Certificate Authority যে ফিঙ্গারপ্রিন্ট প্রকাশ করে তার সাথে এটি চেক করুন।

রুট ইম্পোর্ট এড়িয়ে গেলে পরবর্তী কমান্ডটি এমন একটি বার্তা সহ ব্যর্থ হয় যা কারণ সম্পর্কে কোনো ইঙ্গিত দেয় না:

keytool error: java.lang.Exception: Failed to establish chain from reply

এখন ধাপ 1-এ ব্যবহৃত একই অ্যালিয়াস ব্যবহার করে আপনার ইস্যু করা সার্টিফিকেট ইম্পোর্ট করুন:

keytool -importcert -alias codesign -file codesign.crt -keystore codesign.p12

আপনি যে বার্তাটি চান তা হলো Certificate reply was installed in keystore। এর অর্থ keytool সেই অ্যালিয়াসের অধীনে একটি বিদ্যমান প্রাইভেট কী শনাক্ত করেছে এবং ইস্যু করা সার্টিফিকেট ও এর চেইন এটির সাথে সংযুক্ত করেছে।

যদি আপনি পরিবর্তে একটি নতুন অ্যালিয়াস তৈরি করেন, keytool ফাইলটি গ্রহণ করে এবং প্রিন্ট করে Certificate was added to keystore। এটি সাফল্যের মতো দেখায় কিন্তু তা নয়। keytool সার্টিফিকেটটিকে একটি স্বতন্ত্র বিশ্বস্ত এন্ট্রি হিসেবে সংরক্ষণ করেছে যার পেছনে কোনো প্রাইভেট কী নেই, এবং সেই এন্ট্রি কখনও কিছু সাইন করতে পারবে না। এদিকে মূল অ্যালিয়াসে এখনও ধাপ 1-এর অস্থায়ী সেলফ-সাইনড সার্টিফিকেট রয়েছে। কোনটি আপনার কাছে আছে তা চেক করুন:

keytool -list -keystore codesign.p12

আপনার সাইনিং অ্যালিয়াস অবশ্যই PrivateKeyEntry হিসেবে তালিকাভুক্ত থাকতে হবে। trustedCertEntry হিসেবে প্রদর্শিত একটি অ্যালিয়াস উপরে বর্ণিত ভুল। keytool -delete -alias wrongalias -keystore codesign.p12 দিয়ে এটি মুছে ফেলুন এবং সঠিক অ্যালিয়াসের বিরুদ্ধে ইম্পোর্ট পুনরাবৃত্তি করুন। এন্ট্রিটি এখন একটি সম্পূর্ণ সার্টিফিকেট চেইন বহন করছে কিনা তা নিশ্চিত করতে, একক সেলফ-সাইনড সার্টিফিকেট নয়, তালিকা কমান্ডে -v যোগ করুন।

বেশিরভাগ ক্ষেত্রে একটি হার্ডওয়্যার টোকেনে ইম্পোর্ট করার কিছু থাকে না, কারণ CA ডিভাইসটি পাঠানোর আগেই এতে সার্টিফিকেট লোড করে দেয়। যদি আপনার CA আপনার নিজের HSM-এ তৈরি একটি কী-এর জন্য একটি সার্টিফিকেট ফাইল পাঠায়, তাহলে পূর্ববর্তী সেকশনের PKCS#11 অপশনসহ একই -importcert কমান্ড ব্যবহার করুন।

সার্টিফিকেট দিয়ে একটি JAR ফাইল সাইন করুন

একটি Java কীস্টোরে একটি কোড সাইনিং সার্টিফিকেট রাখার উদ্দেশ্য হলো jarsigner দিয়ে JAR ফাইল সাইন করা, যা JDK-এর সাথেও আসে। সঠিক অ্যালিয়াসের অধীনে সার্টিফিকেট ইনস্টল করা থাকলে:

jarsigner -keystore codesign.p12 -tsa https://your-ca-timestamp-url application.jar codesign

সবসময় আপনার Certificate Authority প্রকাশ করা টাইমস্ট্যাম্প URL সহ -tsa পাস করুন। একটি টাইমস্ট্যাম্প রেকর্ড করে যে JAR সাইন করার সময় সার্টিফিকেটটি তখনও বৈধ ছিল, তাই সার্টিফিকেট মেয়াদ শেষ হওয়ার পরেও সিগনেচারটি কাজ করতে থাকে। একটি ছাড়া, আপনার সফটওয়্যারের প্রতিটি কপি সার্টিফিকেট মেয়াদ শেষ হওয়ার দিনেই ভ্যালিডেট হওয়া বন্ধ করে দেয়।

যখন কীটি একটি টোকেনে থাকে, keytool যেভাবে করে ঠিক সেভাবে jarsigner-কে PKCS#11-এর দিকে নির্দেশ করুন:

jarsigner -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -tsa https://your-ca-timestamp-url application.jar codesign

যদি টোকেনে সম্পূর্ণ সার্টিফিকেট চেইনের জন্য যথেষ্ট জায়গা না থাকে, তাহলে -certchain দিয়ে আলাদাভাবে এটি সরবরাহ করুন। পরে ফলাফল চেক করুন:

jarsigner -verify -verbose -certs application.jar

একটি সফল রান jar verified সহ স্বাক্ষরকারীর ডিস্টিংগুইশড নেম এবং টাইমস্ট্যাম্প বিবরণ প্রিন্ট করে। বর্তমান JDKগুলো ডিফল্ট ডাইজেস্ট অ্যালগরিদম হিসেবে SHA-384 ব্যবহার করে, তাই আপনার খুব কমই হাতে -digestalg বা -sigalg সেট করার প্রয়োজন হবে।

এই রিকোয়েস্ট তৈরির অন্যান্য উপায় OpenSSL, CertReq, Microsoft Management Console, এবং macOS Keychain Access গাইডে আলোচনা করা হয়েছে, এবং একই হার্ডওয়্যার নিয়ম এগুলো সবার ক্ষেত্রেই প্রযোজ্য। আমাদের সম্পূর্ণ কোড সাইনিং টিউটোরিয়াল সেট এবং কোড সাইনিং সার্টিফিকেটের জন্য CSR জেনারেশন-এর ওভারভিউও দেখুন। যদি আপনার একটি কোড সাইনিং সার্টিফিকেটের পরিবর্তে একটি ওয়েবসাইট সার্টিফিকেটের জন্য একটি keytool CSR প্রয়োজন হয়, তাহলে পরিবর্তে Tomcat বা JBoss গাইড অনুসরণ করুন।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী