Port Forwarding and SSL


#21

That 301 error means that NGinx is redirecting, but cannot access the the backend, ie, Seafile. When you made the changes to the port, did you also change your service_url and file_server_root inside Seafile to reflect the port number 3002?


#22

I meant this, I just didn’t take the right words.


#23

Actually, I didn’t see your post until after I had posted mine, so we were both thinking the same thing. :slight_smile:


#24

@Daniel_BlahBla

I just remembered that you are using a CNAME record and not an A record. When you initiated the request with Letsencrypt for a certificate, did you use the CNAME for the registration?


#25

FILE_SERVER_ROOT = ‘https://XXX:3002/seafhttp’;
SERVICE_URL = https://XXX:3002

I have used my domain for the letsencrypt certificate request.
Have used this command:
certbot certonly --rsa-key-size 4096 --webroot -w /var/www/XXX -d XXX.de -d cloud.XXX.de

My complete config now:

server {
    listen       3001;
    server_name  XXX;
    rewrite ^ https://$http_host:3002$request_uri? permanent;    # force redirect http to https
    server_tokens off;
    add_header test_uri "$http_host";
}
    server {
        listen 3002;
        ssl on;
        ssl_certificate /etc/letsencrypt/live/XXX/fullchain.pem;        # path to your cacert.pem
        ssl_certificate_key /etc/letsencrypt/live/XXX/privkey.pem;    # path to your privkey.pem
        server_name XXX;

        # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
        ssl_dhparam /etc/nginx/dhparam.pem;

        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
        proxy_set_header X-Forwarded-For $remote_addr;

   location / {
         proxy_pass         http://127.0.0.1:8000;
         proxy_set_header   Host $host:$server_port;
         proxy_set_header   X-Real-IP $remote_addr;
         proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header   X-Forwarded-Host $server_name;
         proxy_read_timeout  1200s;

         # used for view/edit office file via Office Online Server
         client_max_body_size 0;

         access_log      /var/log/nginx/seahub.access.log;
         error_log       /var/log/nginx/seahub.error.log;
    }

    location /seafhttp {
        rewrite ^/seafhttp(.*)$ $1 break;
        proxy_pass http://127.0.0.1:8082;
        client_max_body_size 0;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
        proxy_send_timeout  36000s;

        send_timeout  36000s;
    }

    location /media {
        root /home/sfadmin/seafile-server-latest/seahub;
    }

    location /.well-known/acme-challenge/ {
        alias /var/www/XXX/.well-known/acme-challenge/;
    }
}

Still no luck :confused:


#26

Seems to be something with your acme service. Can you post the log of it?


#27

Sorry for the delay… My power went out briefly.

I agree with @bionade24. Something is wrong with your certificate. If you are using a CNAME, here are the rules for proper SSL configuration.

  • The certificate must be issued for the CNAME, not the primary domain.
  • You can’t run two certs on the same IP address… ie, if you have certificate for the primary name and CNAME, unless your certifcate(s) have support for SNI.
  • Nginx requires that you bundle the crt files into one file. Letsencrypt has a method for you to do that with NGinx. Otherwise, you’ll need to concatenate them yourself.

#28

[quote=“wthess, post:27, topic:6160”]
You can’t run two certs on the same IP address…
Really ? I thought that would work.


#29

@Daniel_BlahBla

Visit this web page. This is perhaps the best SSL troubleshooter I’ve seen.

https://www.sslshopper.com/ssl-checker.html


#30

According to the NGinx docs, not with a CNAME, you cannot. Albeit, it’s been a while since I’ve visited the NGinx docs, so they could have a way of doing it now.

For example:
mydomain.com (Primary)
mysubdomain.com (CNAME to mydomain.com)
SSL cert for mydomain.com
SSL cert for mysubdomain.com.

The problem, as I understand it, is since both are on the same IP address, but you have two domains pointing to the same IP, the certs get confused somehow. I would have to go back and dig up the info on it. It’s been a while since I last researched it, maybe 5 or 6 years.


#31

Needed to log in with a new account(new member max post limit reached)
Somehow I got it now working to access it over this direct address:

https://cloud.XXX.de:3002

So it is working when i directly use the https prefix and the https port number. But the rewrite from http://cloud.XXX.de:3001 is still not working correctly. SSL Hopper is also reporting this on the http route. When I use the address above SSL Hopper reports everything seems fine


#32

Ok :sweat_smile:, then that would be nerver a problem for because I want to sign subdomains.


#33

So maybe it’s caused by the fritzbox who doesn’t allow the redirects.


#34

I just revisited it. Contacted my certificate provider. 2 certs on the same IP would still require SNI, according to them.


#35

So, it’s working, but the rewrite isn’t?


#36

But with cetbot I could use mail.xxx.de imap.xxx.de and xxx.de without problems. For the rest I will see next week, but that’s nothing related to seafuile Thank you for asking.


#37

Yes seems so. Can visit via https prefix + https port. When using http prefix + port i got the ssl error over and over again


#38

That’s not the same thing. I’m talking about the domains, not subdomains. What I’m talking about is getting a certificate for mydomain.com (top level), and one for mycnamedomain.com (which points to mydomain.com).

Certs are issued for the top level domain, which is tied to a single IP address. SNI will allow something like that, though I can’t purport to know that much about SNI. I just know that SNI is required in the cert to pull it off.


#39

Ok thank you


#40

Ok… NGinx has a command for rewrites on alternate ports. Here it is. I don’t think you’ll even need a 3001 block with this. It goes in the SSL listen port directive.

error_page 497 https://$host:3002$request_uri;

I can’t guarantee this will work as I’ve not tried it. I just found it in a search where someone else was having the same problem you are and it apparently worked for them.