The following patch is basically what I added for desktopcouch.
The issue that desktopcouch had was that, the replicator, when sending the request for a remote's _changes/, it blocked after receiving the response headers. Issuing the exact same request (including OAuth tokens, etc) with curl just worked.
Found that the reason was that we need to pass the option
to ibrowse as well as ssl socket options to specify if peer certification should be done, max certificate depth and client trusted certificates file (a file in PEM format).
Oddly enough this issue didn't arise when doing the initial requests to verify if the target DB exists and remote replication checkpoint (by coincidence none of those requests was generating a response with a body).
The following patch adds 3 new .ini config parameters to the replicator section:
; set to true to validate peer certificates
verify_ssl_certificates = false
; file containing a list of peer trusted certificates (PEM format)obert
; ssl_trusted_certificates_file = /etc/ssl/certs/ca-certificates.crt
; maximum peer certificate depth (must be set even if certificate validation is off)
ssl_certificate_max_depth = 3
I feel the section for these options is right. Nevertheless the last 2 might be useful as well outside the replicator's scope, that is, to validate client certificates.
Robert Newson added sometime ago SSL support to CouchDB's httpd, and created the .ini section [ssl]. Even if client verification is added, it might be useful to specify different settings from the ones used by the replicator, so maybe duplicating them in the [ssl] .ini section is a good idea.
I would like to have feedback on this, and definitily I think the issue should be fixed for 1.1.