Tại sao Windows 2012 R2 không tin tưởng chứng chỉ tự ký của tôi?


9

Trong môi trường thử nghiệm, tôi hiện đang bị trì hoãn việc thử nghiệm một số thứ cần được triển khai sớm (thực tế đã có, nhưng bạn biết thời hạn trôi qua như thế nào ...) vì Windows từ chối tin tưởng vào chứng chỉ tự ký mà chúng tôi có trong chúng tôi môi trường thử nghiệm bị cô lập. Mặc dù tôi chỉ có thể giải quyết vấn đề với chứng chỉ "thực" và một số thủ thuật DNS, vì lý do bảo mật / ngăn cách mà tôi không nói là chứng chỉ.

Tôi đang cố gắng kết nối với một máy chủ email dựa trên Linux có tên Zimbra; nó đang sử dụng chứng chỉ OpenSSL tự tạo. Mặc dù các trang Google đã bật lên đề cập cụ thể đến các trang web IIS có chứng chỉ tự ký IIS, tôi không nghĩ rằng phương pháp tạo ra nó thực sự quan trọng.

Theo hướng dẫn tôi tìm thấy ở đâyđây , đây chỉ là một vấn đề đơn giản khi cài đặt chứng chỉ vào cửa hàng Cơ quan chứng nhận gốc đáng tin cậy của máy tính địa phương. Những gì tôi đã làm, cũng như sao chép thủ công chứng chỉ và nhập trực tiếp chứng chỉ qua phần đính vào MMC. Đăng xuất và khởi động lại không thay đổi bất cứ điều gì.

Đây là lỗi chứng chỉ tôi nhận được mỗi lần: nhập mô tả hình ảnh ở đây

Và đây là Đường dẫn chứng nhận (spoiler: chỉ là chứng chỉ): nhập mô tả hình ảnh ở đây

Cuối cùng, đây là chứng chỉ được cất giấu an toàn trong kho chứng chỉ của máy tính cục bộ, chính xác như hướng dẫn mà tôi đã tìm thấy nói rằng chúng nên là: nhập mô tả hình ảnh ở đây

Các hướng dẫn này đặc biệt tham khảo Vista (tốt, thứ hai không đề cập đến HĐH) và IIS, trong khi tôi đang sử dụng Máy chủ 2012 R2 kết nối với máy chủ dựa trên Linux; có một số khác biệt trong trình hướng dẫn nhập (chẳng hạn như trình duyệt của tôi có tùy chọn nhập cho người dùng hiện tại hoặc hệ thống cục bộ, mặc dù tôi đã thử cả hai), vậy có lẽ tôi phải làm gì khác ở đây? Một thiết lập ở đâu đó mà tôi không thấy phải thay đổi để làm cho nó thực sự tin tưởng vào chứng chỉ mà tôi đã nói với nó để tin tưởng?

Cách chính xác để làm cho Windows Server 2012 R2 tin tưởng vào chứng chỉ tự ký?


Không thể tái tạo vấn đề của bạn. Nếu bạn sử dụng "Tạo chứng chỉ tự ký" của IIS và chọn cài đặt nó trong cửa hàng cá nhân (cũng đã thử cửa hàng Web Hosting), thì không có vấn đề gì cả. Làm thế nào bạn tạo ra chứng chỉ? Từ IIS hoặc từ chứng nhận MMC snapin?

Bạn đã thử chọn cửa hàng đích một cách rõ ràng (nhập từ trong bảng điều khiển mmc) chưa?
JoaoCC

@SujaySarma Nó không dành cho trang web IIS, mà dành cho ứng dụng Linux có tên Zimbra. Đó là chứng chỉ tự ký OpenSSL.
Kromey

@ user1703840 Có, tôi đã chỉ định rõ ràng cửa hàng đích, cũng như cho phép Windows tự động chọn nó, thông qua cả MMC và trình hướng dẫn nhập chứng chỉ trong IE. Kết quả tương tự, hoặc là không có.
Kromey

Huh? Linux đến từ đâu? Toàn bộ câu hỏi của bạn và các liên kết bạn đã đăng (bao gồm ảnh chụp màn hình của bạn) đối phó với Windows Server 2012 R2 và IIS. Vui lòng làm rõ.

Câu trả lời:


1

Lỗi bạn đang nhận không phải là chứng chỉ gốc đáng tin cậy, mà là không thể xác minh chuỗi thành chứng chỉ tin cậy. Nếu bất kỳ phần nào của chuỗi bị hỏng, không đáng tin cậy hoặc bị thiếu, bạn sẽ nhận được một lỗi như vậy. Lỗi mà tôi nhận được với một root không đáng tin cậy, tự kýlà đây: Chứng chỉ gốc CA này không đáng tin cậy. Để kích hoạt lòng tin, hãy cài đặt chứng chỉ này trong cửa hàng ủy quyền chứng nhận gốc đáng tin cậy. Nhưng đối với bạn, nó nói rằng nó không thể xác minh tối đa chứng chỉ gốc đáng tin cậy. Điều này có thể là trong quá trình tự ký, bạn có thể đã yêu cầu openssl ký chứng chỉ với một gốc khác (không phải tự ký) hoặc có thể chưa được đặt làm CA gốc. Nếu đó là lần đầu tiên, bạn phải tin vào gốc mà nó đã được ký thay thế. Nếu đó là cái sau, thì việc đặt một vài thuộc tính trong openssl.conf là vấn đề.


