[GH-ISSUE #36] Gitea connection test failed – unable to verify the first certificate #20

Closed
opened 2026-02-27 15:54:35 +03:00 by kerem · 9 comments
Owner

Originally created by @mariovata on GitHub (Jul 6, 2025).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/36

When attempting to connect to my self-hosted Gitea instance, the application throws the following error:

Gitea connection test failed: 1 | class HttpError extends Error {
2 |   constructor(message, status, statusText, response) {
3 |     super(message);
        ^
HttpError: Network error: unable to verify the first certificate
     status: 0,
 statusText: "Network Error",
   response: undefined,

      at new HttpError (/app/dist/server/chunks/http-client_CVSk-VJJ.mjs:3:5)
      at httpRequest (/app/dist/server/chunks/http-client_CVSk-VJJ.mjs:72:11)

This occurs even though The Gitea instance is properly accessible and other applications trust my local CA and connect without issue (like Firefox, chrome, curl) . The server certificate chain is valid and signed by my own trusted local CA.

Steps to Reproduce

  1. Configure the application to connect to a self-hosted Gitea server behind a reverse proxy (https://git.home.arpa).

  2. Run the connection test.

  3. Observe that it fails with unable to verify the first certificate.

Expected Behavior

The application should trust my local CA certificates like other applications do and connect successfully to Gitea.

Environment

  • Gitea: 1.22.4 built with GNU Make 4.4.1, go1.22.9 : bindata, timetzdata, sqlite, sqlite_unlock_notify
  • gitea-mirror: v2.18.0
  • OS: Linux 6.15.4-arch2-1
Originally created by @mariovata on GitHub (Jul 6, 2025). Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/36 When attempting to connect to my self-hosted Gitea instance, the application throws the following error: ``` Gitea connection test failed: 1 | class HttpError extends Error { 2 | constructor(message, status, statusText, response) { 3 | super(message); ^ HttpError: Network error: unable to verify the first certificate status: 0, statusText: "Network Error", response: undefined, at new HttpError (/app/dist/server/chunks/http-client_CVSk-VJJ.mjs:3:5) at httpRequest (/app/dist/server/chunks/http-client_CVSk-VJJ.mjs:72:11) ``` This occurs even though The Gitea instance is properly accessible and other applications trust my local CA and connect without issue (like Firefox, chrome, curl) . The server certificate chain is valid and signed by my own trusted local CA. ## Steps to Reproduce 1. Configure the application to connect to a self-hosted Gitea server behind a reverse proxy (https://git.home.arpa). 2. Run the connection test. 3. Observe that it fails with unable to verify the first certificate. ## Expected Behavior The application should trust my local CA certificates like other applications do and connect successfully to Gitea. ## Environment - Gitea: 1.22.4 built with GNU Make 4.4.1, go1.22.9 : bindata, timetzdata, sqlite, sqlite_unlock_notify - gitea-mirror: v2.18.0 - OS: Linux 6.15.4-arch2-1
kerem closed this issue 2026-02-27 15:54:35 +03:00
Author
Owner

@mariovata commented on GitHub (Jul 6, 2025):

I was able to get around this by appending this to the environment inside of the docker-compose.yml:
- NODE_TLS_REJECT_UNAUTHORIZED=0
But, I don't think this is a good solution.

<!-- gh-comment-id:3042441336 --> @mariovata commented on GitHub (Jul 6, 2025): I was able to get around this by appending this to the environment inside of the `docker-compose.yml`: `- NODE_TLS_REJECT_UNAUTHORIZED=0` But, I don't think this is a good solution.
Author
Owner

@arunavo4 commented on GitHub (Jul 6, 2025):

@mariovata you can use the NODE_EXTRA_CA_CERTS environment variable to specify your local CA certificate:

NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem bun run start

Or set it in your .env file:
NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem

<!-- gh-comment-id:3042452437 --> @arunavo4 commented on GitHub (Jul 6, 2025): @mariovata you can use the NODE_EXTRA_CA_CERTS environment variable to specify your local CA certificate: NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem bun run start Or set it in your .env file: NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem
Author
Owner

@arunavo4 commented on GitHub (Jul 6, 2025):

Looks like we cannot set it as env variable https://github.com/nodejs/node/issues/51426

<!-- gh-comment-id:3042480410 --> @arunavo4 commented on GitHub (Jul 6, 2025): Looks like we cannot set it as env variable https://github.com/nodejs/node/issues/51426
Author
Owner

@arunavo4 commented on GitHub (Jul 6, 2025):

@mariovata Try this.
Instead of disabling certificate validation, mount your local CA certificate into the container:

  1. Create a directory for your CA certificates:

    mkdir ca-certificates
    
  2. Copy your local CA certificate (since curl works, you can find it in your system):

    # Find your CA certificate - common locations:
    ls /etc/ssl/certs/ | grep -i local
    # or
    ls /usr/local/share/ca-certificates/
    
    # Copy it to your local directory
    cp /path/to/your-ca.crt ca-certificates/
    
  3. Update your docker-compose.yml:

    services:
      gitea-mirror:
        volumes:
          - gitea-mirror-data:/app/data
          - ./ca-certificates/your-ca.crt:/usr/local/share/ca-certificates/your-ca.crt:ro
    
  4. Restart the container:

    docker compose restart
    

This way, the container will trust your local CA without compromising security. The :ro flag mounts it as read-only for extra safety.

For your specific case with https://git.home.arpa, this should resolve the "unable to verify the first certificate" error while maintaining proper SSL/TLS validation.

<!-- gh-comment-id:3042494903 --> @arunavo4 commented on GitHub (Jul 6, 2025): @mariovata Try this. Instead of disabling certificate validation, mount your local CA certificate into the container: 1. Create a directory for your CA certificates: ```bash mkdir ca-certificates ``` 2. Copy your local CA certificate (since curl works, you can find it in your system): ```bash # Find your CA certificate - common locations: ls /etc/ssl/certs/ | grep -i local # or ls /usr/local/share/ca-certificates/ # Copy it to your local directory cp /path/to/your-ca.crt ca-certificates/ ``` 3. Update your `docker-compose.yml`: ```yaml services: gitea-mirror: volumes: - gitea-mirror-data:/app/data - ./ca-certificates/your-ca.crt:/usr/local/share/ca-certificates/your-ca.crt:ro ``` 4. Restart the container: ```bash docker compose restart ``` This way, the container will trust your local CA without compromising security. The `:ro` flag mounts it as read-only for extra safety. For your specific case with `https://git.home.arpa`, this should resolve the "unable to verify the first certificate" error while maintaining proper SSL/TLS validation.
Author
Owner

@mariovata commented on GitHub (Jul 6, 2025):

@mariovata you can use the NODE_EXTRA_CA_CERTS environment variable to specify your local CA certificate:

NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem bun run start

Or set it in your .env file: NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem

I have tried setting this but it failed for some reason with:

gitea-mirror | warn: ignoring extra certs from /etc/ssl/certs/MyLocalRootCA.pem, load failed: error:10000002:SSL routines:OPENSSL_internal:system library

@mariovata Try this. Instead of disabling certificate validation, mount your local CA certificate into the container:

1. Create a directory for your CA certificates:
   mkdir ca-certificates

2. Copy your local CA certificate (since curl works, you can find it in your system):
   # Find your CA certificate - common locations:
   ls /etc/ssl/certs/ | grep -i local
   # or
   ls /usr/local/share/ca-certificates/
   
   # Copy it to your local directory
   cp /path/to/your-ca.crt ca-certificates/

3. Update your `docker-compose.yml`:
   services:
     gitea-mirror:
       volumes:
         - gitea-mirror-data:/app/data
         - ./ca-certificates/your-ca.crt:/usr/local/share/ca-certificates/your-ca.crt:ro

4. Restart the container:
   docker compose restart

This way, the container will trust your local CA without compromising security. The :ro flag mounts it as read-only for extra safety.

For your specific case with https://git.home.arpa, this should resolve the "unable to verify the first certificate" error while maintaining proper SSL/TLS validation.

This also didn't seem to work, the cert is there but I am not sure why it is not being used:

Image

I have also tried setting the env to a local one (- NODE_EXTRA_CA_CERTS=./ca-certificates/MyLocalRootCA.pem) just in case but still the same error:
gitea-mirror | warn: ignoring extra certs from ./ca-certificates/MyLocalRootCA.pem

<!-- gh-comment-id:3042549103 --> @mariovata commented on GitHub (Jul 6, 2025): > [@mariovata](https://github.com/mariovata) you can use the NODE_EXTRA_CA_CERTS environment variable to specify your local CA certificate: > > NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem bun run start > > Or set it in your .env file: NODE_EXTRA_CA_CERTS=/path/to/your/ca-certificate.pem I have tried setting this but it failed for some reason with: `gitea-mirror | warn: ignoring extra certs from /etc/ssl/certs/MyLocalRootCA.pem, load failed: error:10000002:SSL routines:OPENSSL_internal:system library` > [@mariovata](https://github.com/mariovata) Try this. Instead of disabling certificate validation, mount your local CA certificate into the container: > > 1. Create a directory for your CA certificates: > mkdir ca-certificates > > 2. Copy your local CA certificate (since curl works, you can find it in your system): > # Find your CA certificate - common locations: > ls /etc/ssl/certs/ | grep -i local > # or > ls /usr/local/share/ca-certificates/ > > # Copy it to your local directory > cp /path/to/your-ca.crt ca-certificates/ > > 3. Update your `docker-compose.yml`: > services: > gitea-mirror: > volumes: > - gitea-mirror-data:/app/data > - ./ca-certificates/your-ca.crt:/usr/local/share/ca-certificates/your-ca.crt:ro > > 4. Restart the container: > docker compose restart > > > This way, the container will trust your local CA without compromising security. The `:ro` flag mounts it as read-only for extra safety. > > For your specific case with `https://git.home.arpa`, this should resolve the "unable to verify the first certificate" error while maintaining proper SSL/TLS validation. This also didn't seem to work, the cert is there but I am not sure why it is not being used: <img width="642" height="45" alt="Image" src="https://github.com/user-attachments/assets/943c9f65-70a6-428e-bc43-aefab694f799" /> I have also tried setting the env to a local one (` - NODE_EXTRA_CA_CERTS=./ca-certificates/MyLocalRootCA.pem `) just in case but still the same error: `gitea-mirror | warn: ignoring extra certs from ./ca-certificates/MyLocalRootCA.pem`
Author
Owner

@arunavo4 commented on GitHub (Jul 7, 2025):

@mariovata can you build the dockerfile from this branch ca-cert-issue and give it a try https://github.com/RayLabsHQ/gitea-mirror/pull/37

The updated solution:

  1. Modifies the Docker entrypoint to automatically detect and install mounted CA certificates
  2. Ensures the Dockerfile includes the necessary ca-certificates package
  3. Properly sets NODE_EXTRA_CA_CERTS to the system's certificate bundle after installation
<!-- gh-comment-id:3043296310 --> @arunavo4 commented on GitHub (Jul 7, 2025): @mariovata can you build the dockerfile from this branch `ca-cert-issue` and give it a try https://github.com/RayLabsHQ/gitea-mirror/pull/37 The updated solution: 1. Modifies the Docker entrypoint to automatically detect and install mounted CA certificates 2. Ensures the Dockerfile includes the necessary ca-certificates package 3. Properly sets NODE_EXTRA_CA_CERTS to the system's certificate bundle after installation
Author
Owner

@mariovata commented on GitHub (Jul 7, 2025):

Awesome! I rebuilt the container and I have set the

# Option 2: Mount system CA bundle (if your CA is already in system store)
- /etc/ssl/certs/MyLocalRootCA.pem:/etc/ssl/certs/ca-certificates.crt:ro
Image

So the second option works for me and I can now connect to my Gitea securely 🎉!


I have also noticed that the first option throws an error and keeps restarting the container:

# Mount CA certificates for self-signed Gitea instances
# Option 1: Mount specific CA certificate
- ./ca-certificates/MyLocalRootCA.pem:/usr/local/share/ca-certificates/your-ca.crt:ro
Image

For me the second option solves my issue.

<!-- gh-comment-id:3043875751 --> @mariovata commented on GitHub (Jul 7, 2025): Awesome! I rebuilt the container and I have set the ``` # Option 2: Mount system CA bundle (if your CA is already in system store) - /etc/ssl/certs/MyLocalRootCA.pem:/etc/ssl/certs/ca-certificates.crt:ro ``` <img width="568" height="49" alt="Image" src="https://github.com/user-attachments/assets/da763773-7e2f-49da-8a5a-5274713795cc" /> So the second option works for me and I can now connect to my Gitea securely 🎉! --- I have also noticed that the first option throws an error and keeps restarting the container: ``` # Mount CA certificates for self-signed Gitea instances # Option 1: Mount specific CA certificate - ./ca-certificates/MyLocalRootCA.pem:/usr/local/share/ca-certificates/your-ca.crt:ro ``` <img width="899" height="156" alt="Image" src="https://github.com/user-attachments/assets/efa8132b-c232-4d1f-963e-7260ab6a93b6" /> For me the second option solves my issue.
Author
Owner

@arunavo4 commented on GitHub (Jul 7, 2025):

Thanks for the update @mariovata I will update my readme with this info.

<!-- gh-comment-id:3044014971 --> @arunavo4 commented on GitHub (Jul 7, 2025): Thanks for the update @mariovata I will update my readme with this info.
Author
Owner

@arunavo4 commented on GitHub (Jul 7, 2025):

@mariovata consider testing out the latest release v2.21.0

<!-- gh-comment-id:3044529672 --> @arunavo4 commented on GitHub (Jul 7, 2025): @mariovata consider testing out the latest release `v2.21.0`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/gitea-mirror#20
No description provided.