Назад | Перейти на главную страницу

Правильная конфигурация для Couchdb + SSL Ubuntu. Получение ошибки: curl: (35) Неизвестная ошибка протокола SSL при подключении к 127.0.0.1:6984

Я хочу использовать CouchDB с SSL и nodejs, и я только что переключился с самоподписанных сертификатов (которые работали более месяца) на настоящий сертификат SSL, и теперь у меня проблемы с конфигурацией. Я разбросал несколько вопросов по пути, так как их довольно много, но главная проблема в том, что узел и диван больше не разговаривают.

У меня работает nodejs, и я использую расширение node-spdy (https://www.npmjs.org/package/spdy)

У меня настроены сертификаты SSL:

var options = {
  key: fs.readFileSync(__dirname + '/keys/spdy-key.pem'),
  cert: fs.readFileSync(__dirname + '/keys/spdy-cert.pem'),
  ca: fs.readFileSync(__dirname + '/keys/spdy-ca.pem'),
};

Первый вопрос: теперь у меня есть промежуточный сертификат, как мне сообщить об этом nodejs? Раньше мой сертификат был самоподписанным, поэтому я поместил файл csr в место ca (выше), и он работал. На самом деле, пробуя это сегодня, и файл csr, и промежуточный сертификат, похоже, работают в этом месте, но это не может быть правильным, поэтому мой вопрос. Итак, если это csr, то как мне правильно настроить промежуточный сертификат? Я видел эту ветку: https://stackoverflow.com/questions/19104215/node-js-express-js-chain-certificate-not-working

Затем couchdb работал с SSL, когда у меня был самоподписанный сертификат. Чтобы узел и кушетка нормально играли через SSL, мне пришлось установить этот флаг в узле:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Этот остановил узел от выхода из-за ошибки «самоподписанного» сертификата. Теперь я хочу снять этот флаг. (Первоначально я получил этот совет отсюда: https://github.com/mikeal/request/issues/418)

Теперь к главному. В CouchDB мой local.ini имеет:

[httpd]
;port = 5984
;bind_address = 127.0.0.1
; Options for the MochiWeb HTTP server.
;server_options = [{backlog, 128}, {acceptor_pool_size, 16}]
; For more socket options, consult Erlang's module 'inet' man page.
;socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}]

; Uncomment next line to trigger basic-auth popup on unauthorized requests.
WWW-Authenticate = Basic realm="administrator"

; Uncomment next line to set the configuration modification whitelist. Only
; whitelisted values may be changed via the /_config URLs. To allow the admin
; to change this value over HTTP, remember to include {httpd,config_whitelist}
; itself. Excluding it from the list would require editing this file to update
; the whitelist.
;config_whitelist = [{httpd,config_whitelist}, {log,level}, {etc,etc}]

[httpd_global_handlers]
;_google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>}

[couch_httpd_auth]
; If you set this to true, you should also uncomment the WWW-Authenticate line
; above. If you don't configure a WWW-Authenticate header, CouchDB will send
; Basic realm="server" in order to prevent you getting logged out.
require_valid_user = true

[log]
;level = debug

[log_level_by_module]
; In this section you can specify any of the four log levels 'none', 'info',
; 'error' or 'debug' on a per-module basis. See src/*/*.erl for various
; modules.
;couch_httpd = error


[os_daemons]
; For any commands listed here, CouchDB will attempt to ensure that
; the process remains alive. Daemons should monitor their environment
; to know when to exit. This can most easily be accomplished by exiting
; when stdin is closed.
;foo = /path/to/command -with args

[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 = /srv/www/[appname]/keys/cert.pem
key_file = /srv/www/[appname]/keys/key.pem
;password = somepassword
; set to true to validate peer certificates
;verify_ssl_certificates = true

; Path to file containing PEM encoded CA certificates (trusted
; certificates used for verifying a peer certificate). May be omitted if
; you do not want to verify the peer.
; cacert_file = /srv/www/[appname]/keys/ca.pem
; The verification fun (optional) if not specified, the default
; verification fun will be used.
;verify_fun = {Module, VerifyFun}
; maximum peer certificate depth
ssl_certificate_max_depth = 1

Это правильно? Я последовал за (http://guide.couchdb.org/draft/security.html) и (http://wiki.apache.org/couchdb/How_to_enable_SSL)

Однако, когда я подключаюсь, я получаю это в журналах узлов:

error { [Error: read ECONNRESET] code: 'ECONNRESET', errno: 'ECONNRESET', syscall: 'read' }

Обычно это ошибка, когда другая сторона соединения завершается раньше на nodejs. Итак, couchDB закрывается. И когда я бегу curl -k -v https://127.0.0.1:6984/ чтобы проверить, что случилось, я получаю:

* About to connect() to 127.0.0.1 port 6984 (#0)
*   Trying 127.0.0.1...
* Adding handle: conn: 0x181eab0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x181eab0) send_pipe: 1, recv_pipe: 0
* Connected to 127.0.0.1 (127.0.0.1) port 6984 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to 127.0.0.1:6984 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to 127.0.0.1:6984

Все это произошло после новых файлов SSL. Я слышал, что CouchDB не нравятся некоторые конфигурации SSL? (Посмотреть здесь: https://leap.se/code/issues/883#note-10)

Кажется, что выводить странную ошибку, если это просто разрешения, но никогда нельзя быть слишком уверенным. Итак, для файлов pem - у меня есть права доступа 700 для папки / keys и 600 для файлов pem. Пользователь является развернутым пользователем, и кушетка работает на кушетке. Итак, диван не может получить к ним доступ, верно? Это проблема? Если это решение, то как лучше всего добавить пользователя couchdb в группу развертывания? Это исправление? Я всегда стараюсь быть уверенным вдвойне, имея дело с разрешениями.

Кроме того, как бы я ни старался, мне не удавалось получить кушетку для проверки сертификата SSL, поэтому я оставил эту конфигурацию отключенной. Это проблема? Я слышал, что диван требует, чтобы у сертификатов был пароль для работы этого параметра. Это правда? (http://thinkinginsoftware.blogspot.ca/2012/12/couchdb-unknown-ssl-protocol-error-in.html) Мне вообще нужен этот конфиг, чтобы он был включен?

Наконец, отдельно, в файле couch.uri он имеет как http, так и https URL. Итак, запускается 2 экземпляра. Могу ли я безопасно удалить URL-адрес http из запуска теперь, когда я использую SSL, или ему нужны оба?

Павел

Итак, вот ответы на тот случай, если кто-то столкнется с этим в своем собственном путешествии:

Когда вы настраиваете SSL в узле, особенно с SPDY, он запрашивает:

var options = {
  key: fs.readFileSync(__dirname + '/keys/spdy-key.pem'),
  cert: fs.readFileSync(__dirname + '/keys/spdy-cert.pem'),
  ca: fs.readFileSync(__dirname + '/keys/spdy-ca.pem'),
};

Кажется, что вы можете использовать csr (запрос на подпись сертификата) в качестве CA в настройке SSL для самозаверяющих сертификатов. Однако выполнение этого на производственном сервере означает, что в цепочке сертификатов возникли проблемы (сертификат, который вы купили, например RapidSSL, привязан к сертификату более низкого уровня, например GeoTrust. Цепочка должна пройти весь обратный путь, поскольку GeoTrust является один, которому доверяет браузер.) Если вы не создадите файл ca (промежуточный файл сертификата), в большинстве случаев это нормально - он скажет, что цепочка разорвана в https://www.ssllabs.com/ssltest но браузеры, похоже, не заботились. Но правильный способ - поставить промежуточный сертификат на место.

Что касается узла и дивана, проблема определенно заключалась в разрешениях. Я добавил пользователя couchdb в группу пользователей развертывания, но поскольку разрешения на файлы ключей равны 600, у группы все еще нет доступа. В моем случае я просто создал самоподписанный сертификат специально для couchDB.

Это означает, что я должен сказать узлу доверять ему, используя этот флаг конфигурации:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Итак, теперь кушетка и узел общаются и используют SSL.

Что касается некоторых других вопросов:

Базовое использование openssl, похоже, отлично работает с couchdb, поэтому никаких проблем с определенными типами сертификатов или чем-либо подобным, с которыми я сталкивался

Кажется, я не могу включить проверку сертификата для дивана в этой настройке. Я просто получаю SSL: hello: tls_handshake.erl:285:Fatal error: internal error Так что оставив этот набор на ложные работы

Похоже, вы можете безопасно удалить http-сервер из файла couchdb couch.uri (находится на /var/run/couchdb/couch.uri) и просто используйте https.

Надеюсь, это кому-то поможет,

Павел

couchdb и ssl безнадежно (по крайней мере, на данный момент). Кажется, это ошибка в основном erlang библиотека. Два дня мне не повезло. Теперь я пытаюсь использовать nginx как прокси ...