Hi, I’m currently attempting to host a gitlab pages site on a self-hosted gitlab server.
I keep running in circles and believe there could be something I’m simply not understanding.
It’s a project based page (jekyll/just-the-docs) to be exact and when permissions are set to visibility “Everyone” the site is available at groupname.mydomain.pl/projectname. There is a resulting SSL certificate trust error but I’m hoping to deal with that later.
However when I change visibility to “Only project members” the page is no longer available. I see "We can’t connect to the server at projects.git-pages.mydomain.pl. To be clear I am logged in as the owner of the project and thus would expect to have access to the resulting restricted page.
Can anyone explain why the url has changed and whether this is expected behaviour when restricting access? I’d prefer not to have the site publicly exposed and so getting the restrictions down is a must.
Any hints/explanations would be very much appreciated
Seems as though I’ve been able to move a step further. Now when accessing the url from a non-authenticated session I get redirected to the gitlab login page (as expected).
However as an authenticated user I encounter “The redirect URI included is not valid.” presented over the user settings page.
Have you tried this from the Troubleshooting section?
You may see this error if pages_external_url was updated at some point of time. Verify the following:
The Callback URL/Redirect URI in the GitLab Pages System OAuth application is using the protocol (HTTP or HTTPS) that pages_external_url is configured to use.
The domain and path components of Redirect URI are valid: they should look like projects.<pages_external_url>/auth.
Apologies, for the delay. Due to Christmas break I was unable to return to this issue earlier.
Looking at it now and will return with any further findings.
So I can confirm that reviewing the application settings when logged in as an administrator did help us progress a little further. To be clear, I had to enter the correct callback url and ensure that it was scoped to the api. As a result, users must be authenticated before they are able to access anything.
The remaining issue seems to be a certificate trust issuel namely SSL_ERROR_BAD_CERT_DOMAIN error - apparently my certificate is not valid for the pages domain.
I’ll admit I have gone through the available documentation, however there’s so many different clauses and exceptions and that I don’t really understand what seems to be the underlying issue in my case.
My setup is as follows
my ssl certificate: *.mydomain.com
pages site domain: groupname.git-pages.mydomain.pl/projectname
I have currently enabled Force HTTPS (requires valid certificates) in the Pages UI but have not created a new domain - is this strictly necessary?
Wrapping this up. In the end all that was required was ensuring that a new wildcard certificate for the correct domain was issued and deployed where necessary (gitlab server and anything else thats web facing in your setup). The above SSL error was actually a hint in the right direction as it indicated that the wrong cert had initially been published for gitlab pages.
It’s critical to remember that gitlab-pages itself can have an ip, ssl certificate and routing setup different to that of gitlab itself, even though they are the same server.
In my case the following command was useful to verify what certificate was used for the site. openssl s_client -showcerts -connect <project>.git-pages.<domain>:443 </dev/null
