Redirect to sonarqube on http after Gitlab Authentication

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


  • 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:

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_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?

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.

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


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.