Issue Summary

When configuring the GitHub Enterprise Server (GHES) integration with Jira Cloud via a locked gateway, administrators and end users in split-domain environments cannot control which domain is used for browser redirects. The app always uses the external-facing GHES URL, even when an internal UI-only domain is required.

This causes:

• Setup flows to require manual URL edits or local DNS hacks, and
• User-facing actions like “View branch on GitHub” to send users to an external gateway URL that returns HTTP 403, instead of their internal GHES UI URL.

Environment:

• Jira Cloud site: https://jira-xxxxxxx-99999.atlassian.net
• External GHES gateway URL (API + setup redirects): https://ghe-gateway-99999.example.com
• Internal GHES UI URL (used by users/admins): https://ghe-internal-99999.example.corp

Steps to Reproduce

1. As a Jira admin, configure the GitHub Enterprise Server integration:
1.1. In Jira Cloud, go to Apps → Manage Apps → GitHub for Jira → Configure.
1.2. Add a new GitHub Enterprise Server using the external gateway URL: https://ghe-gateway-99999.example.com
1.3. Use manual app creation and create a GitHub App on GHES following: [Manually create a GitHub app for Enterprise Server | Atlassian Support|https://support.atlassian.com/jira-cloud-administration/docs/manually-create-a-github-app/]
1.4. Complete the manual steps and authorize the app.

2. Observe the setup / auth flow:
2.1. When Jira opens a new browser tab to complete authorization, it navigates to: https://ghe-gateway-99999.example.com/login?...
2.2. Due to subdomain isolation and certificate/DNS constraints, the admin must manually change the URL in the browser to the internal GHES URL: https://ghe-internal-99999.example.corp/login?... in order to complete the authorization successfully.

3. After the connection is established, validate user functionality from Jira:
3.1. In a Jira Software project, open an issue that is associated with a repository on GHES.
3.2. From the developer panel, use the Create branch action:

• Select a repository hosted on GHES.
• Choose a source branch and enter a new branch name.

3.3. Submit the branch creation.

4. Check the link Jira provides after the branch is created:
4.1. Jira displays a confirmation message with a “View branch on GitHub” link.
4.2. Click the “View branch on GitHub” link.

Expected Results

During setup:
Jira should be able to use two domains configured for the GHES integration:

• External-facing endpoint (e.g. https://ghe-gateway-99999.example.com) for webhook/API communication and Atlassian-to-GHES calls.
• Internal UI domain (e.g. https://ghe-internal-99999.example.corp) for browser-based redirects (admin setup flows, user actions such as “View branch on GitHub”).
• The app should redirect the browser to the internal UI domain, without requiring the admin to manually edit the URL.

For user workflows (e.g. branch creation from Jira):

• The “View branch on GitHub” link should send users to the internal GHES domain, such as: https://ghe-internal-99999.example.corp/<org>/<repo>/tree/<branch>
• Users should be able to open the branch in GHES without hitting a 403 or misrouted external URL.

The integration should allow explicit configuration of:

• externalBaseUrl (API / webhook endpoint)
• internalUiUrl (browser-facing UI base URL)

Actual Results

During setup:

• Jira always redirects the browser to the external gateway URL, for example: https://ghe-gateway-99999.example.com/login?...
• In split-domain + subdomain-isolation environments, the GHES UI assets (e.g. https://assets.ghe-gateway-99999.example.com/...) may have invalid or mismatched TLS certificates and/or DNS for the admin’s machine.
• The admin has to manually change the URL in the browser to the internal domain (e.g. https://ghe-internal-99999.example.corp/...) in order to see the GHES UI and complete authorization.

For users creating branches from Jira:

• After branch creation, the “View branch on GitHub” link uses the external gateway URL, for example:
  https://ghe-gateway-99999.example.com/<org>/<repo>/tree/<branch>
• In this environment, the external gateway is not intended for direct user UI access, and the request returns HTTP 403 for end users.
• Users must manually replace the domain in the URL with the internal UI domain, or navigate directly in GHES, to view the branch.

In contrast, when creating a Pull Request from Jira, the link correctly uses the internal GHES domain, so behavior is inconsistent across features.

No specific server-side exception was observed in Jira logs for this behavior.
Client-side HAR from the browser shows TLS / connectivity errors when attempting to load GHES asset subdomains from the external gateway host:
Request URL: https://assets.ghe-gateway-99999.example.com/assets/....
Error: net::ERR_CERT_COMMON_NAME_INVALID
Additional failures:
- net::ERR_CERT_COMMON_NAME_INVALID
- net::ERR_CONNECTION_REFUSED 

Note: The primary impact is incorrect browser routing to the external domain, surfaced as HTTP 403 and TLS/CN errors on the client side, rather than a distinct Jira server exception.

Workaround

Currently there is no full product-level fix for this behavior. The following partial workarounds are used:

For setup / authorization flows (admin-only):

• Manually change the URL in the browser tab from the external gateway host (e.g. https://ghe-gateway-99999.example.com/...) to the internal GHES UI domain (e.g. https://ghe-internal-99999.example.corp/...) whenever the Jira wizard opens a new tab for GitHub login/authorization.
• Alternatively, configure local /etc/hosts or internal DNS on the admin’s machine so that GHES asset subdomains resolve correctly while going through the setup wizard.

For user-facing “View branch on GitHub” link:

• Users manually replace the external gateway domain with the internal GHES UI domain in the URL after Jira opens it, or navigate directly to the branch inside GHES.

These workarounds are manual and error-prone.

Currently there is no known configuration option in the product to specify different internal vs external domains so that Jira automatically uses the internal domain for browser redirects. A product-level enhancement is requested to add this capability.