Project

General

Profile

Actions

Issue #1599

closed

No access to repo

Added by Alexandre Roumiantsev about 8 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Category:
Infrastructure (web, git)
Target version:
-
Start date:
01/09/2016
Due date:
% Done:

100%

Estimated time:
Resolution:
fixed
Device:
Grant:
Type of work:

Description

fatal: unable to connect to git.replicant.us:
git.replicant.us[0: 18.4.89.63]: errno=Connection refused

Actions #1

Updated by Kristoffer Sederlöf about 8 years ago

Hola Replicant Lamas!

Same same. A quick nmap tells us that git "is there" but it's in a "closed" state:

----
$ nmap git.replicant.us
...
Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-11 11:37 EET
Nmap scan report for git.replicant.us (18.4.89.63)
Host is up (0.16s latency).
...
PORT STATE SERVICE
9418/tcp closed git
...
----

Thanks for helping us be free! ;-D

Actions #2

Updated by Wolfgang Wiedmeyer about 8 years ago

You can clone over https:
repo init -u https://git.replicant.us/replicant/manifest.git -b replicant-4.2
and then the usual repo sync
See the updated wiki: ReplicantSourceCode
It's safer anyway because the git protocol provides no authentication mechanism.

Actions #3

Updated by Alexandre Roumiantsev about 8 years ago

No better with https:
ran@ubuntu:~/a$ repo init u https://git.replicant.us/replicant/manifest.git -b replicant-4.2
Get https://git.replicant.us/replicant/manifest.git
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 -
:--:-- --:--:-- --:--:-- 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
fatal: unable to access 'https://git.replicant.us/replicant/manifest.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
fatal: unable to access 'https://git.replicant.us/replicant/manifest.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
fatal: cannot obtain manifest https://git.replicant.us/replicant/manifest.git

Actions #4

Updated by Kristoffer Sederlöf about 8 years ago

Hola Wolfgang and Alexandre && Thanks for your fast replies!

I ran into the same problem as Alexandre...

Host "replicant.us" seem to be using "http://www.CAcert.org" as it's
CA provider, that's free and good BUT their cert is not trusted "out
of the box" which leads to this problem from what I can tell.

(So all users must manually add the CACert root CA or somehow add that
k "skip verification" switch to their call-chain which just happens
to removes the whole point of SSL ;
).

I had similar problems some time ago and after some different CA
endeavors I ended up using:

Their free and pretty open solution has worked nicely!

Having successfully setup the letsencrypt magic on site-x it should be
"trusted" on most systems out-of-the-box (Meaning, their root CA is
included on most systems == hence you should get the "trusted
lock-sign" without doing anything and this problem should go away).

I recommend trying it out. Oh yeah, this naturally only works if you
are the admin/root of this box and not FSF... ;-)

The only "downside" that I have thus far found about letsencrypt is
the short:ish expire amount, BUT that's fixed by simply re-running
their script which does all the "renew cert" work on your behalf...

You can't have everything (TM).

Greetings from a snowy southern Finland,
Kristoffer.

Actions #5

Updated by Kristoffer Sederlöf about 8 years ago

Hola Again!

FYI, I think I got things working via simply manually installing CAcert's ROOT and CLASS3 certs to my SSL setup.

That is, my command:

    $ repo sync -j 6

seems to work (well, I get normal git + curl output at least). But now I get this curl error:

    ...
    curl: (35) error:0200100D:system library:fopen:Permission denied
    ...

after each "Retrying clone after deleting...". Hopefully almost harmless (I seem to need to do "repo sync --force-sync" on some repos, oh well).

Anyways, here's my mini workaround. YMMV!

MANUAL CACERT SSL INSTALLATION (Debian/Ubuntu)

  • install cacert's (1) ROOT and (2) CLASS3 certs to SSL (to keep the
    repo chain happy etc...)

As root do:

(1) root-ca:


 # wget http://www.cacert.org/certs/root.crt
 # FILE=cacert-root.crt
 # cp root.crt $FILE 
 # chmod 0640 $FILE
 # cp $FILE /etc/ssl/certs/
 # cd /etc/ssl/certs/
 # openssl x509 -noout -fingerprint -in $FILE   # NOTE! compare SHA1 against http://www.cacert.org/index.php?id=3 SHA1 string....
 # openssl x509 -noout -hash -in $FILE          # upcoming file-hash...
 # ln -sf $FILE $(openssl x509 -hash -noout -in $FILE).0
 # ls -al|grep $FILE
 lrwxrwxrwx 1 root     root         15 Jan 12 12:31 99d0fa06.0 -> cacert-root.crt
 -rw-r----- 1 root     root       2569 Jan 12 12:29 cacert-root.crt
 # cat $FILE >> /etc/ssl/certs/ca-certificates.crt

