0

I'm trying to redirect my domain to another domain but keeping my domain in the URL.

This is my settings:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name example.com;
    root /home/redacted/redacted/wwwdir;

    # SSL
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # reverse proxy
    location / {
        proxy_pass https://example2.com/ID/;
    }

    # Block google
    location = /robots.txt {
        add_header Content-Type text/plain;
        return 200 "User-agent: *\nDisallow: /\n";
    }

}


# HTTP redirect
server {
    listen 80;
    listen [::]:80;

    server_name .example.com;

    location / {
        return 301 https://example.com$request_uri;
    }
}

But I'm seeing errors like this in my logs:

2019/05/31 18:35:48 [crit] 14831#14831: *2415 SSL_do_handshake() failed (SSL: error:14090072:SSL routines:SSL3_GET_SERVER_CERTIFICATE:bad message type) while SSL handshaking to upstream, client: IP, server: example.com, request: "GET /templates/js/jquery.nestable.js HTTP/1.1", upstream: "https://IP:443/ID/templates/js/jquery.nestable.js", host: "example.com", referrer: "https://example.com/admin/index.php"

I think the issue here is upstream:"https://IP:443/ID/templates/js/jquery.nestable.js"

Why is using IP:443 here?

  • Because port 443 is the default port for https. That doesn't matter though. It is not causing you any problem. – Michael Hampton Jun 1 at 1:29
  • What do you mean is not causing any problem? I assume that whatever was trying to fetch that .js script will fail – Freedo Jun 1 at 1:30
  • @MichaelHampton What do you mean is not causing any problem? I assume that whatever was trying to fetch that .js script will fail. From what I know is not possible to have a valid certificate for a IP, so how do you think ip:443 would pass a handshake? – Freedo Jun 1 at 1:39
  • It's not trying to make an HTTPS connection by IP address, so that's irrelevant. You specified a hostname. Unless of course the configuration you posted is not what you are actually using. – Michael Hampton Jun 1 at 2:43
  • @MichaelHampton so why it's giving that error? – Freedo Jun 1 at 3:21
0

When connecting to a backend/upstream using https, Nginx defaults to using client certificate authentication: it expects you to give it a certificate that has been signed by your upstream certificate (see https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/).

As far as I understand this is not what you want; you only want to secure the communication between Nginx and the upstream, not authenticate/authorize it.

I had the same issue a while ago; if I remember correctly, adding proxy_ssl_verify off; next to the proxy_pass ... directive fixed it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.