I'm trying to configure a Git repo in Komodo, to a custom Gitlab instance I'm hosting myself. It's backed by a reverse proxy terminating TLS with a custom CA. When I add the repo to a Resource Sync config, it can't initialise the file because of the following error:
fatal: unable to access 'https://gitlab.custom.domain/infra/compose/': server certificate verification failed. CAfile: none CRLfile: none
error: Could not fetch origin
I know both methods work, because I also use a custom OIDC provider hosted on the same reverse proxy with the same custom CA, and that works with both of these methods. If I remove both, the OIDC provider stops working too.
Could there be something I'm missing, or is the Git system in Komodo using a different CA bundle by any chance?
Thanks
Ali
Originally created by @alihamzam on GitHub (Aug 22, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/757
Hi guys,
I'm trying to configure a Git repo in Komodo, to a custom Gitlab instance I'm hosting myself. It's backed by a reverse proxy terminating TLS with a custom CA. When I add the repo to a Resource Sync config, it can't initialise the file because of the following error:
```
fatal: unable to access 'https://gitlab.custom.domain/infra/compose/': server certificate verification failed. CAfile: none CRLfile: none
error: Could not fetch origin
```
I've seen the previous posts about injecting custom CA's into Komodo (https://github.com/moghtech/komodo/issues/130 and https://github.com/moghtech/komodo/issues/341), and I've injected the custom CA with both methods:
Through customising the Docker image:
```
core:
build:
dockerfile_inline: |
FROM ghcr.io/moghtech/komodo-core:1.19
ADD ./root_ca.crt /usr/local/share/ca-certificates/root_ca.crt
RUN update-ca-certificates
labels:
- komodo.skip
restart: unless-stopped
depends_on:
- mongo
ports:
- 9120:9120
env_file: ./.env
networks:
traefik:
komodo:
environment:
KOMODO_DATABASE_ADDRESS: mongo:27017
KOMODO_DATABASE_USERNAME: ${KOMODO_DB_USERNAME}
KOMODO_DATABASE_PASSWORD: ${KOMODO_DB_PASSWORD}
volumes:
- ./syncs:/syncs
periphery:
build:
dockerfile_inline: |
FROM ghcr.io/moghtech/komodo-periphery:1.19
ADD ./root_ca.crt /usr/local/share/ca-certificates/root_ca.crt
RUN update-ca-certificates
labels:
komodo.skip:
restart: unless-stopped
env_file: ./.env
networks:
komodo:
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /proc:/proc
- ${PERIPHERY_ROOT_DIRECTORY:-/etc/komodo}:${PERIPHERY_ROOT_DIRECTORY:-/etc/komodo}
```
And as volume mounts with a customised entrypoint:
```
core:
image: ghcr.io/moghtech/komodo-core:1.19
labels:
- komodo.skip
restart: unless-stopped
depends_on:
- mongo
ports:
- 9120:9120
env_file: ./.env
entrypoint: sh -c 'update-ca-certificates; core'
networks:
traefik:
komodo:
environment:
KOMODO_DATABASE_ADDRESS: mongo:27017
KOMODO_DATABASE_USERNAME: ${KOMODO_DB_USERNAME}
KOMODO_DATABASE_PASSWORD: ${KOMODO_DB_PASSWORD}
volumes:
- ./syncs:/syncs
- ./root_ca.crt:/usr/local/share/ca-certificates/root_ca.crt:ro
periphery:
image: ghcr.io/moghtech/komodo-periphery:1.19
labels:
komodo.skip:
restart: unless-stopped
env_file: ./.env
entrypoint: sh -c 'update-ca-certificates; periphery'
networks:
komodo:
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /proc:/proc
- ./root_ca.crt:/usr/local/share/ca-certificates/root_ca.crt:ro
- ${PERIPHERY_ROOT_DIRECTORY:-/etc/komodo}:${PERIPHERY_ROOT_DIRECTORY:-/etc/komodo}
```
I know both methods work, because I also use a custom OIDC provider hosted on the same reverse proxy with the same custom CA, and that works with both of these methods. If I remove both, the OIDC provider stops working too.
My resource sync config:
```
[[resource_sync]]
name = "gitlab-infra-compose-2"
[resource_sync.config]
git_provider = "gitlab.custom.domain"
repo = "infra/compose"
git_account = "svc-account-komodo"
resource_path = ["test-stack.toml"]
```
Could there be something I'm missing, or is the Git system in Komodo using a different CA bundle by any chance?
Thanks
Ali
Hm, the last time I checked this method worked with Gitea using internal DNS / CA, I do not currently use this setup. Maybe a user in the discord can corroborate this issue?
<!-- gh-comment-id:3238998048 -->
@mbecker20 commented on GitHub (Aug 30, 2025):
Hm, the last time I checked this method worked with Gitea using internal DNS / CA, I do not currently use this setup. Maybe a user in the discord can corroborate this issue?
Ran into the same problem, turned out to be a minor misconfiguration of the webserver.
It was not serving the intermediate certificate. Fixed that, it's working now.
if you shell into the periphery container, openssl s_client -connect host:port gives good pointers what's actually going wrong.
<!-- gh-comment-id:3244702960 -->
@alphafalcon commented on GitHub (Sep 2, 2025):
Ran into the same problem, turned out to be a minor misconfiguration of the webserver.
It was not serving the intermediate certificate. Fixed that, it's working now.
if you shell into the periphery container, `openssl s_client -connect host:port` gives good pointers what's actually going wrong.
After a lot of testing, I get some really weird behaviour. If I use openssl s_client in the periphery container, I get the full CA chain and there's no "self-signed certificate" warnings, and everything seems to work as expected. If I then go into the core container, the same command returns only the leaf certificate (and no CAs at all), and shows "self-signed certificate":
Core:
❯ bf623f41c9cd ❯ 🦎 core container ❯ root ❯ /app
❯ openssl s_client -connect gitlab.mydomain:443
CONNECTED(00000003)
depth=0 CN = gitlab.mydomain
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = gitlab.mydomain
verify return:1
---
Certificate chain
0 s:CN = gitlab.mydomain
i:CN = gitlab.mydomain
---
Server certificate
-----BEGIN CERTIFICATE-----
PEM
-----END CERTIFICATE-----
subject=CN = gitlab.mydomain
issuer=CN = gitlab.mydomain
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1356 bytes and written 397 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
Periphery container:
❯ 77e7a250dc0f ❯ 🦎 periphery container ❯ root ❯ /app
❯ openssl s_client -connect gitlab.mydomain:443
CONNECTED(00000003)
depth=2 CN = Root CA
verify return:1
depth=1 CN = Intermediate CA
verify return:1
depth=0 CN = gitlab.mydomain
verify return:1
---
Certificate chain
0 s:CN = gitlab.mydomain
i:CN = Intermediate CA
1 s:CN = Intermediate CA
i:CN = Root CA
2 s:CN = Root CA
i:CN = Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
PEM
-----END CERTIFICATE-----
subject=CN = gitlab.mydomain
issuer=CN = Intermediate CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2706 bytes and written 381 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
As you can see, the Periphery container sees the full chain and can validate it. In the Komodo frontend, still the same issue. I've even tried tarballing the contents of /etc/ssl/certs/ from the Periphery container and unpacking it in the Core container, but still the same issue. I've also tried running s_client with multiple other domains and I see the same issue there too.
Thanks
Ali
<!-- gh-comment-id:3263197149 -->
@alihamzam commented on GitHub (Sep 6, 2025):
Hey, apologies for the late reply.
After a lot of testing, I get some really weird behaviour. If I use `openssl s_client` in the periphery container, I get the full CA chain and there's no "self-signed certificate" warnings, and everything seems to work as expected. If I then go into the core container, the same command returns only the leaf certificate (and no CAs at all), and shows "self-signed certificate":
Core:
```
❯ bf623f41c9cd ❯ 🦎 core container ❯ root ❯ /app
❯ openssl s_client -connect gitlab.mydomain:443
CONNECTED(00000003)
depth=0 CN = gitlab.mydomain
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = gitlab.mydomain
verify return:1
---
Certificate chain
0 s:CN = gitlab.mydomain
i:CN = gitlab.mydomain
---
Server certificate
-----BEGIN CERTIFICATE-----
PEM
-----END CERTIFICATE-----
subject=CN = gitlab.mydomain
issuer=CN = gitlab.mydomain
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1356 bytes and written 397 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
```
Periphery container:
```
❯ 77e7a250dc0f ❯ 🦎 periphery container ❯ root ❯ /app
❯ openssl s_client -connect gitlab.mydomain:443
CONNECTED(00000003)
depth=2 CN = Root CA
verify return:1
depth=1 CN = Intermediate CA
verify return:1
depth=0 CN = gitlab.mydomain
verify return:1
---
Certificate chain
0 s:CN = gitlab.mydomain
i:CN = Intermediate CA
1 s:CN = Intermediate CA
i:CN = Root CA
2 s:CN = Root CA
i:CN = Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
PEM
-----END CERTIFICATE-----
subject=CN = gitlab.mydomain
issuer=CN = Intermediate CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2706 bytes and written 381 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
```
As you can see, the Periphery container sees the full chain and can validate it. In the Komodo frontend, still the same issue. I've even tried tarballing the contents of `/etc/ssl/certs/` from the Periphery container and unpacking it in the Core container, but still the same issue. I've also tried running s_client with multiple other domains and I see the same issue there too.
Thanks
Ali
Ok, I figured it out. Komodo core and Gitlab are exposed through the same Traefik ingress, so they share a Docker network (at the moment). Gitlab sets it's hostname to your custom domain (gitlab.mydomain), so when Komodo core tries to access it, it's actually directly access Gitlab's port 443, rather than through the ingress where the TLS with the custom CA is terminated. This is why s_client doesn't show a chain, only a leaf certificate. Periphery isn't on the same Docker network, and so it goes externally through the ingress.
I've rectified this and Komodo's working now. Thanks for the help!
<!-- gh-comment-id:3263222795 -->
@alihamzam commented on GitHub (Sep 6, 2025):
Ok, I figured it out. Komodo core and Gitlab are exposed through the same Traefik ingress, so they share a Docker network (at the moment). Gitlab sets it's hostname to your custom domain (gitlab.mydomain), so when Komodo core tries to access it, it's actually directly access Gitlab's port 443, rather than through the ingress where the TLS with the custom CA is terminated. This is why s_client doesn't show a chain, only a leaf certificate. Periphery isn't on the same Docker network, and so it goes externally through the ingress.
I've rectified this and Komodo's working now. Thanks for the help!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @alihamzam on GitHub (Aug 22, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/757
Hi guys,
I'm trying to configure a Git repo in Komodo, to a custom Gitlab instance I'm hosting myself. It's backed by a reverse proxy terminating TLS with a custom CA. When I add the repo to a Resource Sync config, it can't initialise the file because of the following error:
I've seen the previous posts about injecting custom CA's into Komodo (https://github.com/moghtech/komodo/issues/130 and https://github.com/moghtech/komodo/issues/341), and I've injected the custom CA with both methods:
Through customising the Docker image:
And as volume mounts with a customised entrypoint:
I know both methods work, because I also use a custom OIDC provider hosted on the same reverse proxy with the same custom CA, and that works with both of these methods. If I remove both, the OIDC provider stops working too.
My resource sync config:
Could there be something I'm missing, or is the Git system in Komodo using a different CA bundle by any chance?
Thanks
Ali
@mbecker20 commented on GitHub (Aug 30, 2025):
Hm, the last time I checked this method worked with Gitea using internal DNS / CA, I do not currently use this setup. Maybe a user in the discord can corroborate this issue?
@alphafalcon commented on GitHub (Sep 2, 2025):
Ran into the same problem, turned out to be a minor misconfiguration of the webserver.
It was not serving the intermediate certificate. Fixed that, it's working now.
if you shell into the periphery container,
openssl s_client -connect host:portgives good pointers what's actually going wrong.@alihamzam commented on GitHub (Sep 6, 2025):
Hey, apologies for the late reply.
After a lot of testing, I get some really weird behaviour. If I use
openssl s_clientin the periphery container, I get the full CA chain and there's no "self-signed certificate" warnings, and everything seems to work as expected. If I then go into the core container, the same command returns only the leaf certificate (and no CAs at all), and shows "self-signed certificate":Core:
Periphery container:
As you can see, the Periphery container sees the full chain and can validate it. In the Komodo frontend, still the same issue. I've even tried tarballing the contents of
/etc/ssl/certs/from the Periphery container and unpacking it in the Core container, but still the same issue. I've also tried running s_client with multiple other domains and I see the same issue there too.Thanks
Ali
@alihamzam commented on GitHub (Sep 6, 2025):
Ok, I figured it out. Komodo core and Gitlab are exposed through the same Traefik ingress, so they share a Docker network (at the moment). Gitlab sets it's hostname to your custom domain (gitlab.mydomain), so when Komodo core tries to access it, it's actually directly access Gitlab's port 443, rather than through the ingress where the TLS with the custom CA is terminated. This is why s_client doesn't show a chain, only a leaf certificate. Periphery isn't on the same Docker network, and so it goes externally through the ingress.
I've rectified this and Komodo's working now. Thanks for the help!