# \[SOLVED\] Clone over https fails certificate verification **URL:** \ **Category:** Install/Maintain/Configure\ **Created:** [June 14, 2018, 12:01pm UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337 "2018-06-14T12:01:24Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![adrinux](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/adrinux/32/4741_2.png) [@adrinux](https://forum.gitea.com/u/adrinux)\ **Post date:** [June 14, 2018, 12:01pm UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337/1 "2018-06-14T12:01:24Z")
I have Gitea running nicely on my vps behind an nginx reverse proxy using https and letsencrypt certs. I have cloning via ssh working. I also have Gitea running on a home server and want to set up mirrors of the repos on the vps. I’d like that to work via https rather than http. I generated certs set up gitea.ini for https and got nice https clone uris generated in the ui. But trying to use them gives an error: ```auto git clone https://gitea.example.com:3000/myuser/myrepo.git Cloning into 'myrepo'... fatal: unable to access 'https://gitea.example.com:3000/myuser/myrepo.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none ``` This seems to be due to the self generated certs. One solution is to disable cert verification on the client, seems icky though. Another is to add the CA to the client so it accepts the key, would need done for each client machine… So I’m wondering if anyone has https cloning setup using certs from letsencrypt or wherever and how you went about it. ---
**Author:** ![adrinux](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/adrinux/32/4741_2.png) [@adrinux](https://forum.gitea.com/u/adrinux)\ **Post date:** [June 14, 2018, 1:58pm UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337/2 "2018-06-14T13:58:25Z")
Found a possible workaround, can now clone via https as git user on my home server - still an issue with gitea not being able to read the cert file though. More detail later. ---
**Author:** ![adrinux](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/adrinux/32/4741_2.png) [@adrinux](https://forum.gitea.com/u/adrinux)\ **Post date:** [June 14, 2018, 2:53pm UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337/3 "2018-06-14T14:53:40Z")
Success. Two steps required. First capture the CA cert from the remote gitea server to the git users account on the second gitea server, second tell git to use that CA cert when accessing the remote repos. Capture: ```auto ssh myhome.server sudo su git cd /home/git mkdir cacerts echo -n | openssl s_client -showcerts -connect gitea.example.com:3000 \ 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cacerts/cert.pem ``` Configure gitconfig: ```auto git config --global http."https://gitea.example.com:3000/".sslCAInfo /home/git/cacerts/cert.pem ``` I would need to run these commands on any other client I wanted to do checkouts via https - but checkout via ssh is easier so why bother 🙂 Two helpful posts that helped me figure this out: [Configure git to accept a self signed cert](https://stackoverflow.com/questions/9072376/configure-git-to-accept-a-particular-self-signed-server-certificate-for-a-partic) and [Adding a self signed cert](https://stackoverflow.com/questions/23807313/adding-self-signed-ssl-certificate-without-disabling-authority-signed-ones) ---
**Author:** ![anon74399538](https://avatars.discourse-cdn.com/v4/letter/a/c6cbf5/32.png) [@anon74399538](https://forum.gitea.com/u/anon74399538)\ **Post date:** [July 4, 2018, 9:06am UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337/4 "2018-07-04T09:06:42Z")
I’m an admirer of your Hugo work and see you’re working on self-hosting with a mirror to a Gitea VPS which is one step further than I thought to take my hosting. Could you indulge us a little in your choice of hardware and software stack for hosting on your home server? ---
**Author:** ![adrinux](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/adrinux/32/4741_2.png) [@adrinux](https://forum.gitea.com/u/adrinux)\ **Post date:** [July 4, 2018, 10:26am UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337/5 "2018-07-04T10:26:14Z")
I think you may have it back to front, I’m self-hosting on a cloud VPS and setting up mirrors on my home server. The home server is an old HP Microserver N40L I bought second hand and use for backups, media serving etc. I run Ubuntu server on both. But it’s not like Gitea has heavy hardware requirements. I really need to rebuild Hugo Web Starter so it’ll run on the VPS. Then I could push to git and have auto-build and deploy (via gitea, although standard git hooks would work too). ---
**Author:** ![anon74399538](https://avatars.discourse-cdn.com/v4/letter/a/c6cbf5/32.png) [@anon74399538](https://forum.gitea.com/u/anon74399538)\ **Post date:** [July 4, 2018, 10:49am UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337/6 "2018-07-04T10:49:06Z")
> [@adrinux](#): > > I really need to rebuild Hugo Web Starter so it’ll run on the VPS. Then I could push to git and have auto-build and deploy (via gitea, although standard git hooks would work too). Heads up bep plans to add Sass support in the next version of Hugo with the ability to shell out to PostCSS for autoprefixing (not yet set in stone). As such, it may indeed be time to update your excellent starter. If you can get it running on ARM under Docker I think the world would be a better place as a result. 🙂 [https://github.com/resin-io-library/base-images/tree/master/node/armhf](https://github.com/resin-io-library/base-images/tree/master/node/armhf) ---
**Author:** ![lunny](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/lunny/32/4701_2.png) [@lunny](https://forum.gitea.com/u/lunny)\ **Post date:** [February 8, 2026, 7:46pm UTC](https://forum.gitea.com/t/solved-clone-over-https-fails-certificate-verification/337/7 "2026-02-08T19:46:20Z")