Lỗi SSL - không thể đọc chứng chỉ máy chủ từ tệp

Tôi đã thiết lập SSL cho tên miền của mình ngày hôm nay và đã gặp phải một vấn đề khác - tôi hy vọng ai đó có thể làm sáng tỏ ..

Tôi tiếp tục nhận được các thông báo lỗi sau:

[lỗi] Ban đầu: Không thể đọc chứng chỉ máy chủ từ tệp /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt
[lỗi] Lỗi thư viện SSL: 218529960 lỗi: 0D0680A8: thói quen mã hóa asn1: ASN1_CHECK_TLEN: thẻ sai
[lỗi] Lỗi thư viện SSL: 218595386 lỗi: 0D07804A: thói quen mã hóa asn1: ASN1_ITEM_EX_D2I: lỗi asn1 lồng nhau

Tôi đang chạy Apache 2.2.16 và Ubuntu 10.10. Tệp .crt của tôi có thẻ Bắt đầu và Kết thúc và đã được sao chép chính xác từ email xác nhận tôi nhận được, rất bực bội!

Chúc mừng!

Chỉnh sửa >> Khi cố gắng xác minh .crt Nó dường như không hoạt động:

>> openssl x509 -không xuất hiện -text -in domain.com.crt 
không thể tải chứng chỉ
16851: lỗi: 0906D06C: Các thói quen của PEM: PEM_read_bio: không có dòng bắt đầu: pem_lib.c: 650: Mong đợi: CHỨNG NHẬN ĐƯỢC CHỨNG MINH

Ngoài ra >>

>> openssl x509 -text -inform PEM -in domain.com.crt
không thể tải chứng chỉ
21321: lỗi: 0906D06C: Các thói quen của PEM: PEM_read_bio: không có dòng bắt đầu: pem_lib.c: 650: Mong đợi: CHỨNG NHẬN ĐƯỢC CHỨNG MINH

>> openssl x509 -text -inform DER -in domain.com.crt
không thể tải chứng chỉ
21325: lỗi: 0D0680A8: thói quen mã hóa asn1: ASN1_CHECK_TLEN: thẻ sai: tasn_dec.c: 1316:
21325: error: 0D07804A: thói quen mã hóa asn1: ASN1_ITEM_EX_D2I: lỗi asn1 lồng nhau: tasn_dec.c: 380: Type = X509

Chỉnh sửa >> (Chúc mừng sự giúp đỡ bằng cách này)

>> grep '^ -----' domain.com.crt
----- BEGIN CHỨNG NHẬN -----
----- GIẤY CHỨNG NHẬN -----

Chỉ cần gửi email cho công ty cung cấp Giấy chứng nhận, họ đã trả lời>

Tôi đã kiểm tra tệp CSR mà bạn đã cung cấp và tôi có thể đảm bảo rằng tệp này đã được tạo chính xác. Lỗi mà bạn hiện đang gặp phải là do bạn đang sử dụng một dòng lệnh sai để cài đặt CSR. Bạn sẽ cần sửa đổi domain.com.crt này từ dòng lệnh của bạn với tên theo tên miền của bạn.

• hiện tại crt được thiết lập thành mysite.com.crt - Tôi đã sử dụng domain.com.crt làm ví dụ

Có thể là các dòng được ^ M chấm dứt? Đây là một vấn đề tiềm ẩn khi di chuyển tệp từ Windows sang hệ thống UNIX. Một cách dễ dàng để kiểm tra là sử dụng vitrong chế độ "hiển thị cho tôi nhị phân" vi -b /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt.

Nếu mỗi dòng kết thúc bằng một điều khiển-M, như thế này

-----BEGIN CERTIFICATE-----^M
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM^M
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg^M
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x^M

bạn đã có một tệp ở định dạng kết thúc dòng Windows và apache không thích chúng.

Các tùy chọn của bạn bao gồm di chuyển tệp một lần nữa, cẩn thận hơn; hoặc sử dụng dos2unixlệnh để loại bỏ chúng; bạn cũng có thể loại bỏ chúng bên trong vi, nếu bạn cẩn thận.

Chỉnh sửa : cảm ơn @ dave_thndry_085, người chỉ ra rằng câu trả lời này không còn áp dụng vào năm 2019. Nghĩa là, Apache / OpenSSL hiện đã chấp nhận ^ dòng kết thúc M, vì vậy chúng không gây ra vấn đề. Điều đó nói rằng, các lỗi định dạng khác, một số ví dụ khác nhau xuất hiện trong các bình luận, vẫn có thể gây ra vấn đề; kiểm tra cẩn thận những thứ này nếu chứng chỉ đã được di chuyển trên các hệ thống.

Đối với bất kỳ ai đến trang này có lỗi tương tự khi cố gắng đọc Yêu cầu ký chứng chỉ (CSR) (lưu ý rằng OP đang đọc chứng chỉ): đảm bảo sử dụng đúng lệnh OpenSSL. x509dành cho chứng chỉ và reqdành cho CSR:

openssl req -in server.csr -text -noout

đấu với

openssl x509 -in server.crt -text -noout

Chỉ cần đi vòng tròn trong vòng tròn về điều này, và hóa ra tôi đã có chứng chỉ sai cách - ví dụ

SSLCertificateFile    /etc/apache2/ssl/server.key
SSLCertificateKeyFile /etc/apache2/ssl/server.crt

thay vì:

SSLCertificateFile    /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

Một cái gì đó để kiểm tra nếu bạn nhận được lỗi này.

>> openssl x509 -noout -text -in domain.com.crt 
unable to load certificate
16851:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:650:Expecting: TRUSTED CERTIFICATE

Tôi nghi ngờ rằng bạn có vấn đề với định dạng của chứng chỉ.

Chạy cả hai lệnh sau và cho chúng ta đầu ra:

openssl x509 -text -inform DER -in domain.com.crt 
openssl x509 -text -inform PEM -in domain.com.crt 

Trong trường hợp của tôi, tôi thấy chứng chỉ của mình có các ký tự "-" khác nhau. Phải là một vấn đề sao chép / dán từ quản trị viên đã đặt chứng chỉ lên máy chủ, với trình soạn thảo văn bản thay thế - với một ký tự unicode đặc biệt trên đường đi.

Điều này mất nhiều giờ để chẩn đoán, và cuối cùng tôi chỉ đoán được nó, và chỉnh sửa chứng chỉ trong vi và xóa các ký tự "-" hiện có, và gõ lại chúng.

Hy vọng điều này sẽ giúp được ai đó.

Trong trường hợp của tôi, tôi đã gặp phải lỗi của OP vì bất kỳ ai đã tạo tệp .crt cho tôi ngay từ đầu đã thực sự tạo tệp định dạng .PEM và đặt tên là .crt.

Tôi đã phát hiện ra điều này bằng cách chạy vào hướng dẫn hữu ích sau: https://support.ssl.com/Knowledridease/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certert-and-how -to-convert-them

tất cả những gì tôi phải làm là đổi tên .crt của mình thành .pem và tôi đã hoàn thành! Hướng dẫn chỉ ra rằng các lỗi từ câu hỏi của OP ngụ ý rằng tệp đầu vào đã được định dạng PEM, do đó, việc cố gắng chuyển đổi nó thành .pem từ định dạng DER là không thể thực hiện được và thực tế là không cần thiết.

Hãy chắc chắn rằng tệp của bạn không có dấu vết hoặc khoảng trắng hàng đầu trong tệp chứng chỉ. Đảm bảo cẩn thận không có khoảng trắng hoặc khoảng trống trong tệp chứng chỉ của bạn, bằng cách chọn toàn bộ văn bản và tìm kiếm khoảng trống trên trình chỉnh sửa chỉ văn bản.

Ngoài ra kiểm tra xem thực sự tất cả các tập tin được cấu hình tồn tại và là chính xác.

Ví dụ: trên bài đăng khác của bạn, bạn nói rằng tệp .key của bạn được đặt tên là domain.com.crt của tôi trong khi trên cấu hình vhost bạn có domain.com.crt

