Issue with Access Control on GitLab Pages – Site Not Accessible After Enabling

How to Use GitLab
, ,
1

Hi everyone,

I’m seeking advice on an issue with my GitLab Pages site, which has recently become inaccessible after implementing access control.

Background:
My site, served over HTTPS, was previously accessible to everyone. I aimed to align the site’s access with my GitLab project’s privacy settings (set to private), allowing only project members to visit the site.

Issue:
Post-implementation of access control (configured both in gitlab.rb and project settings), the site fails to load. Instead of a sign-in page or the site itself, there is this error:

“This site can’t be reached sitename.domain.net’s server IP address could not be found”

Interestingly, the issue persists even when I set the access level to “Everybody.”

However, if I revert the changes in the gitlab.rb file (commenting the access control), the site becomes accessible again.

Specifics:

-I am using GitLab CE 16.2.
-The error does not lead to a sign-in page.
-The problem occurs regardless of setting the access level to “Everybody” or “Only Project Members.”

I’ve come across posts discussing similar topics, but none match my situation where the site doesn’t even navigate to a sign-in page, and the accessibility doesn’t change with different user access settings.

Any insights, similar experiences, or suggestions for additional troubleshooting steps would be greatly appreciated. I’m happy to provide more details if needed.

Thank you for your time and assistance!

2

This sounds like a different layer problem with networking and DNS resolution, and unrelated to modifying project settings in the application.

What happens when you try fetching the website content and resolving on the terminal, i.e. through

dig sitename.domain.net A 

ping -c 1 sitename.domain.net 

traceroute sitename.domain.net 

curl -Lvvv sitename.domain.net

Linux packages, or container image, or cloud-native Helm chart/Operator?

Can you share the change diff of these changes?

3

Thank you for your suggestions regarding the network and DNS diagnostics. I’ve run the commands you suggested, and here are the results:

  1. DNS Resolution (dig):The dig sitename.domain.net A command returned the correct IP address for my site in the ANSWER SECTION
  2. Network Connectivity (ping): Running ping -c 1 sitename.domain.net was successful, with 1 packets transmitted, 1 received, 0% packet loss, indicating good network connectivity.
  3. Traceroute: Unfortunately, the traceroute command was not found on my system
  4. SSL Certificate Check (curl):The curl -Lvvv sitename.domain.net command resulted in an SSL certificate problem: SSL certificate problem: self-signed certificate in certificate chain. It seems that the server is using a self-signed certificate, and curl couldn’t establish a secure connection due to this.

For the gitlab.rb file, the only thing I did is uncomment this line (and put true):

gitlab_pages[‘access_control’] = true

Like I said, if I comment it back (#), my site works again.

The GitLab instance is deployed using Linux packages on a Red hat server. My site is accessible without Access Control, despite the SSL certificate issue, but becomes inaccessible when Access Control is enabled.

Given these results, it seems the SSL certificate might be part of the issue, especially considering that the site works when access control is disabled. However, I’m puzzled as to why enabling access control would cause the site to become unreachable, given the same SSL setup. Do you think resolving the SSL certificate issue would rectify this, or could there be something else at play here? Also, can I bypass that requirement if it is because of the self signed certificate ?

4

Also, I just conducted a test on a lab server where I enabled Access Control, but this time using HTTP instead of HTTPS. Interestingly, I encountered the same error as before. This leads me to believe that the issue might not be related to the SSL Certificate after all. Given that we’re operating within a private network, could there be a network-specific factor contributing to this problem? It’s puzzling that the site remains accessible when access control is disabled, yet becomes unreachable once it’s enabled. Any insights or suggestions on this would be greatly appreciated. Thank you!

5

Oh, I missed to bring that into context, sorry. I thought that the site still remains unaccessible after reverting the changes.

I don’t think that TLS/SSL is the problem here, but would like to understand more what’s happening here.

Can you check the pages log and see if the timestamp for accessing the website can be correlated to a log entry?

I also searched Google for the problem using the term gitlab pages access control not working and found some bugs, maybe they are related to the problem.

1 Like