github-starred/komodo
2
0
Fork 1
mirror of https://github.com/moghtech/komodo.git synced 2026-05-06 08:40:30 -05:00
Code Issues 3.5k Packages Projects Releases 103 Wiki Activity

[GH-ISSUE #757] Komodo complains when cloning from Git repo with custom CA #8663

New Issue
Closed
opened 2026-05-03 04:48:08 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-05-03 04:48:08 -05:00
Owner
Copy Link

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

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
GiteaMirror added the seen 👀 label 2026-05-03 04:48:08 -05:00
GiteaMirror commented 2026-05-03 04:48:12 -05:00
Author
Owner
Copy Link

@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?

<!-- 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?
GiteaMirror commented 2026-05-03 04:48:14 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-05-03 04:48:16 -05:00
Author
Owner
Copy Link

@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

<!-- 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
GiteaMirror commented 2026-05-03 04:48:17 -05:00
Author
Owner
Copy Link

@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!

<!-- 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!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
1.19.0
1.19.1
1.19.2
1.19.3
1.19.4
2.0.0
bug
documentation
done
enhancement
help wanted
info
pull-request
Mirrored from GitHub Pull Request
 question
security
seen 👀
setup
thinking 🤔
ui
v2
No Label seen 👀
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/komodo#8663
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?