Configuração adequada para o Couchdb + SSL Ubuntu. Obtendo o erro: curl: (35) Erro de protocolo SSL desconhecido em conexão com 127.0.0.1:6984

Question

Eu estou olhando para usar o CouchDB com SSL e nodejs e acabei de mudar de certificados auto-assinados (que estavam trabalhando há mais de um mês) para um certificado SSL real e agora estou correndo em problemas de configuração. Eu espalhei algumas perguntas ao longo do caminho, pois há algumas peças, mas a questão principal é que o nó e o sofá não falam mais.

Eu tenho nodejs em execução e estou usando a extensão node-spdy ( link )

Eu tenho certificados SSL configurados:

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'),
};

Primeira pergunta: agora tenho um certificado intermediário, como digo ao nodejs isso? Anteriormente, meu certificado era autoassinado, portanto, coloquei o arquivo csr no local ca (acima) e isso estava funcionando. Na verdade, hoje, tanto o arquivo csr quanto o certificado intermediário parecem funcionar nesse ponto, mas isso não pode estar certo, daí a minha pergunta. Então, se é o CSR, então como configurar corretamente o certificado intermediário? Eu vi este tópico: link

Em seguida, couchdb estava trabalhando com o SSL quando eu tinha o certificado autoassinado. A fim de obter o nó e o sofá para jogar legal sobre SSL eu tive que definir este sinalizador no nó:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Este nó parou de sair no erro do certificado "auto-assinado". Agora quero remover essa bandeira. (Originalmente recebi essa dica aqui: link )

Agora, para a questão principal. No CouchDB, meu local.ini possui:

[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

Esta configuração está correta? Eu segui ( link ) e ( link )

No entanto, quando me conecto, recebo isso nos logs do nó:

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

Isso geralmente é um erro quando o outro lado da conexão termina no início do nodejs. Então o couchDB está saindo. E quando eu corro curl -k -v https://127.0.0.1:6984/ para verificar o que está acontecendo, recebo:

* 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

Isso tudo aconteceu depois dos novos arquivos SSL. Ouvi dizer que o CouchDB não gosta de algumas configurações de SSL? (Veja aqui: link )

Parece um erro estranho para a saída se forem apenas permissões, mas você nunca pode ter certeza disso. Portanto, para os arquivos pem, tenho as permissões definidas para 700 na pasta / keys e 600 nos arquivos pem. O usuário é um usuário de implantação e o sofá é executado no usuário do sofá. Então sofá não pode realmente acessar estes, correto? Esse é o problema? Se for a solução, o melhor curso de ação para adicionar o usuário couchdb ao grupo de implantação? Essa é a correção? Eu sempre gosto de ter certeza disso ao lidar com permissões.

Separadamente, não importa o que eu tente, parece que não consigo encontrar um sofá para verificar o certificado SSL, por isso deixei essa configuração desativada. Isso é um problema? Ouvi dizer que o sofá exige que os certificados tenham uma senha para essa configuração funcionar. Isso é verdade? ( link ) Eu preciso mesmo que essa configuração esteja ativada? ?

Por último e separadamente, no arquivo couch.uri, ele tem os URLs http e https. Então está começando 2 instâncias. Posso remover com segurança o URL http de iniciar agora que estou usando SSL ou ele precisa de ambos?

Paul

    

Answer 1

Então, aqui estão as respostas caso alguém encontre isso em sua própria jornada:

Quando você está configurando o SSL no nó, especialmente com o SPDY, ele pede:

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'),
};

Parece que você pode usar o csr (solicitação de assinatura de certificado) como o ca na configuração SSL para certificados auto-assinados. No entanto, fazer isso em um servidor de produção significa que a cadeia de certificados tem problemas (o certificado que você comprou, como o RapidSSL, é vinculado a um certificado de nível inferior, como GeoTrust. A cadeia precisa percorrer todo o caminho desde que GeoTrust é o um confiável pelo navegador.) Se você não fizer o arquivo ca (arquivo de certificado intermediário), tudo bem na maioria dos casos - ele dirá que a cadeia está quebrada em link mas os navegadores não parecem se importar. Mas a maneira correta é colocar o certificado intermediário no local ca.

Quanto ao nó e ao sofá, o problema definitivamente era permissões. Eu adicionei o usuário couchdb ao grupo de usuários de implantação, mas como as permissões nos arquivos de chaves são 600, o grupo ainda não tem acesso. No meu caso, acabei de criar um certificado auto-assinado especialmente para o couchDB.

Isso significa que eu tenho que dizer ao nó para confiar nele usando este sinalizador de configuração:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";

Então, agora couch e node falam e usam SSL.

Quanto a algumas das outras perguntas:

O uso básico do openssl parece funcionar bem com o couchdb, portanto, não há problemas com determinados tipos de certificado ou com algo parecido que eu tenha encontrado

Não consigo ativar a verificação de certificados para sofá nesta configuração. Eu acabei de chegar %código% Então, deixando esse conjunto para falsas obras

Parece que você pode remover com segurança o servidor http do arquivo couch.uri do couchdb (encontrado em SSL: hello: tls_handshake.erl:285:Fatal error: internal error ) e ter apenas o https.

Espero que isso ajude alguém,

Paul

    

Answer 2

couchdb e ssl são impossíveis (pelo menos por enquanto). Parece ser um bug na biblioteca subjacente erlang . Passei dois dias sem sorte. Agora eu tento usar nginx como proxy ...