I installed CouchDB on an Ubuntu server on EC2 on AWS.
Then, I got an SSL cert with Let's Encrypt.
I edited the local.ini file to enabled SSL and point to the cert files.
I opened port 6984 on the EC2 instance.
I restarted CouchDB.
But, I still can't access it over SSL : (
Any help would rock!
Here's my curl
$ curl https://example.com:6984 -v
* Trying ip.add.re.ss...
* TCP_NODELAY set
* Connected to example.com (ip.add.re.ss) port 6984 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /path/to/certs/ca-certificates.crt
CApath: /path/to/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:6984
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:6984
Some help would rock.
Related
I read the lot of blogs about the issue but none of the workaround /solutions worked for me.
I am using the curl command like below
curl -v https://golang.org/dl/?mode=json
* Trying 142.250.80.113:443...
* Connected to golang.org (142.250.80.113) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
* Closing connection 0
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
I changed the setting in gitbash (windows) to use openssl using the below command
git config --global http.sslBackend "openssl"
I am getting the below error after changing openssl
$ curl -v https://golang.org/dl/?mode=json
* Trying 172.253.62.141:443...
* Connected to golang.org (172.253.62.141) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
* CApath: C:\Users\AL25229
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
I have the CA cert/pem file which my organization provides. I am getting all those error messages when I connect with VPN. Connecting VPN is mandatory. By disabling the VPN, it works fine.
I had a running gitlab on an online server with ssl for several years now. Due to a server problem, the provider restarted the machine. Since then, I cannot connect to my gitlab anymore. Does anybody have an idea, how to solve the problem?
Thanks.
root#git:~# curl -v -H -GET "https://gitlabAdress.com"
Rebuilt URL to: https://gitlabAdress.com/
Trying xxx.xxx.xxx.xxx...
TCP_NODELAY set
Connected to gitlabAdress.com (xxx.xxx.xxx.xxx) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs
TLSv1.3 (OUT), TLS handshake, Client hello (1):
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlabAdress.com:443
stopped the pause stream!
Closing connection 0 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlabAdress.com:443
I have been given the following files for setting up TLS for a website running on the domain example.com:
example.com.key (containing the private key)
example.com.cer (containing one certificate)
intermediate_example.com.crt (containing two certificates)
example.com.csr (containing one certificate request)
I'm using Traefik to host the site, and I've configured Traefik like so in the dynamic.yml config:
tls:
certificates:
- certFile: "certs/example.com.cer"
keyFile: "certs/example.com.key"
stores:
- default
Doing so resulted in a website I could access via Chrome and Firefox, but whenever trying a request with curl (or any program using its libraries), I get the following error:
➜ ~ curl -v https://test.example.com/
* Trying xxx.xxx.xxx.xxx:443...
* Connected to test.example.com (xxx.xxx.xxx.xxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
Why is this working in browsers, but not via curl?
I have ensured that the ca-certificates package is installed on the host, and even when I download the most recent CA bundle and use curl --cacert cacert.pem …, it does not work.
What am I missing here?
The reason it does not work is that the intermediate certificate is missing in what Traefik is sending to the client.
The browsers can work around this using the Authority Information Access mechanism, and even macOS does this, fetching the missing information out-of-band, thereby allowing you to access the site normally. Some background is given here.
This is obviously a configuration error on the server. To fix it, at least for Traefik, you can concatenate everything into one .pem file. You don't need to add the CSR file here:
cat example.com.key example.com.cer intermediate_example.com.crt > cert.pem
Then, specify the same file twice in Traefik's config:
tls:
certificates:
- certFile: "certs/cert.pem"
keyFile: "certs/cert.pem"
stores:
- default
This is also mentioned in this discussion on the Traefik community board.
Is there a command to check the TLS version required by a host site? Right now, the only way I know to check is by adjusting the max TLS version of my browser and checking if I can still access the site. However, I suspect there is a more sophisticated way to do this.
You can check using following commands.
For TLS 1.2:
openssl s_client -connect www.google.com:443 -tls1_2
For TLS 1.1:
openssl s_client -connect www.google.com:443 -tls1_1
For TLS 1:
openssl s_client -connect www.google.com:443 -tls1
If you get the certificate chain and the handshake then the TLS version is supported. If you don't see the certificate chain, and something similar to "handshake error" then its not.
From https://maxchadwick.xyz/blog/checking-ssl-tls-version-support-of-remote-host-from-command-line:
nmap ssl-enum-ciphers
Another option for checking SSL / TLS version support is nmap. nmap is not typically installed by default, so you’ll need to manually install it. Once installed you can use the following command to check SSL / TLS version support…
nmap --script ssl-enum-ciphers -p 443 www.google.com
nmap’s ssl-enum-ciphers script will not only check SSL / TLS version support for all versions (TLS 1.0, TLS 1.1, and TLS 1.2) in one go, but will also check cipher support for each version including giving providing a grade.
I like to use curl which can report a TLS version negotiation quite nicely.
For example, this tries to connect with TLS 1.1, which the server negotiates to upgrade to 1.2:
$ curl -Iiv --tlsv1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
[...]
To forbid that the server upgrades the TLS version use the --tls-max option:
$ curl -Iiv --tlsv1.1 --tls-max 1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, internal error (592):
* error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
* Closing connection 0
curl: (35) error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
In this case, the connection fails because the client does not offer any TLS version above 1.1, but the server does not accept any version below 1.2. If used like this, the output is very similar to the openssl_client output.
It seems the most sophisticated way is to check like this for each version:
openssl s_client -connect : -
Nmap has very convenient TLS version and ciphersuite checking NSE script. All in one, multiplatform too: https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
I have a website I am using to host redmine and several git repositories
This works perfectly for http, but I can't clone with https, i.e.
git clone http://mysite.com/git/test.git
works fine, but
git clone https://mysite.com/git/test.git
fails
The strange thing is that https seems to work for everything else I have tested. If I open
https://mysite.com/git/test.git
in a browser (tested in chrome and firefox), I get no errors or warnings. I can also
curl https://mysite.com/git/test.git
wget https://mysite.com/git/test.git
both of which work with no complaints or warnings.
Here is the verbose output from git:
$ GIT_CURL_VERBOSE=1 git clone https://user#mysite.com/test/test.git
Cloning into test...
Password:
* Couldn't find host mysite.com in the .netrc file; using defaults
* About to connect() to mysite.com port 443 (#0)
* Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0)
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection #0
* Couldn't find host mysite.com in the .netrc file; using defaults
* About to connect() to mysite.com port 443 (#0)
* Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0)
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection #0
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://user\
#mysite.com/test/test.git/info/refs
fatal: HTTP request failed
Here is the verbose output from curl, with the personal info changed:
* About to connect() to mysite.com port 443 (#0)
* Trying 127.0.0.1... connected
* Connected to mysite.com (127.0.0.1) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: C=US; <... cut my certs info ...>
* start date: 2011-10-18 00:00:00 GMT
* expire date: 2013-10-17 23:59:59 GMT
* subjectAltName: mysite.com matched
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO High-Assurance Secure Server CA
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
> Host: mysite.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 18 Oct 2011 21:39:54 GMT
< Server: Apache/2.2.14 (Ubuntu)
< Last-Modified: Fri, 14 Oct 2011 03:20:01 GMT
< ETag: "8209c-87-4af39bb89ccac"
< Accept-Ranges: bytes
< Content-Length: 135
< Vary: Accept-Encoding
< Content-Type: text/html
< X-Pad: avoid browser bug
<
<p>Welcome to the mysite.com<p/>
* Connection #0 to host mysite.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
The only difference I can see is that git seems to be using an explicit CAfile while curl uses the whole directory? I'm new to ssl (at least on the admin side), so I'm not sure what this means or how I could configure git to work the same way as curl.
I am using git 1.7.5.4 and apache 2.2.14 on Ubuntu 10.04. I've tried cloning from 3 different linux hosts (including another account on the server itself), and nothing works.
I've also used the openssl tool to verify my cert on the server:
$openssl verify -purpose sslserver -CAfile chain.crt signed.pem
signed.pem: OK
This may be related to the bug https://bugs.maemo.org/show_bug.cgi?id=4953 but it seems different because I am not getting any warning or errors in any other program.
It may be worth mentioning that I am using gitolite and redmine_git_hosting using smart http to do authentication over https. I don't think any of this is at fault though, because the problem exists even if I just stick an otherwise working bare repo in /var/www and access it directly. Also, git over ssh (with and without gitolite) works.
Please let me know if you have any idea what might be wrong or if you'd like some more info. I'd really prefer to get ssl working properly, as opposed to forcing everyone to disable certificate checking in git, although that is a current workaround.
Thanks for reading this long post!
It turns out that this was a gnuTLS issue. gnuTLS is order sensitive, while openssl is not. I re-ordered the certificates in my intermediate cert file and the problem went away
XCondE's answer will address the problem, but turning off security warnings always feels like a bad idea. If you're running on an ubuntu box, then the issue may be that the CA certificate for your web server isn't in the /etc/ssl/certs/ca-certificates.crt file. I ran into this with a git server hosted on a web server with a SSL certificate signed by www.incommon.org.
You can add the intermediate certificate to your ca-certificates file, as follows:
wget http://cert.incommon.org/InCommonServerCA.crt
openssl x509 -inform DER -in InCommonServerCA.crt -out incommon.pem
cat /etc/ssl/certs/ca-certificates.crt incommon.pem > ca-certs2.crt
sudo cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak
sudo cp ca-certs2.crt /etc/ssl/certs/ca-certificates.crt
There's a good discussion of what's going on behind the scenes here:
http://curl.haxx.se/docs/sslcerts.html
I encountered this error with one of my Comodo PositiveSSL certificates and was able to fix it by changing the order of the intermediate certificates.
After ordering the certificate, I was provided with the following files:
Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
PositiveSSL Wildcard Certificate - STAR_mydomain_com.crt
Originally, the order of certificates in the .crt I was providing to Nginx was as follows:
PositiveSSL Wildcard Certificate - STAR_mydomain_com.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
However, I reversed the order of the last two certificates and Git no longer throws verification errors.
git uses gnutls for this stuff, which requires the CA be specified. This can be done with per-respository with:
git config http.sslcapath <path to CA directory>
OR
git config http.sslcainfo <path to CA cert>
You can also specify --system or --global.
The problem may be that you didn't configure correctly Apache
You may have to add your server name to the Apache configuration file
/etc/apache2/sites-enabled/default-ssl.conf, e.g.:
ServerName demo.personalserver.com
From: https://www.progclub.org/blog/2014/09/03/gnutls_handshake-failed-using-git/#comment-96924
export GIT_SSL_NO_VERIFY=1
From http://blog.breadncup.com/2011/06/09/skip-git-ssl-verification/
WARNING: as some people mentioned, this disables verification, leaving you open to a sleuth of security issues. You shouldn't rely on it long-term but, in a pinch, it will get the job done.