You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Julian Bee (JIRA)" <ji...@apache.org> on 2012/05/26 17:59:23 UTC
[jira] [Commented] (COUCHDB-1448) Client Certificate Validation
Nonfunctional
[ https://issues.apache.org/jira/browse/COUCHDB-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284004#comment-13284004 ]
Julian Bee commented on COUCHDB-1448:
-------------------------------------
I came accross the same problem (CouchDB 1.2.0, OpenSSL 1.0.1c 10 May 2012).
When running an OpenSSL test server with my certificates (see below), I am correctly asked for
a client certificate.
{code}
$ openssl s_server -key couch_key.pem -cert couch_cert.pem -www -verify 1 -CAfile root_ca_cert.pem
verify depth is 1
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
47433269592680:error:140780E5:SSL routines:SSL23_READ:ssl handshake failure:s23_lib.c:131:
ACCEPT
47433269592680:error:140780E5:SSL routines:SSL23_READ:ssl handshake failure:s23_lib.c:131:
ACCEPT
depth=1 C = DE, ST = <left out>
verify return:1
depth=0 C = DE, ST = <left out>
verify return:1
ACCEPT
{code}
In the browser, I get the following result:
{code}
Ciphers supported in s_server binary
TLSv1/SSLv3:ECDHE-RSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDHE-ECDSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDHE-RSA-AES256-SHA384 TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA384
TLSv1/SSLv3:ECDHE-RSA-AES256-SHA TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA
TLSv1/SSLv3:SRP-DSS-AES-256-CBC-SHA TLSv1/SSLv3:SRP-RSA-AES-256-CBC-SHA
TLSv1/SSLv3:DHE-DSS-AES256-GCM-SHA384TLSv1/SSLv3:DHE-RSA-AES256-GCM-SHA384
TLSv1/SSLv3:DHE-RSA-AES256-SHA256 TLSv1/SSLv3:DHE-DSS-AES256-SHA256
TLSv1/SSLv3:DHE-RSA-AES256-SHA TLSv1/SSLv3:DHE-DSS-AES256-SHA
TLSv1/SSLv3:DHE-RSA-CAMELLIA256-SHA TLSv1/SSLv3:DHE-DSS-CAMELLIA256-SHA
TLSv1/SSLv3:ECDH-RSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDH-ECDSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDH-RSA-AES256-SHA384 TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA384
TLSv1/SSLv3:ECDH-RSA-AES256-SHA TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA
TLSv1/SSLv3:AES256-GCM-SHA384 TLSv1/SSLv3:AES256-SHA256
TLSv1/SSLv3:AES256-SHA TLSv1/SSLv3:CAMELLIA256-SHA
TLSv1/SSLv3:PSK-AES256-CBC-SHA TLSv1/SSLv3:ECDHE-RSA-DES-CBC3-SHA
TLSv1/SSLv3:ECDHE-ECDSA-DES-CBC3-SHA TLSv1/SSLv3:SRP-DSS-3DES-EDE-CBC-SHA
TLSv1/SSLv3:SRP-RSA-3DES-EDE-CBC-SHA TLSv1/SSLv3:EDH-RSA-DES-CBC3-SHA
TLSv1/SSLv3:EDH-DSS-DES-CBC3-SHA TLSv1/SSLv3:ECDH-RSA-DES-CBC3-SHA
TLSv1/SSLv3:ECDH-ECDSA-DES-CBC3-SHA TLSv1/SSLv3:DES-CBC3-SHA
TLSv1/SSLv3:PSK-3DES-EDE-CBC-SHA TLSv1/SSLv3:ECDHE-RSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDHE-ECDSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDHE-RSA-AES128-SHA256
TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA256TLSv1/SSLv3:ECDHE-RSA-AES128-SHA
TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA TLSv1/SSLv3:SRP-DSS-AES-128-CBC-SHA
TLSv1/SSLv3:SRP-RSA-AES-128-CBC-SHA TLSv1/SSLv3:DHE-DSS-AES128-GCM-SHA256
TLSv1/SSLv3:DHE-RSA-AES128-GCM-SHA256TLSv1/SSLv3:DHE-RSA-AES128-SHA256
TLSv1/SSLv3:DHE-DSS-AES128-SHA256 TLSv1/SSLv3:DHE-RSA-AES128-SHA
TLSv1/SSLv3:DHE-DSS-AES128-SHA TLSv1/SSLv3:DHE-RSA-SEED-SHA
TLSv1/SSLv3:DHE-DSS-SEED-SHA TLSv1/SSLv3:DHE-RSA-CAMELLIA128-SHA
TLSv1/SSLv3:DHE-DSS-CAMELLIA128-SHA TLSv1/SSLv3:ECDH-RSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDH-ECDSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDH-RSA-AES128-SHA256
TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA256 TLSv1/SSLv3:ECDH-RSA-AES128-SHA
TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA TLSv1/SSLv3:AES128-GCM-SHA256
TLSv1/SSLv3:AES128-SHA256 TLSv1/SSLv3:AES128-SHA
TLSv1/SSLv3:SEED-SHA TLSv1/SSLv3:CAMELLIA128-SHA
TLSv1/SSLv3:IDEA-CBC-SHA TLSv1/SSLv3:PSK-AES128-CBC-SHA
TLSv1/SSLv3:ECDHE-RSA-RC4-SHA TLSv1/SSLv3:ECDHE-ECDSA-RC4-SHA
TLSv1/SSLv3:ECDH-RSA-RC4-SHA TLSv1/SSLv3:ECDH-ECDSA-RC4-SHA
TLSv1/SSLv3:RC4-SHA TLSv1/SSLv3:RC4-MD5
TLSv1/SSLv3:PSK-RC4-SHA TLSv1/SSLv3:EDH-RSA-DES-CBC-SHA
TLSv1/SSLv3:EDH-DSS-DES-CBC-SHA TLSv1/SSLv3:DES-CBC-SHA
TLSv1/SSLv3:EXP-EDH-RSA-DES-CBC-SHA TLSv1/SSLv3:EXP-EDH-DSS-DES-CBC-SHA
TLSv1/SSLv3:EXP-DES-CBC-SHA TLSv1/SSLv3:EXP-RC2-CBC-MD5
TLSv1/SSLv3:EXP-RC4-MD5
---
Ciphers common between both SSL end points:
AES128-SHA AES256-SHA RC4-SHA
DES-CBC3-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA DHE-DSS-AES128-SHA
DHE-DSS-AES256-SHA EDH-DSS-DES-CBC3-SHA RC4-MD5
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID:
Session-ID-ctx: 01000000
Master-Key: 2F...E2
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1338046378
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
0 items in the session cache
0 client connects (SSL_connect())
0 client renegotiates (SSL_connect())
0 client connects that finished
3 server accepts (SSL_accept())
0 server renegotiates (SSL_accept())
1 server accepts that finished
0 session cache hits
0 session cache misses
0 session cache timeouts
0 callback cache hits
0 cache full overflows (128 allowed)
---
Client certificate
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1004...510 (0x8...23ce)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=DE, ST=...
Validity
Not Before: May 25 06:55:02 2012 GMT
Not After : May 24 06:55:02 2017 GMT
Subject: C=DE, ST=...
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b1:68:1e:77:6e:bf:db:ef:62:61:22:6c:45:fa:
...
67:db
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
0f:49:39:06:6b:d4:09:82:f8:82:81:08:cc:46:71:5f:30:7a:
...
8a:78:c3:02:3c:75:da:ec
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
{code}
> Client Certificate Validation Nonfunctional
> -------------------------------------------
>
> Key: COUCHDB-1448
> URL: https://issues.apache.org/jira/browse/COUCHDB-1448
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Affects Versions: 1.2
> Environment: OSX 10.7/Ubuntu 11.10, Erlang R15B/R14B4
> Reporter: Brendan O'Connor
> Labels: certificate, client, ssl
>
> CouchDB commit: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 (from build-couchdb) on both platforms (OSX / R14B4, and Ubuntu / R15B).
> Attempting to use client SSL certificate validation. In local.ini, if I specify cert_file and key_file, *server* SSL certificate functionality works as expected. If I also specify a cacert_file and set verify_ssl_certificates = true, I get the following crash:
> ============
> [info] [<0.31.0>] Apache CouchDB has started on https://127.0.0.1:6984/
> [error] [<0.165.0>] SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
> =ERROR REPORT==== 23-Mar-2012::17:12:03 ===
> SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
> [error] [<0.164.0>] SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
> =ERROR REPORT==== 23-Mar-2012::17:12:03 ===
> SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
> [error] [<0.166.0>] SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
> =ERROR REPORT==== 23-Mar-2012::17:12:03 ===
> SSL: hello: ssl_handshake.erl:249:Fatal error: internal error
> [error] [<0.145.0>] {error_report,<0.30.0>,
> {<0.145.0>,std_error,
> [{application,mochiweb},
> "Accept failed error",
> "{error,\"internal error\"}"]}}
> =ERROR REPORT==== 23-Mar-2012::17:12:03 ===
> application: mochiweb
> "Accept failed error"
> "{error,\"internal error\"}"
> [error] [<0.144.0>] {error_report,<0.30.0>,
> {<0.144.0>,std_error,
> [{application,mochiweb},
> "Accept failed error",
> "{error,\"internal error\"}"]}}
> =ERROR REPORT==== 23-Mar-2012::17:12:03 ===
> application: mochiweb
> "Accept failed error"
> "{error,\"internal error\"}"
> [error] [<0.145.0>] {error_report,<0.30.0>,
> {<0.145.0>,crash_report,
> [[{initial_call,
> {mochiweb_acceptor,init,
> ['Argument__1','Argument__2','Argument__3']}},
> {pid,<0.145.0>},
> {registered_name,[]},
> {error_info,
> {exit,
> {error,accept_failed},
> [{mochiweb_acceptor,init,3,
> [{file,
> "/Users/ussjoin/Desktop/build-couchdb/dependencies/couchdb/src/mochiweb/mochiweb_acceptor.erl"},
> {line,33}]},
> {proc_lib,init_p_do_apply,3,
> [{file,"proc_lib.erl"},{line,227}]}]}},
> {ancestors,
> [https,couch_secondary_services,couch_server_sup,
> <0.31.0>]},
> {messages,[]},
> {links,[<0.142.0>]},
> {dictionary,[]},
> {trap_exit,false},
> {status,running},
> {heap_size,2584},
> {stack_size,24},
> {reductions,912}],
> []]}}
> =CRASH REPORT==== 23-Mar-2012::17:12:03 ===
> crasher:
> initial call: mochiweb_acceptor:init/3
> pid: <0.145.0>
> registered_name: []
> exception exit: {error,accept_failed}
> in function mochiweb_acceptor:init/3 (/Users/ussjoin/Desktop/build-couchdb/dependencies/couchdb/src/mochiweb/mochiweb_acceptor.erl, line 33)
> ancestors: [https,couch_secondary_services,couch_server_sup,<0.31.0>]
> messages: []
> links: [<0.142.0>]
> dictionary: []
> trap_exit: false
> status: running
> heap_size: 2584
> stack_size: 24
> reductions: 912
> neighbours:
> [error] [<0.142.0>] {error_report,<0.30.0>,
> {<0.142.0>,std_error,
> {mochiweb_socket_server,310,
> {acceptor_error,{error,accept_failed}}}}}
> ============
> From the browser side, the browser was never even asked by CouchDB to submit a client certificate; it crashes before it gets to that point.
> Similar result when specifying ssl_trusted_certificates_file and verify_ssl_certificates=true in the replicator section of default.ini; a crash and nothing happens on replication attempts.
> Tried increasing ssl_certificate_max_depth to 2 and 3 on both the local.ini[ssl] side and the default.ini[replicator] side, with no apparent effect.
> Workaround:
> In replicator, specify cert_file and key_file, but leave verify_ssl_certificates = false. Use nginx to verify the client certificates (and serve server SSL if you wish). Replication proceeds with client+server SSL as expected, without having to use a proxy on the sending side. (The downside is that you have to use nginx-- if this feature worked as expected, the use case could be solved in CouchDB alone.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira