Custom domain TLS cert not issued 24h+ after deploy (pages-server/git-pages migration stall) #2655

germ501 commented 2026年05月18日 18:03:10 +02:00

Symptom

Custom domain HTTPS cert never issued. HTTP serves a 302 to HTTPS correctly, but the TLS handshake fails with tlsv1 alert internal error. The default codeberg.page URL works fine.

$ curl -sSI https://andygarcia.me/
curl: (35) OpenSSL/3.0.13: error:0A000438:SSL routines::tlsv1 alert internal error
$ curl -sSI http://andygarcia.me/
HTTP/1.1 302 Found
location: https://andygarcia.me/

Deployed 2026年05月17日, still failing as of 2026年05月18日 (>24h, well past the normal 1-3 min provisioning window and past the typical hours-long backoff after a failed validation).

Configuration

• Repo: https://codeberg.org/germ501/pages (public)
• Deployment branch: pages (contains site + .domains file with single line andygarcia.me)
• DNS at Cloudflare (DNS-only, gray cloud, proxy off):
  • A 217.197.84.141
  • AAAA 2a0a:4580:103f:c0de::2
  • TXT germ501.codeberg.page
• No CAA records (Let's Encrypt allowed by default)
• Domain binding is recognized: germ501.codeberg.page 307-redirects to https://andygarcia.me/?, so .domains and TXT are parsed correctly.

Apparent cause: migration stall

Response headers from germ501.codeberg.page show both:

server: pages-server
server: git-pages (git-pages)

This matches the pages-server → git-pages migration symptom described in:

• Codeberg/Community#2528 (same symptom: TLS internal_error on custom domain, codeberg.page URL works)
• Codeberg/Community#2422
• Codeberg/pages-server#444

Already verified (please skip these in triage)

• DNS records correct and globally propagated (verified via dig + 1.1.1.1)
• No CAA records blocking issuance
• .well-known/acme-challenge/<random> returning 503 is normal Caddy behavior (docs.codeberg.org does the same), not the cause
• Repo is public (private repos silently break pages-server fetch)
• Repo name has no dots; previous andygarcia.me repo was renamed to pages to fix TXT parsing and wildcard-cert matching
• Cloudflare proxy is off on all relevant records
• An empty commit on pages (3252131) did not nudge cert issuance

Ask

Could an admin force a cert provisioning retry for andygarcia.me, or confirm whether this domain's binding is stuck on the legacy pages-server during the migration? Happy to provide any further diagnostics.

## Symptom Custom domain HTTPS cert never issued. HTTP serves a 302 to HTTPS correctly, but the TLS handshake fails with `tlsv1 alert internal error`. The default codeberg.page URL works fine. ``` $ curl -sSI https://andygarcia.me/ curl: (35) OpenSSL/3.0.13: error:0A000438:SSL routines::tlsv1 alert internal error $ curl -sSI http://andygarcia.me/ HTTP/1.1 302 Found location: https://andygarcia.me/ ``` Deployed 2026年05月17日, still failing as of 2026年05月18日 (>24h, well past the normal 1-3 min provisioning window and past the typical hours-long backoff after a failed validation). ## Configuration - Repo: https://codeberg.org/germ501/pages (public) - Deployment branch: `pages` (contains site + `.domains` file with single line `andygarcia.me`) - DNS at Cloudflare (DNS-only, gray cloud, proxy off): - A 217.197.84.141 - AAAA 2a0a:4580:103f:c0de::2 - TXT germ501.codeberg.page - No CAA records (Let's Encrypt allowed by default) - Domain binding is recognized: `germ501.codeberg.page` 307-redirects to `https://andygarcia.me/?`, so `.domains` and TXT are parsed correctly. ## Apparent cause: migration stall Response headers from `germ501.codeberg.page` show *both*: ``` server: pages-server server: git-pages (git-pages) ``` This matches the pages-server → git-pages migration symptom described in: - Codeberg/Community#2528 (same symptom: TLS internal_error on custom domain, codeberg.page URL works) - Codeberg/Community#2422 - Codeberg/pages-server#444 ## Already verified (please skip these in triage) - DNS records correct and globally propagated (verified via dig + 1.1.1.1) - No CAA records blocking issuance - `.well-known/acme-challenge/<random>` returning 503 is normal Caddy behavior (docs.codeberg.org does the same), not the cause - Repo is public (private repos silently break pages-server fetch) - Repo name has no dots; previous `andygarcia.me` repo was renamed to `pages` to fix TXT parsing and wildcard-cert matching - Cloudflare proxy is off on all relevant records - An empty commit on `pages` (3252131) did not nudge cert issuance ## Ask Could an admin force a cert provisioning retry for andygarcia.me, or confirm whether this domain's binding is stuck on the legacy pages-server during the migration? Happy to provide any further diagnostics.

faebser commented 2026年05月19日 14:04:16 +02:00

Hi,

We currently have the same problem. Repository is https://codeberg.org/PIA/pages and the target domain is https://about.participatory-archives.ch/. I've added the domain to the .domains file in the page branch of the repo.

curl -sSI https://about.participatory-archives.ch/
curl: (35) LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error

Hi, We currently have the same problem. Repository is https://codeberg.org/PIA/pages and the target domain is https://about.participatory-archives.ch/. I've added the domain to the .domains file in the page branch of the repo. ```bash curl -sSI https://about.participatory-archives.ch/ curl: (35) LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error ```

whitequark commented 2026年05月19日 14:44:37 +02:00

@germ501

1. If you use an LLM to debug an issue it is considered polite to disclose that.
2. The .domains file is no longer used. Git-pages uses DNS as the source of truth for authorization and TLS certificate issuance.
3. How did you deploy the site exactly? You need to set up a webhook. I didn't see any POST or PUT requests for this domain in the last 24h.
4. The redirect from germ501.codeberg.page to andygarcia.me is done by legacy pages-server. If you want to retain control of the redirect you will need to set up webhooks to deploy to both domains, and include a Netlify compatible _redirects file with e.g. //germ501.codeberg.page/* https://andygarcia.me/:splat. (Don't worry about deploying the same site to both domains, it doesn't take much resources.)
5. Git-pages does work with private repositories, but it requires deployment via Forgejo Actions.

@faebser

1. The .domains file is no longer used. Git-pages uses DNS as the source of truth for authorization and TLS certificate issuance.
2. You need to set up a webhook. I didn't see any POST or PUT requests for this domain in the last 24h.

@germ501 1. If you use an LLM to debug an issue it is considered polite to disclose that. 2. The `.domains` file is no longer used. Git-pages uses DNS as the source of truth for authorization and TLS certificate issuance. 3. How did you deploy the site exactly? You need to [set up a webhook](https://docs.codeberg.org/codeberg-pages/migrating-from-pages-v2/#direct-migration-of-pages-sites-using-a-webhook). I didn't see any POST or PUT requests for this domain in the last 24h. 4. The redirect from germ501.codeberg.page to andygarcia.me is done by legacy pages-server. If you want to retain control of the redirect you will need to set up webhooks to deploy to *both domains*, and include a Netlify compatible `_redirects` file with e.g. `//germ501.codeberg.page/* https://andygarcia.me/:splat`. (Don't worry about deploying the same site to both domains, it doesn't take much resources.) 5. Git-pages does work with private repositories, but it requires deployment via Forgejo Actions. @faebser 1. The `.domains` file is no longer used. Git-pages uses DNS as the source of truth for authorization and TLS certificate issuance. 2. You need to [set up a webhook](https://docs.codeberg.org/codeberg-pages/migrating-from-pages-v2/#direct-migration-of-pages-sites-using-a-webhook). I didn't see any POST or PUT requests for this domain in the last 24h.

germ501 commented 2026年05月19日 15:19:01 +02:00

Thank you for the response. Apologies for not disclosing LLM use, I have spinal cord and brain injury that makes typing very slow as result of MS (numb hands basically), I will do my best to type myself what is going in

I added a Forgejo webhook on germ501/pages with target URL https://andygarcia.me/ and branch filter pages, then pushed an empty commit to pages (38e284d : hash for push) to fire it. Roughly 10 minutes after the push, curl -sSI https://andygarcia.me/ still returns tlsv1 alert internal error, and HTTP continues to 302-redirect to HTTPS via the legacy pages-server. Is the slow provisioning expected here or did I configure something wrong?

Thank you for the response. Apologies for not disclosing LLM use, I have spinal cord and brain injury that makes typing very slow as result of MS (numb hands basically), I will do my best to type myself what is going in I added a Forgejo webhook on germ501/pages with target URL https://andygarcia.me/ and branch filter pages, then pushed an empty commit to pages (38e284d : hash for push) to fire it. Roughly 10 minutes after the push, curl -sSI https://andygarcia.me/ still returns tlsv1 alert internal error, and HTTP continues to 302-redirect to HTTPS via the legacy pages-server. Is the slow provisioning expected here or did I configure something wrong?

whitequark commented 2026年05月19日 15:23:51 +02:00

I'm sorry to hear about MS. To clarify, I was only requesting disclosure (in the context of the Codeberg community support tracker at least).

The deploy should happen nearly instantaneously, within seconds. I'm looking into it.

I'm sorry to hear about MS. To clarify, I was only requesting disclosure (in the context of the Codeberg community support tracker at least). The deploy should happen nearly instantaneously, within seconds. I'm looking into it.

whitequark commented 2026年05月19日 15:37:44 +02:00

Ah right! You've hit an issue that is unfortunately not explained in the documentation yet. The webhook needs to be configured with the http:// scheme for the initial deploy. After that you can leave it at that or change it to https:// scheme.

Ah right! You've hit an issue that is unfortunately not explained in the documentation yet. The webhook needs to be configured with the `http://` scheme for the initial deploy. After that you can leave it at that or change it to `https://` scheme.

germ501 commented 2026年05月19日 15:54:55 +02:00

I tried the http:// scheme and the webhook still fails with Post "https://andygarcia.me/": remote error: tls: internal error, with the final URL showing https://. I even deleted the old one, created a new one; same thing.

I tried the http:// scheme and the webhook still fails with Post "https://andygarcia.me/": remote error: tls: internal error, with the final URL showing https://. I even deleted the old one, created a new one; same thing.

whitequark commented 2026年05月19日 16:03:15 +02:00

This is a regression in Codeberg's configuration that I wasn't aware of. I manually triggered the initial deploy for you. Your webhook should work fine going forward (with either scheme); please go ahead and confirm that. Sorry about the issues.

This is a regression in Codeberg's configuration that I wasn't aware of. I manually triggered the initial deploy for you. Your webhook should work fine going forward (with either scheme); please go ahead and confirm that. Sorry about the issues.

whitequark commented 2026年05月19日 16:08:10 +02:00

For other people who may be hitting the same issue, here is how you can manually trigger a webhook request to a git-pages instance:

$ curl -X POST https://codeberg.page -H 'Host: example.org' -H 'X-Forgejo-Event: push' --json '{"ref":"refs/heads/pages","repository":{"clone_url":"https://codeberg.org/example/pages.git"}}'
created

The URL being https://codeberg.page is working around the regression I mentioned earlier. Fill in your own values for Host: and clone_url and it should work.

If you're trying to deploy to a non-root site, e.g. for a project.git repository, the URL needs to be altered in a non-intuitive way:

$ curl -X POST https://codeberg.page/project -H 'Host: example.org' -H 'X-Forgejo-Event: push' --json '{"ref":"refs/heads/pages","repository":{"clone_url":"https://codeberg.org/example/project.git"}}'
created

(What happens here is that codeberg.page is used to make the connection, but then the Host: value replaces that part of the URL for the actual HTTP request.)

For other people who may be hitting the same issue, here is how you can manually trigger a webhook request to a git-pages instance: ``` $ curl -X POST https://codeberg.page -H 'Host: example.org' -H 'X-Forgejo-Event: push' --json '{"ref":"refs/heads/pages","repository":{"clone_url":"https://codeberg.org/example/pages.git"}}' created ``` The URL being `https://codeberg.page` is working around the regression I mentioned earlier. Fill in your own values for `Host:` and `clone_url` and it should work. If you're trying to deploy to a non-root site, e.g. for a `project.git` repository, the URL needs to be altered in a non-intuitive way: ``` $ curl -X POST https://codeberg.page/project -H 'Host: example.org' -H 'X-Forgejo-Event: push' --json '{"ref":"refs/heads/pages","repository":{"clone_url":"https://codeberg.org/example/project.git"}}' created ``` (What happens here is that `codeberg.page` is used to make the connection, but then the `Host:` value replaces that part of the URL for the actual HTTP request.)

germ501 commented 2026年05月19日 16:14:27 +02:00

Thank you! I believe everything is fine now. Again, thanks for the help and quick responses.

Thank you! I believe everything is fine now. Again, thanks for the help and quick responses.

whitequark commented 2026年05月19日 16:15:34 +02:00

You're welcome

You're welcome

whitequark commented 2026年05月19日 16:16:27 +02:00

@faebser I've also triggered an initial deploy for you manually.

@faebser I've also triggered an initial deploy for you manually.

faebser commented 2026年05月19日 19:09:48 +02:00

@whitequark wrote in #2655 (comment):

@faebser I've also triggered an initial deploy for you manually.

Thank you. So I can delete the domains file and simply add a webhook with the target domain https://about.participatory-archives.ch/?

I've attached a screenshot of the documentation where it says that for a custom domain one needs to use the old way. Further down it says that one needs to use a .domains file. Is that info outdated?

@whitequark wrote in https://codeberg.org/Codeberg/Community/issues/2655#issuecomment-15366005: > @faebser I've also triggered an initial deploy for you manually. Thank you. So I can delete the domains file and simply add a webhook with the target domain https://about.participatory-archives.ch/? I've attached a screenshot of the documentation where it says that for a custom domain one needs to use the old way. Further down it says that one needs to use a .domains file. Is that info outdated?

whitequark commented 2026年05月19日 19:36:03 +02:00

Yes and yes.

Yes and yes.