# Cannot checkout a repository hosted on a gitea instance using self-signed certificate (\`server certificate verification failed\`)

**URL:** <https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903>\
**Category:** Actions\
**Created:** [September 27, 2023, 5:50pm UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903 "2023-09-27T17:50:12Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![nodiscc](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/nodiscc/32/4811_2.png) [@nodiscc](https://forum.gitea.com/u/nodiscc)\
**Post date:** [September 27, 2023, 5:50pm UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/1 "2023-09-27T17:50:12Z")

</div>

Hi,

I am trying to set up a self-hosted act-runner, and link it to a Gitea instance that uses self-signed TLS certificates (the implementation/ansible role to deploy it can be found [here](https://github.com/nodiscc/xsrv/compare/gitea-actions?expand=1#files_bucket)). I had no problem setting up act-runner and registering it on my Gitea instance, enabling actions for repositories, etc.

However, during `actions-checkout@v2`, gitea actions fails with `fatal: unable to access 'https://git.example.org/myusername/hecat-test/': server certificate verification failed. CAfile: none CRLfile: none`.

This is because it tries to clone a git repository from the Gitea instance, which does not have a valid certificate. This is a test/staging instance and it is **not** possible for me to get a valid certificate for it. I would like to keep using a self-signed certificate, and make `actions-checkout@v2` play nice with it.

Searching for `self-signed` on [Issues · actions/checkout · GitHub](https://github.com/actions/checkout/issues) yields no results, which make me think github’s checkout action simply does not support this. Moreover it doesn’t appear that maintainers are looking at the project issues at all, so it is pointless to post there (issues are littered with spambot-generated content which are never cleaned up).

Are there ways to accomplish this? Is there an alternative checkout action that I could use? Or is there a way to configure the action trust a custom CA/certificate?

Thanks in advance

---

<div class="post-metadata">

**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:** [September 28, 2023, 2:50am UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/2 "2023-09-28T02:50:52Z")

</div>

Looks like there is no parameter to ignore the certificate verify.  
ref: [https://github.com/actions/checkout/blob/main/action.yml](https://github.com/actions/checkout/blob/main/action.yml)

---

<div class="post-metadata">

**Author:** ![nodiscc](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/nodiscc/32/4811_2.png) [@nodiscc](https://forum.gitea.com/u/nodiscc)\
**Post date:** [October 3, 2023, 11:19am UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/3 "2023-10-03T11:19:20Z")

</div>

Hi,  
I was able to make act-runner/`checkout` action accept the self-signed certificate by:

1. adding my self-signed certificate to the host’s CA certificates bundle, by copying it to `/etc/ssl/certs/` and running `update-ca-certificates`
2. making a copy of the host’s CA certificate bundle (`/etc/ssl/certs/ca-certificates.crt`) for act-runner in `/etc/act-runner/ca-certificates.crt`
3. mounting this copy of the the bundle inside containers managed by act-runner by passing `options: --mount type=bind,source=/etc/act-runner/ca-certificates.crt,target=/etc/ssl/certs/ca-certificates.crt,readonly` and `valid_volumes: ['/etc/act-runner/ca-certificates.crt']` in `/etc/act-runner/config.yaml`
4. have the `checkout` action load this certificate bundle by passing `envs: NODE_EXTRA_CA_CERTS: "/etc/ssl/certs/ca-certificates.crt"` in `/etc/act-runner/config.yaml`

You can find the full ansible role here: [https://github.com/nodiscc/xsrv/tree/master/roles/gitea\_act\_runner](https://github.com/nodiscc/xsrv/tree/master/roles/gitea_act_runner)

Also worth noting that my default setup uses podman instead of docker to manage containers, and seems to work correctly with it. I will probably contribute some documentation on how to achieve this.

---

<div class="post-metadata">

**Author:** ![haydonryan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/haydonryan/32/6337_2.png) [@haydonryan](https://forum.gitea.com/u/haydonryan)\
**Post date:** [October 21, 2024, 7:20pm UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/4 "2024-10-21T19:20:57Z")

</div>

I’m also having the same problems with ca certs, and have just burnt 4 hours trying to get the F thing working.

I run my own Root CA + Intermediate for homelab purposes. Gitea is behind traefik providing the HTTPS endpoint.

On my synology NAS, using a gitea action runner works perfectly - the CA certs pass through to all of the containers.

Running Ubuntu on a different machine, and i can curl the endpoint no problems on the host (cert is in the trust store) but the containers all fail on the git clone step.

I also have insecure: true in my config.yaml

This appears to be a sore spot for sure.

> [@Git actions runner SSL issue](https://forum.gitea.com/t/git-actions-runner-ssl-issue/8115):
>
> When using a git runner (worked prior), I updated the SSL cert that nginx uses to secure gitea and all of a sudden my git action stopped working. My runner is build in a docker container and when calling actions/checkout@v3, I get the below error: Unable to access fatal: unable to access ‘[https://gitea.spacia.com/Spacia/Flyer](https://gitea.spacia.com/Spacia/Flyer)’: server certificate verification failed. CAfile: none CRLfile: none This is only since updating the companies wildcard cert. I also place the cert in /usr/local/share/c…

---

<div class="post-metadata">

**Author:** ![nodiscc](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/nodiscc/32/4811_2.png) [@nodiscc](https://forum.gitea.com/u/nodiscc)\
**Post date:** [October 22, 2024, 10:45am UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/5 "2024-10-22T10:45:00Z")

</div>

@haydonryan check the solution above, there are two things at play:

- the host running act-runner must trust the certificate so it can register/communicate with the gitea instance (seems to work fine for you)
- the containers launched by act-runner, in which the `git clone` process take place, must trust the certificate - these containers have no knowledge of the host’s trust store - so you must have
  - `NODE_EXTRA_CA_CERTS: "/etc/ssl/certs/ca-certificates.crt"` in `/etc/act-runner/config.yaml`
  - `valid_volumes: ['/etc/act-runner/ca-certificates.crt']` and `options: --mount type=bind,source=/etc/act-runner/ca-certificates.crt,target=/etc/ssl/certs/ca-certificates.crt,readonly` in `/etc/act-runner/config.yaml`

Does this work for you?

---

<div class="post-metadata">

**Author:** ![haydonryan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/haydonryan/32/6337_2.png) [@haydonryan](https://forum.gitea.com/u/haydonryan)\
**Post date:** [October 22, 2024, 2:59pm UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/6 "2024-10-22T14:59:29Z")

</div>

I did get it in eventually once I found the options section of config.yaml. I definitely think this is something that could be added to the config.yaml template.

Thanks!

---

<div class="post-metadata">

**Author:** ![haydonryan](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/haydonryan/32/6337_2.png) [@haydonryan](https://forum.gitea.com/u/haydonryan)\
**Post date:** [October 26, 2024, 10:39pm UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/7 "2024-10-26T22:39:52Z")

</div>

I moved from an ubuntu docker host to arch linux based… My vms all trust my internal CA.

I think the way I’m doing this is different to your suggestion - in that I’m just passing through the host directories, rather than having extra certs in etc/act-runner.  
I have it working by:

1. Added the options line in config.yml:

```auto
options: "--volume /etc/ssl/certs:/etc/ssl/certs:ro --volume /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro"

```

1. Passed the cert directories in as volumes too to the main container (docker-compose.yml):

```auto
        - /etc/ssl/certs:/etc/ssl/certs:ro
        - /etc/ca-certificates:/etc/ca-certificates:ro

```

I can confirm I did not need the NODE\_EXTRA\_CA\_CERTS field in config.yml or the following in docker-compose.yml :

```auto
- /etc/ssl/certs/ca-certificates.crt:/etc/act-runner/ca-certificates.crt:ro

```

---

<div class="post-metadata">

**Author:** ![maekro26](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/maekro26/32/6443_2.png) [@maekro26](https://forum.gitea.com/u/maekro26)\
**Post date:** [November 20, 2024, 6:51am UTC](https://forum.gitea.com/t/cannot-checkout-a-repository-hosted-on-a-gitea-instance-using-self-signed-certificate-server-certificate-verification-failed/7903/8 "2024-11-20T06:51:14Z")

</div>

I have a successful attempt following your guide. Confirm it works on Ubuntu docker host.  
In my case, i have to add `valid_volumes` options (`GITEA_RUNNER_VALID_VOLUME_N` in env variable) to mount custom volumes onto jobs container.  
Thank you for the pointers!!!
