mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-04-25 15:25:55 +03:00
[GH-ISSUE #36] Gitea connection test failed – unable to verify the first certificate #20
Labels
No labels
bug
documentation
enhancement
help wanted
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/gitea-mirror#20
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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
Configure the application to connect to a self-hosted Gitea server behind a reverse proxy (https://git.home.arpa).
Run the connection test.
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
@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=0But, I don't think this is a good solution.
@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
@arunavo4 commented on GitHub (Jul 6, 2025):
Looks like we cannot set it as env variable https://github.com/nodejs/node/issues/51426
@arunavo4 commented on GitHub (Jul 6, 2025):
@mariovata Try this.
Instead of disabling certificate validation, mount your local CA certificate into the container:
Create a directory for your CA certificates:
Copy your local CA certificate (since curl works, you can find it in your system):
Update your
docker-compose.yml:Restart the container:
This way, the container will trust your local CA without compromising security. The
:roflag 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.@mariovata commented on GitHub (Jul 6, 2025):
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 libraryThis also didn't seem to work, the cert is there but I am not sure why it is not being used:
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@arunavo4 commented on GitHub (Jul 7, 2025):
@mariovata can you build the dockerfile from this branch
ca-cert-issueand give it a try https://github.com/RayLabsHQ/gitea-mirror/pull/37The updated solution:
@mariovata commented on GitHub (Jul 7, 2025):
Awesome! I rebuilt the container and I have set the
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:
For me the second option solves my issue.
@arunavo4 commented on GitHub (Jul 7, 2025):
Thanks for the update @mariovata I will update my readme with this info.
@arunavo4 commented on GitHub (Jul 7, 2025):
@mariovata consider testing out the latest release
v2.21.0