Nginx misconfiguration then?
sudo nginx -T
Nginx misconfiguration then?
sudo nginx -T
OR
they are two different systems.
I'm actually confused haha. Do you guys want the nginx config?
Yeah. That would help. Putting a test file maybe moreso.
curl -Iki4 alkarkhi.com
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 10 Jul 2021 16:58:15 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://www.alkarkhi.com/
curl -Iki6 alkarkhi.com
HTTP/1.1 403 Forbidden
Connection: close
Content-Type: text/html
Cache-Control: no-cache
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: frame-ancestors 'self'
Content-Length: 3444
Those two should be the exact same thing.
That's very true. I see what you mean, @rg305. We need to determine if it's the same system.
Can you create a file named test
in your webroot directory containing 1234
.
If @rg305 can curl the test
file on both systems (and hopefully get a 200 back), we will have a match. If not, could be configuration or two different systems.
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name it-does-not-matter;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/letsencrypt/live/alkarkhi.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/alkarkhi.com/privkey.pem;
server_name alkarkhi.com 51.195.152.242 2001:41d0:0800:2e90:6d72:2ffb:8267:0001;
return 301 https://www.$server_name$request_uri;
}
server {
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/letsencrypt/live/alkarkhi.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/alkarkhi.com/privkey.pem;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html index.php;
server_name www.alkarkhi.com;
location / {
if ($request_uri ~ "/index.html" ) {
rewrite ^(.*)/ $1/ permanent;
}
if ($request_uri ~ ^/(.*)\.html) {
return 301 /$1$is_args$args;
}
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri.html $uri/ =404;
}
error_page 404 /custom_404.html;
location = /custom_404.html {
root /usr/share/nginx/html;
internal;
}
# pass PHP scripts to FastCGI server
#
location ~ \.php$ {
include snippets/fastcgi-php.conf;
# With php-fpm (or other unix sockets):
fastcgi_pass unix:/run/php/php7.3-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
if ($request_uri ~ ^/(.*)\.php) {
return 301 /$1$is_args$args;
}
}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
deny all;
}
}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
# listen 80;
# listen [::]:80;
#
# server_name example.com;
#
# root /var/www/example.com;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}
And to undo a bad deletion too - lol
The first section seems to clash when "www" is used - by always adding another "www" to that.
server_name alkarkhi.com www.alkarkhi.com 51.195.152.242 2001:41d0:0800:2e90:6d72:2ffb:8267:0001;
return 301 https://www.$server_name$request_uri;
Otherwise I can't see wht they don't serve the same thing(s).
Since the (only) HTTP vhost is defined as the default, then you really don't need to match the server_name at all.
You can change:
server_name alkarkhi.com www.alkarkhi.com 51.195.152.242 2001:41d0:0800:2e90:6d72:2ffb:8267:0001;
To:
server_name it-does-not-matter;
But you will then need to change:
return 301 https://www.$server_name$request_uri;
To:
return 301 https://$host$request_uri;
[and get a cert with both names on it - and then redirect from HTTPS to HTTPS://www]
[note: if you don't include both names on the cert, you can't accept HTTPS to both names]
I see that you have obtained several wildcard certs in the past...
Did you have to do them all manually?
[edit] please show the cert now in use with:
certbot certificates
server_name it-does-not-matter;
As in literally?
I guess so. Most of these were only test certificates when I didn't know letsencrypt had a rate-limit
Found the following certs:
Certificate Name: alkarkhi.com
Serial Number: 38cbc14f197af2e8760761c980f49105e00
Key Type: RSA
Domains: alkarkhi.com *.alkarkhi.com
Expiry Date: 2021-10-08 11:06:04+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/alkarkhi.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/alkarkhi.com/privkey.pem
btw the 89 days it because I renewed manually today
I edited the nginx config. Can someone verify if its right
Yes, any string will do.
Like:
server_name _;
Excellent!
You already have a wildcard cert; did you have to obtain it manually?
EDIT: Unfortunately, you had to renew it manually - we need to automate this (once and for all).
IPv6 continues to show a different reply:
curl -Iki6 alkarkhi.com
HTTP/1.1 403 Forbidden
Connection: close
Content-Type: text/html
Cache-Control: no-cache
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: frame-ancestors 'self'
Content-Length: 3592
And when you didn't/don't know LE has a test/staging system for this very purpose.
Do they actually? Where?
For example:
sudo certbot certonly --cert-name alkarkhi.com --nginx -d "alkarkhi.com,www.alkarkhi.com" --dry-run
The --dry-run
causes certbot to use the staging environment.
The certonly
command is included because --dry-run
doesn't work with the run
command (ridiculous, I know) with run
being the default command when no other command is specified.
Do you actually need a wildcard certificate for your purposes? In the many hundreds of help cases that I've worked, I've found that almost no one actually needs a wildcard certificate based upon their circumstances. Wildcard certificates often require more work to maintain (as you can tell), can present security concerns, and reasonably offer no additional security over a non-wildcard certificate.