Redirect to sonarqube on http after Gitlab Authentication

SonarQube Server / Community Build
1

SonarQube Developer Edition 8.5.1 incl. Nginx Version 1.18 for SSL termination under RHEL 7.8, integrated with
GitLab 13 with self signed certificate

sonarqube base url: https:\sonarcube.customer.lan
Gitlab base url: https:\gitlab.customer.lan
Gitlab SSL certificate is imported into SQ keystore

Behavior:

  • SonarQube Login Page via https (OK)
  • login via Gitlab via https (OK)
  • Authentfication on SQ (OK)
  • Redirect to SQ , but on http instead of https:
    image
    image1451×740 236 KB

see our Nginx config file:
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl;
ssl_certificate /etc/nginx/sonarqube.customer.lan.crt;
ssl_certificate_key /etc/nginx/prodPrivate.key;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ‘ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA’;
ssl_session_timeout 1d;

location / {
proxy_pass http://sonarqube.customer.lan:9000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto https;
}
}

after that wrong http redirect: if I navigate to https:\sonarqube.customer.lan in my browser, it shows that the user has been logged into SQ successfully.

Any ideas?

2

Hello @Stephan_Krause,
This issue is more of a Nginx configuration issue than a SonarQube configuration one. I suggest you to have a look at the example we give in the documentation but we will not provide more help on the configuration of your proxy. This being a third party tool we do not provide support on it.
Alex.

3

@Stephan_Krause I’m facing the same issue, and was unable yet to resolve it. Any clue would be appreciated.

Rgds

4

I think we were seeing the same issue and have been able to solve it, or at least work around it.

TL;DR: Use this in your nginx config:

proxy_redirect http://$host https://$host;

We are using SAML for authentication with our SQ 8.8 instance. The issue we saw was that the POST request to the callback url (https://<sonar-url>/oauth2/callback/saml) was answered with a 302 redirect to http://<sonar-url>/<the-rest>.

So we went digging. The issue, I think, is that the construction of the redirect URL is mostly handled by Catalina, which, unlike SonarQube, does not handle the X-Forwarded-Proto header, but instead just copies the scheme from the request (see org.apache.catalina.connector.Response#toAbsolute. callchain starts at org.sonar.server.authentication.OAuth2ContextFactory.OAuthContextImpl#redirectToRequestedPage).

The solution was, as described in the TL;DR above, to rewrite all redirect locations to SQ with nginx to use https instead. See also Module ngx_http_proxy_module.

Not sure if this can be classified as a bug in SQ, or Catalina, or anywhere.