LDAP with custom root CA #6567

New Issue

GiteaMirror · 2025-11-02T06:59:47-06:00

GiteaMirror commented

2025-11-02 06:59:47 -06:00

Originally created by @mddeff on GitHub (Dec 22, 2020).

Gitea version (or commit ref): 1.13.0 - Deployed using official helm chart to k3s cluster
Operating system: Docker image/Alpine v3.12
Database (use [x]):
- PostgreSQL
- MariaDB
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
Log:

2020/12/22 00:13:56 ...es/auth/ldap/ldap.go:241:SearchEntry() [E] LDAP Connect error, <LDAP.ADDR>:LDAP Result Code 200 "Network Error": x509: certificate signed by unknown authority

Description

Gitea doesn't provide a method for allowing admins to inject custom root CAs for LDAPS authentication. Most web applications that I've used which leverage LDAP allow for admins to paste in a root CA for doing ldap authentication.

Scope

If you can add your CA cert to the root trust store for the OS, then you're golden. For regular VM/bare metal installs, this is almost a non-issue. In most cases, those hosts would likely be joined to your domain (IPA or AD) and likely have the root CA cert for your domain already added.

For docker/kubernetes, this is a non-starter. You have to either:

Run the commands (below) manually in the container
- The volume where the updated trust store (/etc/ssl/certs/ca-certificates.crt) is ephemeral and subsequently not 'durable'
Do some witchcraft and volumeMount over the existing system cert store
- This means that the admin has to maintain the volume and rebuild the cert store every time the image gets updated. Unsustainable.
Rebuild the official gitea with your certs baked in
- Again, unsustainable. Barrier of entry too high just to get LDAPS.
Disable TLS verification in the authentication configuration (what I suspect most people are doing)
- Might as well disable TLS entirely

Workaround

Based off of the alpine linux image, one can update the root store like so:

# source: https://unix.stackexchange.com/questions/464484/install-self-signed-certificate-to-alpine-linux
curl http://ipa.server/ipa/config/ca.crt > /usr/local/share/ca-certificates/iparoot.ca
update-ca-certificates

But as mentioned above, (for docker/kube at least), this is very fragile.

This issue is not new as it's been alluded to in #6335 and #13396.

Thoughts?

Originally created by @mddeff on GitHub (Dec 22, 2020).   - Gitea version (or commit ref): 1.13.0 - Deployed using official helm chart to k3s cluster - Operating system: Docker image/Alpine v3.12  - Database (use `[x]`): - [ ] PostgreSQL - [x] MariaDB - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log: ``` 2020/12/22 00:13:56 ...es/auth/ldap/ldap.go:241:SearchEntry() [E] LDAP Connect error, <LDAP.ADDR>:LDAP Result Code 200 "Network Error": x509: certificate signed by unknown authority ```    ## Description Gitea doesn't provide a method for allowing admins to inject custom root CAs for LDAPS authentication. Most web applications that I've used which leverage LDAP allow for admins to paste in a root CA for doing ldap authentication. ## Scope If you can add your CA cert to the root trust store for the OS, then you're golden. For regular VM/bare metal installs, this is almost a non-issue. In most cases, those hosts would likely be joined to your domain (IPA or AD) and likely have the root CA cert for your domain already added. For docker/kubernetes, this is a non-starter. You have to either: - Run the commands (below) manually in the container - The volume where the updated trust store (`/etc/ssl/certs/ca-certificates.crt`) is ephemeral and subsequently not 'durable' - Do some witchcraft and `volumeMount` over the existing system cert store - This means that the admin has to maintain the volume and rebuild the cert store every time the image gets updated. Unsustainable. - Rebuild the official gitea with your certs baked in - Again, unsustainable. Barrier of entry too high just to get LDAPS. - Disable TLS verification in the authentication configuration (what I suspect most people are doing) - Might as well disable TLS entirely ## Workaround Based off of the alpine linux image, one can update the root store like so: ``` # source: https://unix.stackexchange.com/questions/464484/install-self-signed-certificate-to-alpine-linux curl http://ipa.server/ipa/config/ca.crt > /usr/local/share/ca-certificates/iparoot.ca update-ca-certificates ``` But as mentioned above, (for docker/kube at least), this is very fragile. This issue is not new as it's been alluded to in #6335 and #13396. Thoughts?

GiteaMirror added the type/proposal type/enhancement topic/authentication type/upstream issue/workaround labels 2025-11-02 06:59:47 -06:00

GiteaMirror commented

2025-11-02 06:59:48 -06:00

@mddeff commented on GitHub (Dec 22, 2020):

