I have installed CouchDB on Windows 7 x64.
I am trying to run CouchDB with SSL on port 6984.
I am prepared certificate like in documentation: secure-socket-level-options
And also checking: CouchDB Wiki
When I restart server, using:
curl http://127.0.0.1:5984/_restart -X POST
A log show, the port 6984 is listening:
[Tue, 25 Nov 2014 10:15:48 GMT] [debug] [<0.1208.0>] 'POST' /_restart {1,1} from "127.0.0.1"
Headers: [{'Accept',"*/*"},
{'Authorization',"Basic dG9tOnBhcw=="},
{'Content-Type',"application/json"},
{'Host',"127.0.0.1:5984"},
{'User-Agent',"curl/7.38.0"}]
[Tue, 25 Nov 2014 10:15:48 GMT] [debug] [<0.1208.0>] OAuth Params: []
[Tue, 25 Nov 2014 10:15:48 GMT] [info] [<0.1208.0>] 127.0.0.1 - - POST /_restart 202
[Tue, 25 Nov 2014 10:15:50 GMT] [info] [<0.1957.0>] Apache CouchDB has started on http://127.0.0.1:5984/
[Tue, 25 Nov 2014 10:15:50 GMT] [info] [<0.1957.0>] Apache CouchDB has started on https://127.0.0.1:6984/
I am modified local.ini, just like documentation says:
[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 = C:/Program\ Files\ (x86)/Apache\ Software\ Foundation/CouchDB/etc/Cert/localhost.crt
;key_file = C:/Program\ Files\ (x86)/Apache\ Software\ Foundation/CouchDB/etc/Cert/localhost.pem
cert_file = C:/Program\ Files\ (x86)/Apache\ Software\ Foundation/CouchDB/etc/couchdb/localhost.crt
key_file = C:/Program\ Files\ (x86)/Apache\ Software\ Foundation/CouchDB/etc/couchdb/localhost.pem
;cert_file = /etc/Cert/localhost.crt
;key_file = /etc/Cert/localhost.pem
;key_file = /etc/couchdb/localhost.pem
;cert_file = /etc/couchdb/couchdb.pem
port = 6984
;password = pass:a
; set to true to validate peer certificates
verify_ssl_certificates = false
; 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 = /full/path/to/cacertf
; 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
After restart service, I cannot connect to server on port 6984:
curl -k -v https://127.0.0.1:6984
* Rebuilt URL to: https://127.0.0.1:6984/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 6984 (#0)
* 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
Is something, what I have missed, I am not checked ? CouchDB is in version 1.6.1.
I have the same problem and same symptoms but one thing is certain the path to your certificates is way off.
You need to use the actual 'Windows' path to the certificates and if there are spaces ( i.e. c:\Program Files(x86)\Apa..... ) use single quotes around the whole path. It should be ok to replace the '\' with a '/' in the path.
For those that are wondering.. as of 2018, CouchDB 2.1.1 runs fine on Windows 10 with HTTPS enabled.
I generated my Certificate using another site that I setup on Ubuntu using Let's encrypt's certbot (https://certbot.eff.org/lets-encrypt/ubuntuxenial-other) and then copied them over to my windows machine. I get a warning that the certificate is not valid, but that's fine as Windows is just for development.
[ssl]
cert_file = c:/couchdb/cert/cert1.pem
key_file = c:/couchdb/cert/privkey1.pem
cacert_file = c:/couchdb/cert/fullchain1.pem
Related
I have a ruby on rails webapp sending requests to a third party SOAP API. When I request like:
endpoint = "https://www.booking-manager.com/cbm_web_service2/services/CBM?wsdl"
client = Savon.client(wsdl: endpoint,
#log_level: :info,
log_level: :debug,
log: true,
pretty_print_xml: true,
open_timeout: 300,
read_timeout: 300)
message = {'in0' => xxx,
'in1' => 'xxxx',
'in2' => 'xxx'}
response = client.call(:get_bases, message: message)
I´m getting next error:
HTTPI::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate has expired)):
The webapp is running under:
Mac OSX Big Sur 11.6.1
ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-darwin20]
I have this issue for weeks and I don´t know what else to do. According to many posts, I tested
openssl s_client -showcerts -host valid-isrgrootx1.letsencrypt.org -port 443
and got:
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
0 s:/CN=origin.letsencrypt.org
i:/C=US/O=Let's Encrypt/CN=R3
so, according to this: https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/970
I manually updated the file /etc/ssl/cert.pem to remove the DST Root CA X3 certificate. After that, I think that I moved one step forward. When running:
openssl s_client -showcerts -host valid-isrgrootx1.letsencrypt.org -port 443
Now, I don´t get the error and I think looks good:
CONNECTED(00000005)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = origin.letsencrypt.org
verify return:1
---
Certificate chain
0 s:/CN=origin.letsencrypt.org
i:/C=US/O=Let's Encrypt/CN=R3
However, unfortunately the error in my ruby app still remains the same. According to this, I understand ruby is running an openssl that is not getting the information from this certs. I´m not skilled with this at all and don´t know if this makes sense.
I just read other posts and checking openssl version
I got LibreSSL 2.8.3
which openssl
/usr/bin/openssl
In my /usr/local/opt I see three openssl versions folders:
openssl
openssl#1.1
openssl#3
I updated my .zshrc file and now openssl version notifies
OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)
and ruby seems to be using:
ruby -ropenssl -e "puts OpenSSL::OPENSSL_VERSION"
OpenSSL 1.1.1l 24 Aug 2021
I´m aware that the ruby OpenSSL version is 1.1.1 and the system is running 3.0.1. I don´t know how to update ruby to run OpenSSL 3.0.1, although I´m not sure if this can be the root problem. I´m lost at this point.
UPDATE
I think I´m narrowing the issue down. My guess is that Ruby is using a version of openSSL, in this case 1.1.1, that is pointing to /Users/Rober/.rbenv/versions/3.0.3/openssl/ssl/certs bundler instead of pointing to /etc/ssl/cert.pem
irb
irb(main):001:0> require "openssl"
=> true
irb(main):002:0> puts OpenSSL::OPENSSL_VERSION
OpenSSL 1.1.1l 24 Aug 2021
=> nil
irb(main):003:0> puts "SSL_CERT_FILE: %s" % OpenSSL::X509::DEFAULT_CERT_FILE
irb(main):004:0> puts "SSL_CERT_DIR: %s" % OpenSSL::X509::DEFAULT_CERT_DIR
SSL_CERT_FILE: /Users/Rober/.rbenv/versions/3.0.3/openssl/ssl/cert.pem
SSL_CERT_DIR: /Users/Rober/.rbenv/versions/3.0.3/openssl/ssl/certs
This file /Users/Rober/.rbenv/versions/3.0.3/openssl/ssl/cert.pem , unfortunately when I check the content is in the format:
-----BEGIN CERTIFICATE-----
certificate chain
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
I mean, in this file /etc/ssl/cert.pem I could read some readable headers that helped identify the certificate to remove, but in this case the headers are not present, so it´s not possible.
I think that I probably just need to config ruby to run openssl to point to this file /etc/ssl/cert.pem. According to mamy posts, I just added export SSL_CERT_FILE="/etc/ssl/cert.pem" to my .zshrc file, but still getting
OpenSSL::X509::DEFAULT_CERT_FILE
SSL_CERT_FILE: /Users/Rober/.rbenv/versions/3.0.3/openssl/ssl/cert.pem
SOLUTION
Thanks to #JanGaraj that provided the right solution to this problem in my other production post: SSL_connect returned=1 errno=0 state=error: certificate verify failed in ruby and Ubuntu 14.04
Just to summarize, apart from the points depicted above, I just needed to update my web service request specifying my ca-certificates file, like: Savon.client(ssl_ca_cert_file: "/etc/ssl/certs/ca-certificates.crt ")
The solution to this question was provided in another post by #jangaraj
It looks like you are using Ubuntu 14 and Savon 2 client. Savon 2 client doc: https://www.savonrb.com/version2/globals.html
ssl_ca_cert_file
Sets the SSL ca cert file to use.
Savon.client(ssl_ca_cert_file: "lib/ca_cert.pem")
I would point ssl_ca_cert_file to /etc/ssl/certs/ca-certificates.crt explicitly.
We have a program called server.exe which starts a websocket server (ws, wss) on computer of client.
It`s main purpose accept connections from browser (127.0.0.1) and send some data to it. It uses openssl dlls (1.0.2.20).
Problem: After startup of Windows server.exe does not work. It does not accept secure connections.
Debug Log with errors:
10.12.2019_16:11:09:0861 <<< ID = 728, msg: SSL library error during handshake on fd = 728 error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
10.12.2019_16:11:09:0876 <<< ID = 592, msg: SSL library error during handshake on fd = 592 error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number
10.12.2019_16:11:09:0876 <<< ID = 776, msg: SSL library error during handshake on fd = 776 error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number
But!! If we just restart server.exe - everything begin to work fine!
if we launch server.exe with .bat file (5 sec dealy) - everything is working!
Why? How can we solve problem?
Fixed.
server.exe file cannot find path to the dll.
I am trying to access 6.x ES instance using High Level REST Client 6.7.2.
Access to this ES instance is provided to me via hostname (https://****.azureedge.net), username & password.
My Spring Boot application is getting data from the same ES without issues when it runs from my dev environment (IDE), but throws SSLHandshakeException as soon as I try run it from Docker container (from my development machine or K8s cluster in cloud).
Container is made with base image: FROM debian:stretch-slim & OpenJDK 11.0.2 with Spring Boot necessary modules.
I made some progress debugging with -Djavax.net.debug=all. It turns out that while running in docker image just few first steps of usual SSL handshaking happen:
Produced ClientHello handshake message
WRITE: TLS13 handshake, length = 2352
Raw write
Raw read (0000: 15 03 03 00 02 02 28 ......( )
READ: TLSv1.2 alert, length = 2
Received alert message (
"Alert": {
"level" : "fatal",
"description": "handshake_failure"
}
)
followed by SSLHandshakeException:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at org.elasticsearch.client.RestClient$SyncResponseListener.get(RestClient.java:938)
at org.elasticsearch.client.RestClient.performRequest(RestClient.java:227)
at org.elasticsearch.client.RestHighLevelClient.internalPerformRequest(RestHighLevelClient.java:1764)
at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:1749)
at org.elasticsearch.client.RestHighLevelClient.performRequestAndParseEntity(RestHighLevelClient.java:1708)
at org.elasticsearch.client.SecurityClient.getSslCertificates(SecurityClient.java:508)
....
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source)
at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source)
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Unknown Source)
at java.base/sun.security.ssl.TransportContext.dispatch(Unknown Source)
at java.base/sun.security.ssl.SSLTransport.decode(Unknown Source)
at java.base/sun.security.ssl.SSLEngineImpl.decode(Unknown Source)
at java.base/sun.security.ssl.SSLEngineImpl.readRecord(Unknown Source)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(Unknown Source)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(Unknown Source)
at java.base/javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:271)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:316)
at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:509)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:591)
When running from my local environment handshake looks uninterrupted:
Produced ClientHello handshake message
WRITE: TLS13 handshake, length = 460
Raw write
Raw read
READ: TLSv1.2 handshake, length = 155
Consuming ServerHello
ServerHello
Negotiated protocol version: TLSv1.3
Session initialized: Session(1560119025211|TLS_AES_256_GCM_SHA384)
WRITE: TLS13 change_cipher_spec, length = 1
Raw write
Raw read
READ: TLSv1.2 change_cipher_spec, length = 1
Consuming ChangeCipherSpec message
Raw read
READ: TLSv1.2 application_data, length = 27
...
Raw read
READ: TLSv1.2 application_data, length = 8469
Consuming server Certificate handshake message
... // here is the list of 3 certificates with "SHA256withRSA", "SHA256withRSA", "SHA1withRSA" signature algorithms
Found trusted certificate ⇢ SHA1withRSA
...
While running locally I noticed CN=Microsoft IT TLS CA 2, OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US, as well as CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE as issuers, maybe this is important, but I guess it is expected considering ES host address (Azure).
At the end I wanted to emphasise that I didn't need to do anything special to make this work in my macOS Java 11.0.2 development environment.
I already tried following, but that didn't change anything:
Changing base Docker image from "slim" to non slim version
Using OpenJDK 11.0.1 or 11.0.2
Added cert from host to TrustStore that JVM is using in a runtime. (I checked in Docker container that there is indeed one more cert, but considering when handshake failure happens I imagine this is irrelevant)
tried to enforce App with: "-Dcom.sun.net.ssl.enableECC=false", "-Djdk.tls.client.protocols=TLSv1.3", "-Dhttps.protocols=TLSv1.3", didn't help
Interesting: curl from Docker image with BasicAuth "talks" with same URL without issues (handshake completes) & small query returns results. I guess that curl and JVM are using different sources of trusted CAs inside the Docker, different algorithms for handshaking etc..
Thanks in advance for any help
TLDR: enforcing TLSv1.2 for client in the app made handshaking complete from inside the docker
After a lot of try/fail attempts I made it work. Following things didn't make any difference:
using non "slim" debian base image insead of "slim"
using OpenJDK 11.0.2 instead of 11.0.1
adding host's certificate to JVM TrustedStore while building docker image so it is available when container starts.
enforcing com.sun.net.ssl.enableECC=false
enforcing TLSv1.3 for https.protocols and/or jdk.tls.client.protocols
enforcing TLSv1.2 for https.protocols
What fixed handshake with host, was enforcing TLSv1.2 for client by using -Djdk.tls.client.protocols=TLSv1.2 in Dockerfile, so app runs with this flag inside container. This allowed SSL handshake to complete as it should work anyways. For some reason actual negotiation about protocol version didn't work without enforcing lower version of protocol for client. Logs from local vs docker environment doesn't show any difference but this helped in docker.
What helped me to find out was:
setting of javax.net.debug=ssl:handshake or even more detailed javax.net.debug=all so I could see details of handshake attempts
confirming that "at least someone" can establish outbound communication from inside the docker by using curl to send same request as app is trying, which worked because curl somehow figured out how to proceed handshaking with host.
pure luck
Thanks everyone for support & ideas
I've just downloaded wampserver with Apache/2.4.4 (Win64) OpenSSL/1.0.1g PHP/5.4.12. Not a standard download, the original openssl version was too old.
I'm trying to create a new soapclient, but when the wsdl is at an ssl url apache crashes with no error.
$wsdl = 'https://www.undisclosedlocation.com/wsdl/mywsdl.wsdl";
$sclient = new SoapClient($wsdl,array('trace'=>1));
no hits, no runs, no errors. All i get is:
The connection was reset
The connection to the server was reset while the page was loading.
on the browser. Even in my debugger i just "session prematurely finished"
The wsdl isn't available on a url without ssl, but if i copy it to a local location it works, but then all the namespaces are off.
I'm using a self-signed certificate and get one more error.
[Sun Apr 13 22:45:50.192400 2014] [ssl:warn] [pid 19:tid 76] AH01909: RSA certificate configured for mydomain:443 does NOT include an ID which matches the server name
It seems that the problem is with your certifcate. There are at leas two problems:
Self signed certificate, which is not trusted by your client
The certificate doesn't contain the DNS name of your website
Most of the systems will discard the connection when one of those errors occurs.
Try to add the following setting before:
$context = stream_con**strong text**text_create(array(
'ssl' => array(
'verify_peer' => false,
'allow_self_signed' => true
)
));
See the following Stackoverflow question: Disable certificate verification in PHP SoapClient
I just recently added the SSL Endpoint add-on to my "example" app, and
updated my SSL Cert and Private Key from DNSimple to Heroku (according to this article:
http://ryan.mcgeary.org/2011/09/16/how-to-add-a-dnsimple-ssl-certificate-to-heroku/
) thanks to this command:
$ heroku certs:add STAR_example_com-bundle.pem STAR_example_com-private.key --app example
Adding SSL endpoint to example... done
example now served by oita-4417.herokussl.com
Certificate details:
subject: /OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.example.com
start date: 2012-07-28 02:00:00 CEST
expire date: 2013-07-29 01:59:59 CEST
common name(s): *.example.com, example.com
issuer: /OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.example.com
SSL certificate is verified by a root authority.
But now, when I try to access to my app with https://example.com (and sub-domains such as https://foo.example.com), I have a
warning (inside a big red page, using Chrome)...
How could I fix this? Maybe I have to wait some hours? Thanks!