SSLCertificateFile /etc/apache2/domain.ssl/domain.ssl.crt/domain.com.crt
SSLCertificateKeyFile /etc/apache2/domain.ssl/domain.ssl.key/domain.com.key
SSLCertificateChainFile /etc/apache2/domain.ssl/ca.crt
SSLCACertificateFile /etc/apache2/domain.ssl/gs_intermediate_ca.crt

Kiểm tra lại rằng tất cả các tệp trên thực sự tồn tại và hợp lệ.

Nếu người khác gặp phải vấn đề này và nhật ký lỗi apache của bạn sẽ nói điều gì đó như:

Ban đầu: Không thể đọc chứng chỉ máy chủ từ tệp /etc/apache2/domain.com.ssl/domain.com.crt/domain.com.crt

Hãy chắc chắn rằng bạn đã không trao đổi các tệp khóa và chứng chỉ của mình trong các khai báo trong cấu hình apache. Tôi đã chỉ chìa khóa vào tệp chứng chỉ của tôi và chứng chỉ cho tệp khóa của tôi. Bài đăng này đã giúp tôi tìm ra vấn đề nhưng tôi muốn chỉ ra nó là một vấn đề / giải pháp tiềm năng khác.

Vấn đề của tôi (có cùng một lỗi trong khi cài đặt máy chủ mới với Apache 2.4) là Apache (2.4) không thể đọc tệp nhị phân .crt. Tôi đã nhập nó trong cửa hàng chứng chỉ cá nhân của mình (với mmc) và xuất nó dưới dạng X.509 (.cer) được mã hóa cơ sở 64. Đổi tên tệp đã xuất thành cùng tên (.crt) (được sử dụng trong httpd-ssl.conf của tôi) và nó đã hoạt động trở lại! Chứng chỉ tương tự hoạt động trên máy chủ cũ của tôi, có lẽ Apache 2.4 nghiêm ngặt hơn 2.2? Chúc may mắn.

Trong trường hợp của tôi, nó phải làm với BOM có mặt trong tệp. Người ta có thể lột nó như vậy:

tail -c +4 ssl.crt > ssl2.crt

Không chắc chắn nếu nó luôn mất 3 byte, vì vậy cách tốt hơn phải là:

vi -c 'se nobomb' -c wq ssl.crt

Tôi gặp lỗi tương tự vì tôi đã chuyển .key bằng tên tệp .crt

Tôi gặp vấn đề tương tự khi vô tình sử dụng chứng chỉ IIS loại p7b do khách hàng cung cấp trong cấu hình apache. Chuyển đổi định dạng cert sang x509 đã sửa lỗi. Cả hai loại trông giống nhau trên bề mặt nhưng rõ ràng là khác nhau ở bên trong.

Tôi gặp vấn đề này vì tôi đã gửi nội dung của tệp .p7b kiểu IIS được dán vào email. Nó có các thẻ "----- BEGIN CHỨNG NHẬN -----" và "----- CHỨNG NHẬN -----", giống như .pem và nội dung sử dụng mã hóa base64 trông tương tự. Tôi đã chuyển đổi nó thành tệp * .pem như vậy:

openssl pkcs7 -print_certs -in cert.p7b -out cert.cer

Sau đó, Apache 2.2 đã hạnh phúc.

Gần đây tôi đã gặp vấn đề này khi sử dụng Lets Encrypt (letencrypt) trên Windows. Chứng chỉ đã trở lại được mã hóa dưới dạng UTF-16LE. Chuyển đổi nó thành UTF-8 (sử dụng dos2unix) đã giải quyết được vấn đề.

Trong trường hợp của tôi chỉ là những dòng trống. Khi tôi dán tập tin crt từ ntepad hoặc notepad ++ trong nano luôn có smth như

sdgrgrgr rgregegreg rgrgreg
rgregreg rggregregr rgregrg

loại bỏ các khoảng trống và putig tất cả trong một dòng đã giải quyết vấn đề Eg:

sdgrgrgr
rgregegreg
rgrgreg
rgregreg
rggregregr
rgregrg