Các ảnh chụp màn hình cho thấy chứng chỉ được cài đặt trong Trusted Root CA và cũng cho thấy toàn bộ chuỗi là chính chứng chỉ - đó là gốc và do đó, trong Root Root CA đáng tin cậy. Câu hỏi là tại sao không?
Kromey

Tôi đang nói nó có thể không phải là root, không phải là nó không được thêm vào kho gốc đáng tin cậy. Lỗi là điều kỳ lạ về nó - không nên nói rằng nó không thể xác minh nó với một CA đáng tin cậy, nếu nó được coi là một CA - đó là lý do tại sao tôi cho rằng nó không thực sự là một root, nhưng đã ký với giấy chứng nhận khác.
flashbang

hãy thử chạy lệnh này trên hộp bạn đang cố lấy chứng chỉ cho: openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -sha256 -nodesvà nhập chứng chỉ đó vào cửa hàng CA gốc đáng tin cậy. (tất nhiên, cũng như cấu hình nó thành chứng chỉ và khóa được sử dụng bởi Zimbra).
flashbang

Ồ, tôi hiểu ý của bạn. Xin lỗi tôi hiểu lầm. Nhưng nếu nó không phải là root, không nên xuất hiện trong cửa sổ Chứng nhận Đường dẫn? Thật không may, trong thực tế, tôi không thể kiểm tra điều này thêm nữa - tôi đã có được chứng chỉ hợp pháp của chúng tôi và cùng với một chút hack trong hoststập tin khiến nó hoạt động theo cách đó.
Kromey

Chứng chỉ của bạn là từ một CA gốc, dựa trên ảnh chụp màn hình. Nếu bạn xem chi tiết chứng chỉ cho idp.godaddy.com , toàn bộ đường dẫn được trình bày và bạn có thể sử dụng nó làm so sánh. Nếu bạn nhìn vào các thuộc tính của chứng chỉ trong MMC, nó có bao gồm xác thực máy chủ trong mục đích chứng chỉ không? (Nhấp chuột phải vào chứng chỉ trong ảnh chụp màn hình thứ hai và chọn thuộc tính).
John Auld

1

từ những gì tôi có thể tìm ra, bạn cần thêm zmaster làm CA nguồn đáng tin cậy vì đó là cơ quan phát hành, WS2k12 đang cố gắng xác minh chứng chỉ đối với máy chủ lưu trữ mà nó không biết gì. Bạn đúng ở chỗ phương thức tạo không quan trọng nhưng nguồn có thể kiểm chứng được. Điều này có tác dụng mà bạn gặp phải: WS2k12 không tin tưởng một chứng chỉ chỉ vì nó có tên là $ Random_issuing_ mượtity, nó cần có thể xác minh chứng chỉ.


Đó là chứng chỉ tự ký - bằng cách đặt chứng chỉ vào cửa hàng Root Root đáng tin cậy, theo định nghĩa bạn sẽ tin tưởng nhà phát hành.
Chris McKeown

Trừ khi tôi thiếu một cái gì đó, đó chính xác là những gì tôi đã làm - xem ảnh chụp màn hình thứ ba hiển thị chứng chỉ của zmaster trong cửa hàng Trusted Root CA.
Kromey

0

Tôi gặp vấn đề tương tự, hóa ra giải pháp của tôi là cập nhật các tệp .crt và .key cho máy chủ thư như được sử dụng bởi dovecot. Exim4 trên thư đã có bộ chứng chỉ / khóa được cập nhật, nhưng dovecot vẫn đang trỏ đến bộ chứng chỉ / khóa cũ.

Cặp cert / key cũ hoạt động tốt trong hầu hết các tình huống, nhưng không phải với triển vọng.com cũng như với MS Outlook 2013.

Các vấn đề với triển vọng.com khiến tôi phải nâng cấp chứng chỉ exim4 gần đây - hiện dovecot [và máy chủ webmail] cũng sử dụng các tệp cert (và khóa) mới. Bản thân máy chủ thư cũng đã được nâng cấp gần đây [từ bản nén cũ của Debian thành tiếng khò khè], thiết lập cũ vẫn ổn với bộ chứng chỉ / khóa cũ, nhưng sau khi nâng cấp, tôi cần tạo bộ chứng chỉ / khóa mới trước đó Các sản phẩm MS sẽ hoạt động đúng với máy chủ thư.


0

Tôi nghĩ vấn đề là làm thế nào bạn truy cập được tài nguyên. Đối với mạng cục bộ của bạn, bạn có thể sử dụng tên máy chủ thay vì tên miền đầy đủ. Tuy nhiên, chứng chỉ của bạn được cấp theo tên miền đầy đủ.


Câu hỏi này đã có một câu trả lời được chấp nhận.
BE77Y

-1

Cài đặt chứng chỉ cho Cơ quan chứng nhận gốc đáng tin cậy và Nhà xuất bản đáng tin cậy.

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.