nginx: ssl verification failed + wrong redirect

Amedee Van Gasse asked:

This is my current nginx config:

$ cat /etc/nginx/sites-enabled/bitbucket

server {
        listen 80 default_server;
        listen [::]:80 default_server;


        return 302$request_uri;

server {
        listen 443 ssl default_server;

        server_tokens off;
        add_header Strict-Transport-Security "max-age=31536000";

        access_log  /var/log/nginx/bitbucket_access.log;
        error_log   /var/log/nginx/bitbucket_error.log;

        ssl on;
        ssl_certificate /etc/ssl/private/ssl-itextsupport.pem;
        ssl_certificate_key /etc/ssl/private/ssl-itextsupport.key;

        location / {
                proxy_pass http://localhost:7990/;
                proxy_set_header        Host $host;
                proxy_set_header        X-Forwarded-Host $host;
                proxy_set_header        X-Forwarded-Server $host;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        X-Real-IP $remote_addr;
                proxy_redirect          off;

http redirect to git is OK in a console:

$ curl -I                                                                                                                                                                                                    10:09  amedee@iTextQA
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Tue, 15 Nov 2016 13:15:50 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive

But in Chrome it redirects to Browser cache is already cleared and disabled while DevTools is open. Suggestions to NUKE the Chrome redirect cache are welcome, but that is not my question.

The above redirect is also OK for and Again, not working in Chrome, but that is not my question.

Next step: testing https redirect.

$ curl -I                                                                                                                                                                                                 curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here:

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

I add -k as suggested:

$ curl -I -k                                                                                                                                                                                              HTTP/1.1 302 Found
Server: nginx
Date: Tue, 15 Nov 2016 13:31:56 GMT
Connection: keep-alive
X-AREQUESTID: @PT467Wx871x701860x0
X-ASEN: SEN-L8781032
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
Content-Language: en-US
Strict-Transport-Security: max-age=31536000

My two questions:

  1. Why does SSL verification fail? I verified /etc/ssl/private/ssl-itextsupport.{pem,key}, they are the exact files as provided by our hosting company and as they are used on other servers, where https works. It fails on the console and in the browser.
  2. Why does https get redirected to the gitlab subdomain instead of the git subdomain? I grepped all of the server, and I can’t find any relevant nginx config that might be responsible.

My answer:

Your web application sent the second redirect. Check its config to make sure it knows what domain it is supposed to be serving.

Curl doesn’t like the SSL certificate because you didn’t install the intermediate certificate.

View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.