當導入新的可信任證書時，密鑰倉庫中還沒有 alias。在把證書添加到密鑰倉庫中之前，keytool 將嘗試用密鑰倉庫中已有的可信任證書來構造從該證書到自簽名證書（屬于根 CA）的信任鏈，以對證書進行校驗。
如果指定了 -trustcacerts 選項，則將為該信任鏈考慮其它證書，即考慮名為“cacerts”的文件中的證書，該文件位于 JDK 安全屬性目錄 java.home\lib\security 中，其中 java.home 為 JDK 安裝目錄。“cacerts”文件代表含有 CA 證書的系統范圍的密鑰倉庫。通過指定密鑰倉庫類型為“jks”，系統管理員可用 keytool 來配置和管理該文件。“cacerts”密鑰倉庫文件發送時附有五個 VeriSign 根 CA 證書，其 X.500 特征名如下：
1. OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.",
C=US
2. OU=Class 2 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US
3. OU=Class 3 Public Primary Certification Authority,
O="VeriSign, Inc.", C=US
4. OU=Class 4 Public Primary Certification
Authority, O="VeriSign, Inc.", C=US
5. OU=Secure Server Certification
Authority, O="RSA Data Security, Inc.", C=US
“cacerts”密鑰倉庫文件的初始口令為“changeit” 。系統管理員在安裝 JDK 后，就應該立即更改這個口令以及該文件的缺省訪問權限。
如果 keytool 無法建立從要導入的證書到自簽名證書的信任路徑（利用密鑰倉庫或“cacerts”文件），則打印出該證書的信息，而用戶將得到要求校驗的提示，例如，系統將通知用戶通過比較顯示出的指紋和得自其它（可信任的）信息來源的指紋來進行校驗，信息來源可能是證書擁有者本人。在將證書作為一個“可信任”證書導入之前，要十分小心，務必保證該證書是有效的！ -- 參見有關導入可信任證書的警告。然后，用戶可以選擇中止導入操作。但是，如果給了 -noprompt 選項，則不會有與用戶的交互。
當導入認證答復時，該認證答復將用密鑰倉庫中可信任的證書來確認，有時也使用在“cacerts”密鑰倉庫文件中配置的證書（如果指定了 -trustcacerts 選項）。
如果答復是一個 X.509 證書，keytool 將嘗試建立信任鏈，以該認證答復為頭，以屬于根 CA 的自簽名證書為尾。該認證答復和用于認證該認證答復的證書層次形成了 alias 的新證書鏈。
如果答復是 PKCS#7 格式的證書鏈，則該鏈應首先被排序（用戶證書在最前面，自簽名的根 CA 證書在最后面），然后 keytool 嘗試將答復中的根 CA 證書與密鑰倉庫或“cacerts”密鑰倉庫文件（如果指定了 -trustcacerts 選項）中的任何可信任證書進行匹配。如果找不到匹配，則打印出該根 CA 證書的信息，而用戶將得到要求校驗它的提示，例如，系統將通知用戶通過比較顯示出的指紋和得自其它（可信任的）信息來源的指紋來進行校驗，信息來源可能是證書擁有者本人。因此，用戶可以選擇中止導入操作。但是，如果給了 -noprompt 選項，則不會有與用戶的交互。
alias 的新證書鏈將取代與該項關聯的舊證書鏈。只有提供了有效的 keypass，即提供了用于保護該項的私鑰的口令時，舊鏈才可被取代。如果沒有提供口令，而且私鑰口令與密鑰倉庫口令不同，用戶將得到要求輸入口令的提示。使用口令時必須小心 -- 參見與口令有關的警告。
-selfcert {-alias alias} {-sigalg sigalg} {-dname dname} {-validity valDays} [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v} {-Jjavaoption}
利用密鑰倉庫信息（包括與 alias 關聯的私鑰和公鑰）產生 X.509 v1 自簽名證書。如果在命令行提供了 dname，它將同時用作該證書的簽發人和主體的 X.500 特征名。否則，將使用與 alias 關聯的 X.500 特征名（位于其現有證書鏈底部）。
所生成的證書作為 alias 所標識的密鑰倉庫項中的單元素證書鏈來存儲，它將取代現有的證書鏈。
sigalg 指定簽名證書用的算法。參見支持的算法和密鑰大小。
要訪問私鑰，必須提供正確的口令，因為私鑰在密鑰倉庫中是受口令保護的。如果在命令行中沒有提供 keypass，且私鑰口令與保護密鑰倉庫完整性所用的口令不同，則用戶將得到要求輸入該口令的提示。使用口令時必須小心 -- 參見與口令有關的警告。
valDays 指定證書的有效期。
-identitydb {-file idb_file} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v} {-Jjavaoption}
從 idb_file 文件中讀取 JDK 1.1.x 格式的身份數據庫，并將它的項加到密鑰倉庫中。如果沒有給出文件名，則從標準輸入設備中讀取身份數據庫。如果不存在密鑰倉庫，則創建它。
只有被標記為可信任的身份數據庫項（“身份”）才能被導入密鑰倉庫中。所有其它身份都將被略去。對每個可信任的身份，將創建一個密鑰倉庫項。身份名用作該密鑰倉庫項的“別名”。
所有可信任身份的私鑰都將在相同的口令 storepass 下得到加密。該口令與保護密鑰倉庫完整性所用的口令相同。用戶隨后可用 keytool 命令選項“-keypasswd”來對各私鑰賦予單獨的口令。
身份數據庫中的一個身份可以存放多個證書，各證書所認證的都是同一公鑰。但一個私鑰的密鑰倉庫密鑰項含有該私鑰和單一的“證書鏈”（該鏈最初只有一個證書），鏈中的第一個證書含有與該私鑰對應的公鑰。當從身份導入信息時，只有該身份中的第一個證書被儲存到密鑰倉庫中。這是因為身份數據庫中的身份名被用作其相應密鑰倉庫項的別名，而別名在密鑰倉庫中是唯一的。
導出數據
-certreq {-alias alias} {-sigalg sigalg} {-file certreq_file} [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v} {-Jjavaoption}
生成 PKCS#10 格式的證書簽名請求 (CSR)。
CSR 用來發送給認證機構 (CA)。CA 對認證請求者進行認證（通常是離線的），并返回證書或證書鏈，以取代密鑰倉庫中現有的證書鏈（該證書鏈最初只含有自簽名證書）。
私鑰和與 alias 關聯的 X.500 特征名用于創建 PKCS#10 證書請求。要訪問私鑰，必須提供正確的口令，因為私鑰在庫中是受口令保護的。如果在命令行沒有提供 keypass，且私鑰口令與保護密鑰倉庫完整性所用的口令不同，則用戶將得到要求輸入口令的提示。
使用口令時必須小心 -- 參見與口令有關的警告。
sigalg 指定簽名 CSR 時用的算法。參見支持的算法和密鑰大小。
CSR 存儲在文件 certreq_file 中。如果沒有給出文件名，CSR 將被輸出到標準輸出設備中。
用 import 命令來導入 CA 所返回的答復。
-export {-alias alias} {-file cert_file} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-rfc} {-v} {-Jjavaoption}
從密鑰倉庫中讀取與 alias 關聯的證書，并將其儲存在文件 cert_file 中。
如果沒有給出文件名，證書將被輸出到標準輸出設備中。
缺省情況下，證書被輸出為二進制編碼格式，但如果指定了 -rfc 選項，則將被輸出為 Internet RFC 1421 標準中定義的可打印格式。
如果 alias 引用的是可信任證書，則該證書將被輸出。否則，alias 引用的是含有相關證書鏈的密鑰項。在這種情況下，鏈中的第一個證書將被返回。該證書對由 alias 所指定的實體的公鑰進行認證。
顯示數據
-list {-alias alias} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v | -rfc} {-Jjavaoption}
打?。ǖ綐藴瘦敵鲈O備中）alias 所標識的密鑰倉庫項的內容。如果沒有指定別名，則將打印整個密鑰倉庫的內容。
缺省情況下，該命令打印證書的 MD5 指紋。如果指定了 -v 選項，證書將以可讀格式打印，同時包含擁有者、簽發人和序列號等附加信息。如果指定了??-rfc 選項，證書將以 Internet RFC 1421 標準所定義的可打印的編碼格式打印。
不能同時指定 -v 和 -rfc 兩個選項。
-printcert {-file cert_file} {-v} {-Jjavaoption}
從文件 cert_file 中讀取證書將以可讀格式打印其內容。如果沒有給出文件名，則從標準輸入設備中讀取證書。
證書可以是用二進制編碼或 Internet RFC 1421 標準所定義的可打印編碼格式。
注意：該選項的使用與密鑰倉庫無關。
管理密鑰倉庫
-keyclone {-alias alias} [-dest dest_alias] [-keypass keypass] [-new new_keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v} {-Jjavaoption}
生成新的密鑰倉庫項，該項含有的私鑰和證書鏈與原始項的相同。
原始項由 alias （如果沒有提供別名，則其值缺省為“mykey”）標識。新（目標）項由 dest_alias 標識。如果沒有在命令行中提供目標別名，用戶將得到要求輸入該信息的提示。
如果私鑰口令與密鑰倉庫口令不同，那么，只有提供了有效的 keypass 時該項才能被復制。keypass 是用于保護與 alias 關聯的私鑰的口令。如果沒有在命令行提供密鑰口令，且私鑰口令與密鑰倉庫口令不同，用戶將得到要求輸入口令的提示。如果愿意，可用不同的口令來保護復制項中的私鑰。如果沒有在命令行提供 -new 選項，用戶將得到提示要求輸入新項的口令（可以選擇讓該口令與被復制項的私鑰所用的口令相同）。
使用口令時必須小心 -- 參見與口令有關的警告。
該命令可用于建立多個與給定密鑰對相對應的證書鏈，或用于備份。
-storepasswd [-new new_storepass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v} {-Jjavaoption}
更改保護密鑰倉庫內容的完整性所用的口令。新口令為 new_storepass，其長度必須至少是 6 個字符。
使用口令時必須小心 -- 參見與口令有關的警告。
-keypasswd {-alias alias} [-keypass old_keypass] [-new new_keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v} {-Jjavaoption}
把保護 alias 所標識的私鑰的口令從 old_keypass 更改為 new_keypass。
如果沒有在命令行提供 keypass 選項，且私鑰口令與密鑰倉庫口令不同，則用戶將得到要求輸入該口令的提示。
如果沒有在命令行給出 -new 選項，則用戶將得到要求輸入新口令的提示。
使用口令時必須小心 -- 參見與口令有關的警告。
-delete [-alias alias] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-v} {-Jjavaoption}
從密鑰倉庫中刪除 alias 所標識的項。如果沒有在命令行上提供別名，則用戶將得到要求輸入別名的提示。
獲取幫助
-help
列出所有的命令及其選項。
示例
假設您要創建一個密鑰倉庫以管理您的公鑰/私鑰對來自您所信任實體的證書。
生成密鑰對
您首先要做的是創建一個密鑰倉庫和生成密鑰對。您可以使用以下命令：
keytool -genkey -dname "cn=Mark Jones, ou=JavaSoft, o=Sun, c=US"
-alias business -keypass kpi135 -keystore /working/mykeystore
-storepass ab987c -validity 180
（請注意：鍵入該命令時必須使其成為一行。此處用多行來顯示，主要是為了可讀性。）
該命令將在 C 盤的“working”目錄（假設它還不存在）中創建名為“mykeystore”的密鑰倉庫，并賦予它口令“ab987c”。它將為實體生成公鑰/私鑰對，該實體的“特征名”為：常用名“Mark Jones”、組織單位“JavaSoft”、組織“Sun”和兩個字母的國家代碼“US”。它使用缺省的“DSA”密鑰生成算法來創建密鑰，兩個密鑰（公鑰與私鑰）的長度都是 1024 位。
它創建自簽名證書（使用缺省的“帶 DSA 的 SHA1”簽名算法），該證書包括公鑰和特征名信息。該證書的有效期為 180 天，且與別名“business”所代表的密鑰倉庫項關聯。私鑰被賦予口令“kpi135”。
如果采用選項的缺省值，可以大大縮短該命令。實際上，這些選項并不是必需的；對于有缺省值的選項，未指定時將使用缺省值，對于任何被要求的值，您將會得到要求輸入它的提示。因此，您可以只使用下面的命令：
keytool -genkey
這種情況下，將創建一個具有別名“mykey”的密鑰倉庫項，它含有新生成的密鑰對和有效期為 90 天的證書。該項被放在您的宿主目錄下一個名為“.keystore”的密鑰倉庫中（如果該密鑰倉庫并不存在，則將創建它）。您將得到要求輸入特征名信息、密鑰倉庫口令和私鑰口令的提示。
其余示例假設您執行了未指定選項的 -genkey 命令，且用上述第一個 -genkey 命令中給出的值來回答提示要求（私鑰口令為“kpi135”等等）。
從認證機構請求已簽名的證書
目前為止我們所具有的就是自簽名證書。證書如果由認證機構 (CA) 簽名，將更有可能得到別人的信任。要得到這樣的簽名，首先要用以下命令生成證書簽名請求 (CSR)：
keytool -certreq -file MarkJ.csr
這將為缺省別名“mykey”所標識的實體生成 CSR，并將此請求放在名為“MarkJ.csr”的文件中。將此文件提交給某個 CA（例如 VeriSign, Inc.）。該 CA 將對您這個請求者進行認證（通常是離線的），然后返回它們所簽名的證書，用于認證您的公鑰。（某些情況下，它們實際上將返回證書鏈，鏈中每個證書都認證前一個證書的簽名人的公鑰。）
導入 CA 的證書
自簽名證書必須用證書鏈代替，鏈中的每個證書都認證前一個證書的簽名人的公鑰，直到“根”CA 為止。
在導入 CA 的答復之前，在您的密鑰倉庫中或 cacerts 密鑰倉庫文件（如導入命令中所述）中需要有一個或多個“可信任”證書：
如果該認證答復是個證書鏈，您只需要鏈中最頂部的證書（即用于認證根 CA 的公鑰的“根” CA 證書）。
如果該認證答復是單個證書，您需要發放 CA（即簽名該證書的認證機構）的證書，如果此證書不是自簽名的，則需其簽名人的證書，以此類推，直到自簽名的“根” CA 證書為止。
“cacerts”密鑰倉庫文件發送時附有五個 VeriSign 根 CA 證書，因此您可能并不需要導入 VeriSign 證書以作為密鑰倉庫中的可信任證書。但如果您請求由另一個 CA 簽名的證書，而認證該 CA 的公鑰的證書未被加到“cacerts”中，則您需要將來自該 CA 的證書作為“可信任證書”導入。
來自 CA 的證書通常是自簽名的或是由另一個 CA 簽名的（這種情況下您還需要認證該 CA 的公鑰的證書）。假設 ABC, Inc. 公司是 CA，而您從該公司獲得一個聲稱是自簽名證書的名為“ABCCA.cer”的文件，它用于認證該 CA 的公鑰。
在將證書作為一個“可信任”證書導入之前，要十分小心，務必保證該證書是有效的！先查看一下（用 keytool -printcert 命令，或用不帶 -noprompt 選項的 keytool -import 命令）以確保所顯示的證書指紋與所預計的相匹配。然后可以給發送證書的人打電話，將您所看到的指紋與他們所提供的（或安全公鑰儲存庫所顯示的）進行比較。只有兩者相等才可保證證書在傳送途中沒有被其它人（例如，攻擊者）的證書所更換。如果發生了這樣的攻擊，而您未檢查證書即將其導入，那么您就會信任攻擊者所簽名的任何東西。
如果您相信證書是有效的，則您可以用以下命令將其加到密鑰倉庫中：
keytool -import -alias abc -file ABCCA.cer
這將在密鑰倉庫中用文件“ABCCA.cer”中的數據創建“可信任證書”項，并將別名“abc”賦予該項。
導入來自 CA 的認證答復
一旦導入了用于認證 CA（該 CA 是您將證書簽名請求送往之處）公鑰的證書后，或在“cacerts”文件中已有這種證書時，就可以導入該認證答復，從而用證書鏈取代您的自簽名證書。如果 CA 的答復是證書鏈，則該鏈是 CA 響應您的請求而返回的證書鏈；如果 CA 的答復是一個證書，則該鏈是用認證答復和可信任證書建立的證書鏈，這些可信任證書是密鑰倉庫（您要將認證答復導入之處）或“cacerts”密鑰倉庫文件中已有的。
例如，假設您將證書簽名請求送往 VeriSign。您可用以下命令來導入認證答復，該命令假定所返回的證書名為“VSMarkJ.cer”：
keytool -import -trustcacerts -file VSMarkJ.cer
導出用于認證您的公鑰的證書
假設您用 jarsigner 工具來簽名 Java 歸檔 (JAR) 文件。需要使用這一文件的客戶機將認證您的簽名。
認證簽名的一種方法是先將您的公鑰證書作為“可信任”項導入它們的密鑰倉庫中。您可以將證書導出并將其提供給客戶機。例如，假設項的別名為“mykey”，您可以用以下命令將您的證書導出到名為 MJ.cer 的文件中：
keytool -export -alias mykey -file MJ.cer
有了該證書以及已被簽名的 JAR 文件，客戶機就可以用 jarsigner 工具來認證您的簽名。
更改特征名但保留密鑰對
假設，譬如說因為您換了部門或搬到另一個城市去了而改變了您的特征名。如果愿意，您仍然可以使用您先前使用的公鑰/私鑰對而只對特征名進行更新。例如，假設您的名字叫 Susan Miller，并用別名 sMiller 和以下的特征名創建了初始密鑰項：
"cn=Susan Miller, ou=Finance Department, o=BlueSoft, c=us"
假設您從財務部門換到了會計部門。您仍然可使用先前所生成的公鑰/私鑰對，而用以下方法對特征名進行更新。首先，復制您的密鑰項：
keytool -keyclone -alias sMiller -dest sMillerNew
（您將得到要求輸入密鑰倉庫口令和初始密鑰口令及目標密鑰口令的提示，因為在命令行沒有提供這些信息。）現在，您需要更改與復制項關聯的證書鏈以使鏈中的第一個證書使用您的新特征名。先用相應名稱生成自簽名證書：
keytool -selfcert -alias sMillerNew
-dname "cn=Susan Miller, ou=Accounting Department, o=BlueSoft, c=us"
然后根據該新證書中的信息生成證書簽名請求：
keytool -certreq -alias sMillerNew
當您得到 CA 認證答復后，將其導入：
keytool -import -alias sMillerNew -file VSSMillerNew.cer
導入認證答復后，您也許會要刪除使用舊特征名的初始密鑰項： keytool -delete -alias sMiller