(2) class3-ca:


 # wget http://www.cacert.org/certs/class3.crt
 # FILE=cacert-class3.crt
 # cp class3.crt $FILE
 # chmod 0640 $FILE
 # cp $FILE /etc/ssl/certs/
 # cd /etc/ssl/certs/
 # openssl x509 -noout -fingerprint -in $FILE  # NOTE! same as above, compare SHA1 str's!
 # openssl x509 -noout -hash -in $FILE
 # ln -sf $FILE $(openssl x509 -hash -noout -in $FILE).0
 # ls -al|grep $FILE
 lrwxrwxrwx 1 root     root         17 Jan 12 12:43 590d426f.0 -> cacert-class3.crt
 -rw-r----- 1 root     root       2610 Jan 12 12:42 cacert-class3.crt
 # cat $FILE >> /etc/ssl/certs/ca-certificates.crt

Mini Verification:

 # openssl s_client -connect replicant.us:443 -CApath /etc/ssl/certs/ 
 ...
     Verify return code: 0 (ok)
                         ^^^^^^

Lastly, run your repo command and cross your fingers...

Actions #6

Updated by Wolfgang Wiedmeyer about 8 years ago

If you're on Debian Jessie and have the backports repository enabled, it is nothing more than installing one package: https://packages.debian.org/jessie-backports/ca-cacert

Actions #7

Updated by Kristoffer Sederlöf about 8 years ago

Hola Wolfgang!

Gotcha. Some of this info might be good to place under the ReplicantSourceCode page.

Anyways, unless I'm missing something the main problem still stands, people need to do
extra work to get things working... (meaning, the https:// solution does not work out-
of-the-box).

Keep up your good work,
Kristoffer.

Actions #8

Updated by Wolfgang Wiedmeyer about 8 years ago

Gotcha. Some of this info might be good to place under the ReplicantSourceCode page.

Anyways, unless I'm missing something the main problem still stands, people need to do
extra work to get things working... (meaning, the https:// solution does not work out-
of-the-box).

Absolutely! And thanks for providing the general instructions! This will definitely help others.

I cannot say anything about letsencrypt because I did not yet have the time to try it out on my servers. The comparably short expiration time might be an issue. Let's see how Paul decides on this.

Actions #9

Updated by Kristoffer Sederlöf about 8 years ago

Hola Wolfgang!

Regarding Letsencrypt's short expiration time I don't see that as much
of a problem anymore.

Yes it's something "a bit extra" that you need to remember (compared
to commercial/other free CA's) BUT that's easily fixed by putting some
Action-Point to your calendar which says something like

  • Renew our Letsencrypt cert via running their script (see Your-ssl-renew-mini-HOWTO).

The work just takes a couple of minutes and your done.

I just re-verified that running their "get-me-a-SSL-cert" script
again will do the needful and push the expiration date forward in
time (+ 1 month?)

And remember, you don't need to wait 5 minutes before things go BOOM
to do this, you can do this anytime ;-)

My old/previous run of their script gave me this SSL expiration date:

    Expires date: 1.3.2016

and after just re-running their python-script like so:

    # ./letsencrypt-auto --apache --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview

and answering some ncurse-like (CLI) questions, the script pushed the
expires date forward to:

    Expires date: 14.4.2016

I can live with that (meaning, it's ok for my devel host usage).

It would be even nicer if their script would just shut up and work in
batch-mode (non-interactive). Then one could simple create a monthly
cronjob and be done with it.

Who knows, perhaps even that is possible in the future (or already
now? ;-) I'm to lazy to check ;-D

Kind regards,
Kristoffer.

Actions #10

Updated by Sandro Santilli about 8 years ago

A workaround, if you're ok with trusting the URL, is setting GIT_SSL_NO_VERIFY=1 in the environment, like:
GIT_SSL_NO_VERIFY=1 git clone https://git.replicant.us/replicant/sdk.git

Note that using http would not work as the server redirects to https anyway.

Actions #11

Updated by Paul Kocialkowski about 8 years ago

  • Category set to Infrastructure (web, git)
  • Assignee set to Paul Kocialkowski
  • Device added
  • Device deleted (Unknown)
Actions #12

Updated by Fil Lupin almost 8 years ago

I tkink some update on the pages linked into http://redmine.replicant.us/projects/replicant/wiki#Replicant-build should help users.

Actions #13

Updated by Fil Lupin almost 8 years ago

  1. NOTE! compare SHA1 against http://www.cacert.org/index.php?id=3 SHA1 string....

If I understand what you mean, it does not seem to match:

sudo sha1sum -t  $FILE
506fb5538523119fdeddb269bdaa355b1c12a58f  cacert-root.crt

and I did not find any string beginning with 506 on the page http://www.cacert.org/index.php?id=3

Could you detail the procedure for checking please?

Actions #14

Updated by Fil Lupin almost 8 years ago

Waiting for the a secured way to use git, here is a page to get CAcert certificate manually on debian: https://www.brightbox.com/blog/2014/03/04/add-cacert-ubuntu-debian/

Actions #15

Updated by Wolfgang Wiedmeyer about 7 years ago

  • % Done changed from 0 to 100
  • Resolution set to fixed

git.replicant.us is now using Let's Encrypt and the host is up, at least for now.
The different additional steps to add trust for CAcert aren't necessary anymore.

Actions #16

Updated by Wolfgang Wiedmeyer about 7 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF