Làm cách nào để tìm ra kho khóa JVM của tôi đang sử dụng?


125

Tôi cần nhập chứng chỉ vào kho khóa JVM của mình. Tôi đang sử dụng như sau:

keytool -import -alias daldap -file somecert.cer

vì vậy tôi có thể cần phải thay đổi cuộc gọi của mình thành một cái gì đó như:

keytool -import -alias daldap -file somecert.cer -keystore cacerts storepass changeit

1
Bạn cần nhập chứng chỉ vào kho ủy thác JVM của mình , trừ khi đó là CSR đã ký, trong trường hợp đó bạn nên nhập chứng chỉ vào kho khóa của riêng mình và bạn phải biết đó là nơi nào, nếu không bạn sẽ không thể tạo khóa hoặc CSR.
Hầu tước Lorne

Câu trả lời:


129

Kho khóa của bạn sẽ ở trong bạn JAVA_HOME---> JRE -->lib---> security--> cacerts. Bạn cần kiểm tra xem JAVA_HOME của bạn được định cấu hình ở đâu, có thể là một trong những nơi này,

  1. Máy tính ---> Nâng cao -> Biến môi trường ---> JAVA_HOME

  2. Máy chủ của bạn khởi động các tập tin hàng loạt.

Trong lệnh nhập của bạn -keystore cacerts (cung cấp đường dẫn đầy đủ đến JRE ở trên thay vì chỉ nói các đoạn trích).


6
/ Thư viện / Java / Trang chủ / lib / bảo mật / trích dẫn trên Mac OS X 10.9
Sam Barnum

9
* "JAVA_HOME ---> JRE -> lib ---> security -> cacerts" Lưu ý "s" ở cuối, chỉ dành cho bất kỳ độc giả nào trong tương lai.
Keir Nellyer

4
Vì vậy, nếu tôi cài đặt một phiên bản Java mới và JAVA_HOME đang trỏ đến một thư mục mới, tôi có gặp vấn đề về chứng chỉ không?
Kirill Yunussov

1
@Murphy: Điều này có thể giúp bạn stackoverflow.com/questions/5251323/ trên
kosa

4
Tôi nghĩ đây là vị trí cửa hàng tin cậy hơn là vị trí cửa hàng chính.
dùng2001850

35

Vị trí kho khóa

Mỗi lệnh keytool có một -keystoretùy chọn để chỉ định tên và vị trí của tệp kho khóa liên tục cho kho khóa được quản lý bởi keytool. Kho lưu trữ theo mặc định được lưu trữ trong một tệp có tên .keystoretrong thư mục chính của người dùng, như được xác định bởi thuộc tính hệ thống "user.home". Đặt tên người dùng uName, giá trị thuộc tính "user.home" mặc định là

C:\Users\uName on Windows 7 systems
C:\Winnt\Profiles\uName on multi-user Windows NT systems
C:\Windows\Profiles\uName on multi-user Windows 95 systems
C:\Windows on single-user Windows 95 systems

Do đó, nếu tên người dùng là "cathy", "user.home" mặc định là

C:\Users\cathy on Windows 7 systems
C:\Winnt\Profiles\cathy on multi-user Windows NT systems
C:\Windows\Profiles\cathy on multi-user Windows 95 systems

http://docs.oracle.com/javase/1.5/docs/tooldocs/windows/keytool.html


Tôi đã tìm kiếm ~/.keystoretập tin bí ẩn này ! Nếu tôi bỏ -keystoretham số, tôi không thể tìm ra keytoolmục tiêu kho khóa mặc định nào . Tôi tiếp tục tìm kiếm cacertsmột nơi khác trên máy. Tôi không mong đợi keytool sẽ tạo ~/.keystoretrong thư mục chính, cũng không được đặt tên .keystorethay thế cacerts. Bạn đã điền vào chỗ trống mà mọi người Java nên ghi lại! Cảm ơn bạn!
George Pantazes

26

Mac OS X 10.12 với Java 1.8:

$ JAVA_HOME / jre / lib / bảo mật

cd $JAVA_HOME

/ L Library / Java / JavaVirtualMachines / jdk1.8.0_40.jdk / Content / Home

Từ đó, nó ở trong:

./jre/lib/security

Tôi có một kho khóa trong đó.

Để chỉ định đây là một tùy chọn VM:

-Djavax.net.ssl.trustStore=/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit

Tôi không nói đây là cách chính xác (Tại sao java không biết nhìn vào bên trong JAVA_HOME?), Nhưng đây là điều tôi phải làm để nó hoạt động.


16

Bạn có thể tìm thấy nó trong thư mục "Trang chủ" của bạn:

Trên Windows 7:

C:\Users\<YOUR_ACCOUNT>\.keystore

Trên Linux (Ubuntu):

/home/<YOUR_ACCOUNT>/.keystore

4
tôi không có thư mục này trên windows
simgineer

1
Tôi đã làm một -keygen mà không chỉ định kho lưu trữ khóa, hy vọng nó sẽ tạo một cái trong thư mục hiện tại, nhưng nó đã tạo nó trong nhà tôi như bạn nói. ~ / .keystore Không thể tìm thấy nó từ lâu! :-) Cảm ơn.
Eurospophone

hãy để tôi nói thêm rằng theo cygwin, đường dẫn windows được sử dụng vì thuộc tính java user.homebằng với $HOMEDRIVE$HOMEPATHcài đặt của windows và không $HOMEđược đặt bởi cygwin ở đâu HOMEDRIVE=C:HOMEPATH=\Users\[YOUR ACCOUNT]
user1708042

13

Điều này làm việc cho tôi:

#! / thùng / bash

CACERTS = $ ( readlink - e $ ( dirname $ ( readlink - e $ ( mà keytool ))) /../ lib / security / cacerts )

if keytool - list - keystore $ CACERTS - storepass changeit > / dev / null ; sau đó  
    tiếng vang $ CACERTS

    echo khác 'Không thể tìm thấy tập tin cacerts.' > & 2 
    thoát 1 fi 

Chỉ dành cho Linux. Solaris của tôi không có đường dẫn. Cuối cùng, tôi đã sử dụng Perl-Script này:

#! / usr / bin / env perl sử dụng nghiêm ngặt ; sử dụng cảnh báo ; sử dụng Cwd qw ( realpath ); 
$ _ = realpath (( grep {- x && - f } map { "$ _ / keytool" } split ( ':' , $ ENV { PATH })) [ 0 ]); chết "Không thể tìm thấy keytool" trừ khi được xác định $ _ ; $ keytool của tôi = $ _ ; in


  
  

 "Sử dụng '$ keytool'. \ N" ; 
s / keytool $ / /;
$ _ = realpath ($ _. '../ lib / security / cacerts ');
chết "Không thể tìm thấy cacerts" trừ khi -f $ _;
$ cacerts của tôi = $ _;
in "Nhập vào ' $ cacerts '. \ n";
`$ keytool -list -keystore" $ cacerts "-storepass changeit`;
chết "Không thể đọc khóa chứa" trừ khi $? == 0;
thoát nếu $ ARGV [0] eq ' - d ';
foreach (@ARGV) {
    $ cert của tôi = $ _;
    s /\.[ucci.[+$//;
    bí danh $ của tôi = $ _;
    in "Nhập ' $ cert ' dưới dạng ' $ bí danh '. \ n";
    `keytool -importcert -file" $ cert "-alias" $ alias "-keystore" $ cacerts "-storepass changeit`;
    cảnh báo "Không thể nhập chứng chỉ: $?" trừ khi $? == 0;
}

6

Như DimtryB đã đề cập, theo mặc định, kho khóa nằm trong thư mục người dùng. Nhưng nếu bạn đang cố cập nhật cacertstệp, để JVM có thể chọn các khóa, thì bạn sẽ phải cập nhật cacertstệp theo jre/lib/security. Bạn cũng có thể xem các khóa bằng cách thực hiện lệnh keytool -list -keystore cacertsđể xem chứng chỉ của bạn có được thêm không.


Rất vui khi biết rằng lệnh keytool lib/securitytự động thêm đường dẫn chính xác nếu chỉ được cung cấp tên tương đối.
ceving

1
Nhưng điều này sẽ không làm việc cho -importcert. Lệnh list hiển thị các chứng chỉ toàn hệ thống nhưng lệnh nhập sẽ tạo một tệp mới trong thư mục hiện tại.
ceving

1
updatedb; locate cacertsgiúp tìm vị trí cài đặt của các tập tin điện tử.
sjas

5

Trên Debian, sử dụng phiên bản openjdk "1.8.0_212", tôi đã tìm thấy các đoạn trích ở đây:

 /etc/ssl/certs/java/cacerts

Chắc chắn sẽ có ích nếu có một lệnh tiêu chuẩn sẽ in ra đường dẫn này.


1

Đối với tôi sử dụng hình ảnh Docker OpenJDK 12 chính thức , vị trí của kho khóa Java là:

/usr/java/openjdk-12/lib/security/cacerts

Đó là một cửa hàng ủy thác, không phải là kho khóa.
Hầu tước Lorne

1
Đầu tiên: Nếu bạn đọc kỹ câu hỏi (và nhận xét của riêng bạn), nó có vẻ giống như Truststore, nơi chứng nhận nên được nhập. Thứ hai, sự khác biệt giữa Truststore và Keystore khá mất phương hướng - và cả hai đều sử dụng thuật ngữ "Keystore" btw, vì cả hai đều sử dụng định dạng cả hai. Thứ ba: Nếu bạn xem lệnh nhập, keytool -import -file example.crt -alias exampleCA -keystore truststore.jksbạn cũng sử dụng tham số -keystore... khá không rõ IMHO. Và cuối cùng nhưng không kém phần quan trọng: Tôi đã tìm kiếm về vấn đề chính xác đó - và thấy đó là câu hỏi. Có thể những người khác exp giống nhau.
jonashackt

Hơn nữa, tất cả các câu trả lời khác cũng đề cập đến cái gọi là "Truststore" mà JDK sử dụng để xác thực. Vì vậy, bạn cũng downvote tất cả các câu trả lời khác là tốt? Tôi đã nhận được một upvote, vì vậy đã có ai đó câu trả lời của tôi giúp đỡ.
jonashackt

0

Chúng tôi đã gặp phải sự cố này trên Tomcat đang chạy từ thư mục jre đã bị xóa (gần như hoàn toàn) sau khi cập nhật jre tự động, do đó, jre đang chạy không thể tìm thấy jre ... / lib / security / cacerts vì nó không còn tồn tại.

Khởi động lại Tomcat (sau khi thay đổi cấu hình để chạy từ vị trí jre khác nhau) đã khắc phục sự cố.


0

Ngoài tất cả các câu trả lời trên:

Nếu cập nhật tệp cacerts trong thư mục JRE không có ích, hãy thử cập nhật nó trong JDK.

C: \ Tệp chương trình \ Java \ jdk1.8.0_192 \ jre \ lib \ security

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.