I am using laradock to configure HTTPS for two domains, which are different sub domains under the same top-level domain, a.test.com and b. test.com. I encountered a.test.com, which was successfully configured and had no access issues. However, b. test.com did not have HTTPS configured. My browser access https://b.test.com But it will parse the project code to a.test.com. If I open the SSL configuration of b. test.com, nginx will report an error.
Here is the nginx configuration:
nginx.conf
user www-data;
worker_processes 4;
pid /run/nginx.pid;
daemon off;
events {
worker_connections 2048;
multi_accept on;
use epoll;
}
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 15;
types_hash_max_size 2048;
client_max_body_size 20M;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /dev/stdout;
error_log /dev/stderr;
gzip on;
gzip_disable "msie6";
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-available/*.conf;
open_file_cache off; # Disabled for issue 619
charset UTF-8;
}
The following is the domain name configuration for nginx:
a.test.com
server {
listen 80;
server_name a.test.com;
return 301 https://a.test.com$request_uri;
}
server {
listen 80;
listen [::]:80;
# For https
listen 443 ssl;
listen [::]:443 ssl ipv6only=on;
ssl_certificate /etc/nginx/ssl/a.test.com.pem;
ssl_certificate_key /etc/nginx/ssl/a.test.com.key;
server_name a.test.com;
root /var/www/a-test/public;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
location ~ \.php$ {
try_files $uri /index.php =404;
fastcgi_pass php-upstream;
fastcgi_index index.php;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#fixes timeouts
fastcgi_read_timeout 600;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
location /.well-known/acme-challenge/ {
root /var/www/letsencrypt/;
log_not_found off;
}
error_log /var/log/nginx/laravel_error.log;
access_log /var/log/nginx/laravel_access.log;
}
b.test.com
#server {
# listen 80;
# server_name b.test.com;
# return 301 https://b.test.com$request_uri;
#}
server {
listen 80;
listen [::]:80;
# For https
#listen 443 ssl;
#listen [::]:443 ssl ipv6only=on;
#ssl_certificate /etc/nginx/ssl/b.test.com.pem;
#ssl_certificate_key /etc/nginx/ssl/b.test.com.key;
server_name b.test.com;
root /var/www/b-test/public;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
location ~ \.php$ {
try_files $uri /index.php =404;
fastcgi_pass php-upstream;
fastcgi_index index.php;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#fixes timeouts
fastcgi_read_timeout 600;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
location /.well-known/acme-challenge/ {
root /var/www/letsencrypt/;
log_not_found off;
}
error_log /var/log/nginx/laravel_error.log;
access_log /var/log/nginx/laravel_access.log;
}
If I open the SSL related configuration of b. test.com, the following error will occur:
2023/11/17 02:26:07 [warn] 9#9: conflicting server name "a.test.com" on 0.0.0.0:80, ignored
2023/11/17 02:28:25 [emerg] 9#9: duplicate listen options for [::]:443 in /etc/nginx/sites-available/a.test.com.conf:14
When configured as above, access https://b.test.com Can I successfully access it, but the project code pointing to a.test.com should not be inaccessible