System Information
I’m running Docker and Nginx on Debian Buster. I set up my Seafile server on Docker and I’m using system Nginx as a reverse proxy. My Seafile instance is available locally and at seafile.***.com.
The Problem
I can connect to my public link with my browser and my iOS Seafile Pro app; however, my desktop syncing client for Mac cannot connect to my public link. It says “Network Error: SSL handshake failed”. When I try with my local link, it works without error. This leads me to believe that I misconfigured my system Nginx for Seafile.
Here is my Nginx configuration:
server {
listen 80;
listen [::]:80;
server_name seafile.***.com;
server_tokens off;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name seafile.***.com;
server_tokens off;
ssl_certificate /etc/letsencrypt/live/seafile.***.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/seafile.***.com/privkey.pem;
ssl_session_timeout 5m;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
ssl_session_tickets off;
# modern configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
# HSTS (ngx_http_headers_module is required) (63072000 seconds)
add_header Strict-Transport-Security "max-age=63072000" always;
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
# verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /etc/letsencrypt/live/seafile.***.com/chain.pem;
location / {
proxy_pass http://127.0.0.1:5080;
proxy_set_header Host $host;
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_set_header X-Forwarded-Proto https;
access_log /var/log/nginx/seahub.access.log;
error_log /var/log/nginx/seahub.error.log;
proxy_read_timeout 1200s;
client_max_body_size 0;
}
}
Things I Have Tried
Previously, I only allowed TLSv1.3. However, when I read that the Mac client had some issues with TLSv1.3, I updated my configuration to allow TLSv1.2. I also saw that the Mac client was updated to support TLSv1.3, but I saw this thread arguing the contrary and became confused.
Anyways, I’m not sure what the issue is. I tried changing several things about this configuration, but none of them have fixed the issue. I looked through my Nginx access and error logs for Seafile, but I couldn’t find any logs regarding my Mac client. I looked through general Nginx error logs and was also unable to find relevant errors. If it would help, I can post my Nginx access logs for Seafile. The Nginx logs within Seafile on Docker might also be useful, but I’m not sure how to access them.
Other Information
While I’m at it, I’m going to post my Docker Compose file for reference:
version: "3.7"
services:
db:
image: mariadb
restart: always
volumes:
- ./data/db:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=*****
- MYSQL_LOG_CONSOLE=true
memcached:
image: memcached
restart: always
entrypoint: memcached -m 256
elasticsearch:
image: seafileltd/elasticsearch-with-ik:5.6.16
restart: always
ulimits:
memlock:
soft: -1
hard: -1
mem_limit: 2g
volumes:
- ./data/elasticsearch:/usr/share/elasticsearch/data
environment:
- discovery.type=single-node
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms1g -Xmx1g"
app:
image: docker.seadrive.org/seafileltd/seafile-pro-mc
restart: always
ports: [5080:80]
volumes:
- ./data/seafile:/shared
environment:
- TIME_ZONE=America/New_York
- DB_HOST=db
- DB_ROOT_PASSWD=*****
- SEAFILE_ADMIN_EMAIL=***@***.com
- SEAFILE_ADMIN_PASSWORD=*****
- SEAFILE_SERVER_LETSENCRYPT=false
- SEAFILE_SERVER_HOSTNAME=seafile.***.com
depends_on: [db, memcached, elasticsearch]
I looked through several threads on this forum and some recommended to change SERVICE_URL and FILE_SERVER_ROOT. I changed these links on my admin portal from HTTP to HTTPS. I’m not sure how much of a difference that will make, but I just wanted to mention that beforehand.