Looks like there are other that are having issues with the docker image not being able to affect the container CA trust store. (#2744)

Maybe the best solution is to have the docker container update the CA truststore on boot. This way all people have to do is mount a config map into /usr/local/share/ca-certificates and you're good to go. There are obvious security implications to this (auto-importing CA certificates), but I think that if somebody ca affect what your configMaps are, they can swap out the "image" spec and run amok anyways.

@mddeff commented on GitHub (Dec 22, 2020): Looks like there are other that are having issues with the docker image not being able to affect the container CA trust store. (#2744) Maybe the best solution is to have the docker container update the CA truststore on boot. This way all people have to do is mount a config map into `/usr/local/share/ca-certificates` and you're good to go. There are obvious security implications to this (auto-importing CA certificates), but I think that if somebody ca affect what your configMaps are, they can swap out the "image" spec and run amok anyways.

GiteaMirror commented

2025-11-02 06:59:48 -06:00

@delfuego commented on GitHub (Feb 10, 2021):

Count me as someone who has to disable TLS verification for my LDAPS server, since it's signed by an internal-CA chain. I certainly would advocate for some way to load additional certificates into the root trust store of a Dockerized Gitea image!

@delfuego commented on GitHub (Feb 10, 2021): Count me as someone who has to disable TLS verification for my LDAPS server, since it's signed by an internal-CA chain. I certainly would advocate for some way to load additional certificates into the root trust store of a Dockerized Gitea image!

GiteaMirror commented

2025-11-02 06:59:48 -06:00

@Dunky13 commented on GitHub (May 19, 2021):

Same here, but for oauth OIDC.

@Dunky13 commented on GitHub (May 19, 2021): Same here, but for oauth OIDC.

GiteaMirror commented

2025-11-02 06:59:49 -06:00

@mddeff commented on GitHub (May 19, 2021):

Thinking about this more, many apps allow for admin-provided CA certs specifically for LDAP authentication. I cant think of a single instance where my LDAP server (IPA or AD) has had it's certs in a chain that's distributed with OSes. Typically, this same chain needs to have a CA somewhere towards the top that the auth service can control for other signing reasons (krb, client certs, etc), Subsequently, the LDAP/Auth CA's cert won't be signed by anybody in the main trust stores (because they aren't going to sign CA Certs with it's own signing power).

Support for custom LDAP CAs

Hashicorp Vault
Rancher
gitlab

While adding support in gittea is inherently a larger lift, I think its the "better" solution (at least, the more common one). Barring that, the proposed solution of having the container bootstrap in certs would work too. I could go either way.

@mddeff commented on GitHub (May 19, 2021): Thinking about this more, many apps allow for admin-provided CA certs specifically for LDAP authentication. I cant think of a single instance where my LDAP server (IPA or AD) has had it's certs in a chain that's distributed with OSes. Typically, this same chain needs to have a CA somewhere towards the top that the auth service can control for other signing reasons (krb, client certs, etc), Subsequently, the LDAP/Auth CA's cert won't be signed by anybody in the main trust stores (because they aren't going to sign CA Certs with it's own signing power). ## Support for custom LDAP CAs [Hashicorp Vault](https://support.hashicorp.com/hc/en-us/articles/115012966928-Vault-Backend-CA-Certificate-Format) [Rancher](https://rancher.com/docs/rancher/v2.x/en/admin-settings/authentication/ad/#prerequisites) [gitlab](https://docs.gitlab.com/ee/administration/auth/ldap/#ssl-configuration-settings) While adding support in gittea is inherently a larger lift, I think its the "better" solution (at least, the more common one). Barring that, the proposed solution of having the container bootstrap in certs would work too. I could go either way.

GiteaMirror commented

2025-11-02 06:59:49 -06:00

@matthias-colt commented on GitHub (Jul 13, 2021):

How can the certificate check with ldaps be disabled on current Gitea release?
I can only see an option "Skip TLS Verify" in the SMTP section but not for LDAP config.

@matthias-colt commented on GitHub (Jul 13, 2021): How can the certificate check with ldaps be disabled on current Gitea release? I can only see an option "Skip TLS Verify" in the SMTP section but not for LDAP config.

GiteaMirror commented

2025-11-02 06:59:49 -06:00

@th3r3d commented on GitHub (Sep 13, 2021):

Can be done same for OAuth OIDC as suggested by Dunky13 pls.

@th3r3d commented on GitHub (Sep 13, 2021): Can be done same for OAuth OIDC as suggested by Dunky13 pls.

GiteaMirror commented

2025-11-02 06:59:49 -06:00

@zeripath commented on GitHub (Sep 13, 2021):

Skip TLS verify is already in 1.16

@zeripath commented on GitHub (Sep 13, 2021): Skip TLS verify is already in 1.16

GiteaMirror commented

2025-11-02 06:59:49 -06:00

@th3r3d commented on GitHub (Sep 13, 2021):

Skip TLS verify is already in 1.16

Sorry didnt check roadmap for 1.16. Thank you

@th3r3d commented on GitHub (Sep 13, 2021): > Skip TLS verify is already in 1.16 Sorry didnt check roadmap for 1.16. Thank you

GiteaMirror commented

2025-11-02 06:59:50 -06:00

@johannagnarsson commented on GitHub (Nov 7, 2022):

Are there any plans of having the container update the ca trust store on boot? currently we need to run it manually inside the container which isn't really feasible.

@johannagnarsson commented on GitHub (Nov 7, 2022): Are there any plans of having the container update the ca trust store on boot? currently we need to run it manually inside the container which isn't really feasible.

GiteaMirror commented

2025-11-02 06:59:50 -06:00

@sei-mkaar commented on GitHub (Nov 7, 2022):

@johannagnarsson We found that certificates mounted in /etc/ssl/certs are added to the container trust store automatically. Here's a working Helm config that demonstrates it:
https://github.com/cmu-sei/foundry-appliance/blob/main/foundry/common/gitea.values.yaml#L227

Credit to this blog for the idea:
https://schemesandnotions.io/posts/giteadroneselfsignedtls/#gitea---droneci

@sei-mkaar commented on GitHub (Nov 7, 2022): @johannagnarsson We found that certificates mounted in `/etc/ssl/certs` are added to the container trust store automatically. Here's a working Helm config that demonstrates it: https://github.com/cmu-sei/foundry-appliance/blob/main/foundry/common/gitea.values.yaml#L227 Credit to this blog for the idea: https://schemesandnotions.io/posts/giteadroneselfsignedtls/#gitea---droneci

GiteaMirror commented

2025-11-02 06:59:50 -06:00

@johannagnarsson commented on GitHub (Nov 7, 2022):

That totally worked! I was mounting my certs into the "recommended" alpine directory /usr/local/share/ca-certificates/ which wasn't working. Thank you so much for that @sei-mkaar !!

@johannagnarsson commented on GitHub (Nov 7, 2022): That totally worked! I was mounting my certs into the "recommended" alpine directory `/usr/local/share/ca-certificates/` which wasn't working. Thank you so much for that @sei-mkaar !!

GiteaMirror commented

2025-11-02 06:59:50 -06:00

@justusbunsi commented on GitHub (Nov 14, 2022):

Awesome, this is working 🤯. Thanks for sharing @sei-mkaar and to the unknown author of the mentioned blog post.

@justusbunsi commented on GitHub (Nov 14, 2022): Awesome, this is working 🤯. Thanks for sharing @sei-mkaar and to the unknown author of the mentioned blog post.

GiteaMirror commented

2025-11-02 06:59:50 -06:00

@sei-mkaar commented on GitHub (Nov 17, 2022):

You're welcome. 😄

And it looks like this is a feature of the Go crypto/x509 standard library and not necessarily specific to Gitea. Good to know when adding custom certs to other apps.

https://github.com/golang/go/issues/12139

@sei-mkaar commented on GitHub (Nov 17, 2022): You're welcome. 😄 And it looks like this is a [feature of the Go `crypto/x509` standard library](https://go.dev/src/crypto/x509/root_linux.go) and not necessarily specific to Gitea. Good to know when adding custom certs to other apps. https://github.com/golang/go/issues/12139

GiteaMirror commented

2025-11-02 06:59:51 -06:00

@bidek commented on GitHub (Nov 23, 2023):

Is this workaround should work in 1.21.0 version ?

I tried to mount my custom ca at /etc/ssl/certs/customCA.crt. And i see it from container but unless i invoke update-ca-certificates my custom cert is not "registered". For obvious reasons "login" inside container and invoke update-ca-certificates is not an option.

On host side, file have 644 permission and its owned by root

@bidek commented on GitHub (Nov 23, 2023): Is this workaround should work in 1.21.0 version ? I tried to mount my custom ca at /etc/ssl/certs/customCA.crt. And i see it from container but unless i invoke update-ca-certificates my custom cert is not "registered". For obvious reasons "login" inside container and invoke update-ca-certificates is not an option. On host side, file have 644 permission and its owned by root

GiteaMirror commented

2025-11-02 06:59:51 -06:00

@mddeff commented on GitHub (Nov 23, 2023):

@sei-mkaar , so thats really funny, because it turns out that's actually my blog! Its amazing how much we forget about previous problems when trying to solve new ones. Glad that helped!

@mddeff commented on GitHub (Nov 23, 2023): @sei-mkaar , so thats really funny, because it turns out that's actually [my blog](https://github.com/Schemes-and-Notions/schemesandnotions.io/blob/master/content/posts/giteaDroneSelfSignedTLS/index.md)! Its amazing how much we forget about previous problems when trying to solve new ones. Glad that helped!

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#6567