Apache couchDB CA đã ký các sự cố chứng chỉ

Question

Tôi đang chạy phiên bản Apache CouchDB (phiên bản 1.3.0) trên máy chủ Ubuntu 12.10 trên đám mây (AWS). Tôi đang cố gắng để có được SSL làm việc trên trường hợp couchDB của tôi.

Cài đặt SSL cơ bản rất dễ dàng. Tôi đã đặt chứng chỉ và khóa của tôi trong một thư mục và uncomment dòng sau trong file local.ini tôi

httpsd = {couch_httpd, start_link, [https]} 
cert_file = /usr/local/etc/couchdb/certs/mycouchdbserver_cert.pem 
key_file = /usr/local/etc/couchdb/certs/mycouchdbserver_key.pem 

tôi cũng đã thực hiện chắc chắn rằng các quyền sở hữu trên những tập tin này là chính xác.

Tính năng này hoạt động tốt, máy chủ couchDB khởi động, bạn có thể điều hướng đến https://mycouchdbserver.com/_utils/ mà không gặp sự cố.

kiểm tra sử dụng openssl

openssl s_client -showcerts -connect mycouchdbserver.com:443 

Cung cấp kết quả chính xác cho cấu hình tiêu chuẩn SSL

Khi kiểm tra các thiết lập trên trang web DigiCert (công ty SSL Certs được mua thông qua - kiểm tra liên kết: http://www.digicert.com/help/) Tôi nhận được lỗi sau:

Máy chủ không gửi chứng chỉ trung gian được yêu cầu.

Khi mua chứng chỉ SSL, tôi đã nhận được chứng chỉ trung gian từ DigiCert và cũng đã tải xuống chứng chỉ gốc cho DigiCert.

Trong tập tin cấu hình local.ini cho CouchDB bạn có thể sử dụng chúng với các lĩnh vực cấu hình sau:

verify_ssl_certificates = true 
cacert_file = xxxx 

Vấn đề của tôi là tôi không thể có được điều này để làm việc và đã thử tất cả các kết hợp có thể để có được điều này để công việc. Dưới đây là những gì tôi đã cố gắng:

1. Cố gắng thiết lập cacert_file đến cert trung gian từ DigiCert
2. Cố gắng thiết lập cacert_file với chứng chỉ gốc trong/etc/ssl/certs
3. Cố gắng thêm cert gốc từ trang web DigiCert vào/usr/shared/ca-certs/và sau đó chạy dpkg-reconfigure ca-certificate để cài đặt chứng chỉ gốc mới và thiết lập cacert_file thành chứng chỉ được mã hóa mới trong/etc/ssl/certs
4. Đã thử kết hợp chứng chỉ và trung gian cert trong một tệp được sử dụng cho cert_file
5. Đã thử kết hợp cert, cert trung gian và cert gốc vào 1 tệp pem được sử dụng cho cert_file

Tất cả các lỗi trên đều ném lỗi trong nhật ký couchDB. Một số cung cấp cho một lượng khối lượng của đầu ra trong các lỗi bản ghi nhưng sử dụng số 3, tôi nhận được

=ERROR REPORT==== 11-Jun-2013::11:35:30 === 
SSL: hello: ssl_handshake.erl:252:Fatal error: internal error 

Và thử nghiệm với openssl tôi nhận được

CONNECTED(00000003) 
16871:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1099:SSL alert number 80 
16871:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: 

Có ai có bất kỳ ý tưởng về cách sử dụng các verify_ssl_certificates , chứng chỉ gốc và chứng chỉ trung gian chính xác với couchDB

Tôi đã đọc tất cả tài liệu trực tuyến và không có gì đã giúp

Cảm ơn trước Andrew

Answer 1

Đối với bất cứ ai quan tâm đây là cách cuối cùng chúng tôi đã giải quyết được vấn đề:

Có vẻ rằng chúng ta không thể có được CouchDB để hoạt động đúng với chứng chỉ trung gian của chúng tôi.

Vì chúng tôi đang chạy máy chủ couchDB trên một phiên bản AWS EC2, tôi vừa tạo một bản sao ELB (Elastic Load Balancer) và tải chứng chỉ lên ELB, sau đó thêm cá thể EC2 dưới bộ cân bằng tải của tôi và định tuyến lại DNS của mình cân bằng tải (sử dụng Route53 ở đây).

Tôi sau đó tắt hoàn toàn SSL trên couchDB và đưa bắt tay SSL vào bộ cân bằng tải hỗ trợ sử dụng chứng chỉ trung gian.

Điều này có nghĩa là các dấu phẩy giữa ELB và couchDB không an toàn nhưng đối với chúng tôi điều đó là tốt.

Điều này cũng có nghĩa là bây giờ chúng ta có thể thêm vào nhiều máy chủ couchDB theo ELB cho khả năng mở rộng để 2 con chim 1 giải pháp đá.

Bạn cũng có thể thực hiện giải pháp tương tự với Nginx nhưng việc thêm và quản lý ELB là dễ dàng và ổn định vì vậy chúng tôi đã đi với giải pháp ELB.

Answer 2

Có một vài điều mà CouchDB nhạy cảm. Một vấn đề là biểu mẫu phát hành lại của namecheap. Nếu bạn sử dụng namecheap để xử lý CSR của mình, bạn sẽ gặp vấn đề. Ví dụ, tôi đã mua một cert RapidSSL qua namecheap, và để cấp lại nó đúng tôi phải đi trực tiếp đến GeoTrust để có được một cert làm việc: https://products.geotrust.com/orders/orderinformation/authentication.do

Để tạo Certs SSL, tôi đã làm như sau:

$ openssl genrsa -des3 -out server.pem 2048 

Cụm mật khẩu đã được sử dụng. Nó phải được sử dụng cho các lệnh khác đừng quên nó.

Tạo yêu cầu cert:

$ openssl req -new -key server.pem -out server.csr 

Chỉ trả lời như sau:

• Nước
• Nhà nước
• Địa phương
• Tổ chức
• Tên thường

Tất cả các câu hỏi khác được để trống.

Lệnh này tạo ra khóa bí mật được mã hóa mà CouchDB sẽ sử dụng:

$ openssl rsa -in server.pem -out server.key 

Khi được hỏi cho csr, qua các nội dung của tập tin server.csr vào hộp văn bản.

Sau một loạt email, bạn cuối cùng sẽ nhận được chứng nhận. Một vấn đề khác là cách CouchDB xử lý chứng chỉ chuỗi. Đừng lo lắng về việc tạo ra một chứng chỉ xích; bỏ qua các crt trung gian, bạn chỉ cần cert cụ thể cho miền của bạn cho couchdb để hoạt động đúng.

sửa đổi những dòng sau đây trong tập tin CouchDB local.ini:

[daemons] 
; enable SSL support by uncommenting the following line and supply the PEM's below. 
; the default ssl port CouchDB listens on is 6984 
httpsd = {couch_httpd, start_link, [https]} 

[ssl] 
cert_file = /path/to/ssl/cert/server.crt 
key_file = /path/to/ssl/cert/server.key 

Tôi không chắc chắn nếu điều này sẽ tạo sự khác biệt, nhưng chắc chắn rằng các điều khoản trên Certs SSL được thiết lập để 600. Ngoài hãy chắc chắn để chown các certs bởi người sử dụng quá trình CouchDB:

# in the ssl cert directory 
sudo chmod 600 ./* 
sudo chown couchdb:couchdb ./* 

Và khởi động lại máy chủ của bạn:

sudo /etc/init.d/couchdb restart 

Answer 3

Tóm tắt: Bạn sẽ cần CouchDB 1.6.0 hoặc mới hơn để làm việc này (hoặc vá phiên bản hiện tại của bạn).

Tôi đã gặp sự cố tương tự khi chạy CouchDB 1.4.0 hoặc Raspberry Pi (raspbian jessie).

Tôi khẳng định với lệnh sau đó máy chủ CouchDB chỉ gửi giấy chứng nhận riêng của mình thay vì toàn bộ chuỗi chứng chỉ, như là bắt buộc spec TLS:

openssl s_client -connect myhostname:6984 -showcerts 

Điều này cho thấy chỉ có một chứng chỉ. Ngoài ra, nó báo cáo một sự thất bại xác minh. Chứng chỉ của tôi là từ Namecheap. Trong khi tôi có chứng chỉ gốc của tổ chức phát hành (COMODO RSA) được cài đặt trên máy khách, thì ít nhất phải có một chứng chỉ trung gian để hoàn thành chuỗi.

Lưu ý rằng một số trình duyệt có thể tự động tìm nạp các chứng chỉ trung gian và tất cả đều xuất hiện tốt. Tuy nhiên, hầu hết các công cụ dòng lệnh (curl, perl, python, openssl) đều thất bại. Cũng thú vị là trên trình duyệt Chrome của Android nó thỉnh thoảng cho thấy một khóa màu xanh lá cây (tất cả tốt) và vào những thời điểm khác báo cáo rằng trang web không thể được xác minh. Tôi nghi ngờ rằng nó đang sử dụng bộ nhớ cache chứng chỉ cục bộ. Nếu tôi tình cờ duyệt một trang web cung cấp cùng một chứng chỉ trung gian, thì việc xác minh sau đó sẽ thành công cho máy chủ CouchDB của tôi, cho đến khi bộ nhớ cache bị xóa.

Sau khi đào sâu vào nguồn CouchDB và Erlang, tôi đã tìm thấy thông tin sau: Erlang có thể được chuyển qua tệp PEM dưới dạng 'cacertfile'. Điều này được sử dụng cho cả việc xác minh chứng chỉ ứng dụng khách (nếu được bật) và để soạn chuỗi chứng chỉ đầy đủ được gửi tới máy khách trong thông báo Chứng chỉ TLS. Tuy nhiên, phiên bản CouchDB của tôi không vượt qua đối số cacertfile, trừ khi được chỉ định cacert_fileVÀverify_ssl_certificates = true. Tuy nhiên, nếu các điều kiện đó được đáp ứng, nó sẽ bỏ qua khóa máy chủ và chứng chỉ!

Tôi thấy rằng điều này đã được gửi dưới dạng lỗi COUCHDB-2028. Lưu ý rằng lỗi nói rằng điều này đã được giải quyết trong phiên bản 1.7.0, mà tôi tin rằng không tồn tại.

Tôi thấy rằng the fix was applied to the official CouchDB repository vào ngày 2014-01-30.Thật không may là lịch sử sửa đổi chính thức không hiển thị bản sửa lỗi, nhưng việc đào bới thông qua git repo cho thấy rằng bản sửa lỗi lần đầu tiên được chính thức phát hành trong CouchDB 1.6.0.

Trong trường hợp của tôi, tôi đã có thể tải xuống và biên dịch và cài đặt CouchDB 1.6.1 từ nguồn. Bây giờ, lệnh trên openssl hiển thị chuỗi 4 chứng chỉ được gửi bởi máy chủ CouchDB. Tôi cung cấp khóa máy chủ và cert, cộng với cacert_file với gói CA được tải xuống từ Namecheap. verify_ssl_certificates là sai. Tất cả các trình duyệt mà tôi đã thử nghiệm đều tin tưởng trang web, cộng với các công cụ dòng lệnh của tôi đang hoạt động mà không cần hack để vô hiệu xác minh.