Webhook x509: certificate signed by unknown authority #3467

New Issue

GiteaMirror · 2025-11-02T05:13:42-06:00

GiteaMirror commented

2025-11-02 05:13:42 -06:00

Originally created by @boukandouramhamed on GitHub (Jun 14, 2019).

Gitea version (or commit ref): 1.9.0+dev-311-gfb4438a81
Git version: 2.20.1
Operating system: Centos 7
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

Unable to add webhook for openshift origin pipeline (3.11).

Delivery: Post https://ip@:8443/apis/build.openshift.io/v1/namespaces/jenkins/buildconfigs/pipeline6/webhooks/somesecret/generic: x509: certificate signed by unknown authority

How can i use self signed webhooks in gitea ?

Screenshots

Originally created by @boukandouramhamed on GitHub (Jun 14, 2019).   - Gitea version (or commit ref): 1.9.0+dev-311-gfb4438a81 - Git version: 2.20.1 - Operating system: Centos 7 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description Unable to add webhook for openshift origin pipeline (3.11). > Delivery: Post https://ip@:8443/apis/build.openshift.io/v1/namespaces/jenkins/buildconfigs/pipeline6/webhooks/somesecret/generic: x509: certificate signed by unknown authority How can i use self signed webhooks in gitea ? ## Screenshots

GiteaMirror added the topic/webhooks issue/confirmed type/enhancement labels 2025-11-02 05:13:42 -06:00

GiteaMirror closed this issue

2025-11-02 05:13:42 -06:00

GiteaMirror commented

2025-11-02 05:13:43 -06:00

@stale[bot] commented on GitHub (Aug 13, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Aug 13, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:13:43 -06:00

@langemar commented on GitHub (Nov 18, 2019):

A similar issue was tracked by #2744 but the given solution is not suitable in an openshift/k8s environment. I'm seeking for a solution since a while in order to use openshift's oauth2/openID provider in gitea.

Grepping through the source code i even can't find where the trust-store might be initialised.

best regards

@langemar commented on GitHub (Nov 18, 2019): A similar issue was tracked by #2744 but the given solution is not suitable in an openshift/k8s environment. I'm seeking for a solution since a while in order to use openshift's oauth2/openID provider in gitea. Grepping through the source code i even can't find where the trust-store might be initialised. best regards

GiteaMirror commented

2025-11-02 05:13:43 -06:00

@lunny commented on GitHub (Nov 19, 2019):

We should add a config on [webhook] to allow self-signed webhooks.

@lunny commented on GitHub (Nov 19, 2019): We should add a config on `[webhook]` to allow self-signed webhooks.

GiteaMirror commented

2025-11-02 05:13:44 -06:00

@langemar commented on GitHub (Nov 19, 2019):

A more general option would be great to address not only webhooks.
As said I try to integrate gitea in openshift and want gitea to use the openID endpoint provided by openshift, which is accessible through tls endpoint secured by a cluster wide certificate.

The same is also true for every connection gitea make to external resources. This would include databases, indexers, auth providers (OpenID/OAuth2, LDAP and SMTP), webhooks (of coursce), Mailer, Cache (redis with TLS), Picture, log (at least smtp logs) and U2F.

Best regards

@langemar commented on GitHub (Nov 19, 2019): A more general option would be great to address not only webhooks. As said I try to integrate gitea in openshift and want gitea to use the openID endpoint provided by openshift, which is accessible through tls endpoint secured by a cluster wide certificate. The same is also true for every connection gitea make to external resources. This would include databases, indexers, auth providers (OpenID/OAuth2, LDAP and SMTP), webhooks (of coursce), Mailer, Cache (redis with TLS), Picture, log (at least smtp logs) and U2F. Best regards

GiteaMirror commented

2025-11-02 05:13:44 -06:00

@damobrisbane commented on GitHub (Apr 17, 2021):

My workaround for cert not being available (docker) was to create and tag a new image with cert copied in, ie:

`
cat Dockerfile

FROM gitea:v0.2
COPY MYLOCALCACERT.crt /etc/ssl/certs
...
docker build -t gitea:v0.2-custcert .
`

Though I havde no idea what might be best practice around properly addressing this.

@damobrisbane commented on GitHub (Apr 17, 2021): My workaround for cert not being available (docker) was to create and tag a new image with cert copied in, ie: ` cat Dockerfile FROM gitea:v0.2 COPY MYLOCALCACERT.crt /etc/ssl/certs ... docker build -t gitea:v0.2-custcert . ` Though I havde no idea what might be best practice around properly addressing this.

GiteaMirror commented

2025-11-02 05:13:44 -06:00

@langemar commented on GitHub (Apr 17, 2021):

Hi damobrisbane,

openshift provides an operator to maintaine service certificates, there rolled automatically. So it is unpractical to rebuild the container once the operator did his job (requires additional monitoring and manuel work to trigger builds).

These certificates are used for cluster internal communication only and it is advised not to use external verifieable certificate root, see for example this blog.
For the outer world ocp routes (ingest proxy) can do a reencrypt using a custom certificate at the edge.

A proper solution would be to have a config line or hardcoded path where certificates can be placed and included as trust anchor on container start. Even better would be if the application monitors a path/configmap for additional certificates, but a container restart normally happens often enough to be safe with a start up solution.

best regards

@langemar commented on GitHub (Apr 17, 2021): Hi damobrisbane, openshift provides an operator to maintaine service certificates, there rolled automatically. So it is unpractical to rebuild the container once the operator did his job (requires additional monitoring and manuel work to trigger builds). These certificates are used for cluster internal communication only and it is advised not to use external verifieable certificate root, see for example [this blog](https://www.openshift.com/blog/considerations-on-openshift-pkis-and-certificates). For the outer world ocp routes (ingest proxy) can do a reencrypt using a custom certificate at the edge. A proper solution would be to have a config line or hardcoded path where certificates can be placed and included as trust anchor on container start. Even better would be if the application monitors a path/configmap for additional certificates, but a container restart normally happens often enough to be safe with a start up solution. best regards

GiteaMirror commented

2025-11-02 05:13:44 -06:00

@lunny commented on GitHub (Apr 17, 2021):

Have you tried

[webhook]
; Allow insecure certification
SKIP_TLS_VERIFY = true

@lunny commented on GitHub (Apr 17, 2021): Have you tried ```ini [webhook] ; Allow insecure certification SKIP_TLS_VERIFY = true ```

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3467