Let's Encrypt Failing on one new virtual domain

Yes, if your web server is Nginx, otherwise Apache.

looks like HTTP based validation can only be done if DNS is being managed externally (disabling DNS domain feature)

maybe someone can guide if that can be done without disabling the DNS feature.

Or if you need this to be done urgently you can request ssl outside virtualmin using cli

sudo certbot certonly --nginx --preferred-challenges http -d example.com
vim /etc/letsencrypt/live/example.com

and install ssl certs under “Update Certificate and Key” feature

Nginx

server {
	server_name *****.com www.*****.com;
	listen xxx.xxx.xxx.xxx;
	root /home/*****/public_html;
	index index.php index.htm index.html;
	access_log /var/log/virtualmin/*****.com_access_log;
	error_log /var/log/virtualmin/*****.com_error_log;
	fastcgi_param GATEWAY_INTERFACE CGI/1.1;
	fastcgi_param SERVER_SOFTWARE nginx;
	fastcgi_param QUERY_STRING $query_string;
	fastcgi_param REQUEST_METHOD $request_method;
	fastcgi_param CONTENT_TYPE $content_type;
	fastcgi_param CONTENT_LENGTH $content_length;
	fastcgi_param SCRIPT_FILENAME "/home/*****/public_html$fastcgi_script_name";
	fastcgi_param SCRIPT_NAME $fastcgi_script_name;
	fastcgi_param REQUEST_URI $request_uri;
	fastcgi_param DOCUMENT_URI $document_uri;
	fastcgi_param DOCUMENT_ROOT /home/*****/public_html;
	fastcgi_param SERVER_PROTOCOL $server_protocol;
	fastcgi_param REMOTE_ADDR $remote_addr;
	fastcgi_param REMOTE_PORT $remote_port;
	fastcgi_param SERVER_ADDR $server_addr;
	fastcgi_param SERVER_PORT $server_port;
	fastcgi_param SERVER_NAME $server_name;
	fastcgi_param PATH_INFO $fastcgi_path_info;
	fastcgi_param HTTPS $https;
	location ^~ /.well-known/ {
		try_files $uri /;
	}
	location ~ "\.php(/|$)" {
		try_files $uri $fastcgi_script_name =404;
		default_type application/x-httpd-php;
		fastcgi_pass unix:/var/php-nginx/1667404056106520.sock/socket;
	}
	fastcgi_split_path_info "^(.+\.php)(/.+)$";
	location /cgi-bin/ {
		gzip off;
		root /home/*****/cgi-bin;
		fastcgi_pass unix:/var/fcgiwrap/1667404056106520.sock/socket;
		fastcgi_param SCRIPT_FILENAME "/home/*****$fastcgi_script_name";
		fastcgi_param GATEWAY_INTERFACE CGI/1.1;
		fastcgi_param SERVER_SOFTWARE nginx;
		fastcgi_param QUERY_STRING $query_string;
		fastcgi_param REQUEST_METHOD $request_method;
		fastcgi_param CONTENT_TYPE $content_type;
		fastcgi_param CONTENT_LENGTH $content_length;
		fastcgi_param SCRIPT_NAME $fastcgi_script_name;
		fastcgi_param REQUEST_URI $request_uri;
		fastcgi_param DOCUMENT_URI $document_uri;
		fastcgi_param DOCUMENT_ROOT /home/*****/public_html;
		fastcgi_param SERVER_PROTOCOL $server_protocol;
		fastcgi_param REMOTE_ADDR $remote_addr;
		fastcgi_param REMOTE_PORT $remote_port;
		fastcgi_param SERVER_ADDR $server_addr;
		fastcgi_param SERVER_PORT $server_port;
		fastcgi_param SERVER_NAME $server_name;
		fastcgi_param PATH_INFO $fastcgi_path_info;
		fastcgi_param HTTPS $https;
	}
	listen xxx.xxx.xxx.xxx:443 ssl;
	ssl_certificate /etc/ssl/virtualmin/1667404056106520/ssl.cert;
	ssl_certificate_key /etc/ssl/virtualmin/1667404056106520/ssl.key;
	if ($scheme = http) {
		rewrite "^\Q^/(?!.well-known)(.*)$\E(.*)" "https://%{HTTP_HOST}/$1$1" break;
	}
}

I hope that means more to you than me. Only edited to remove IP and domain name. It is a lot more than I’m used to seeing.

It seems not:
“The requested nginx plugin does not appear to be installed”

No. That is not accurate. Web validation is the default validation method and happens first. DNS is only required if wildcard certs are being generated (and, most people shouldn’t use wildcards), or if web validation failed. Solving why web validation failed is the goal in nearly all cases.

@Jamie we are adding incorrect SSL redirect, and it not only doesn’t work but also is not getting detected on Servers ⇟ Nginx Webserver: Website Options page.

1 Like

What’s wrong with that redirect regular expression?

OK, having slept on it (nightmares more like) I come back to this nginx config.
As I said much more than I’m used to.
How much of it is a requirement to enable Virtualmin/Webmin to work?

The sites to be operated here are not php sites (I retired php 25 years ago!) the sites all use Pascal or Nodejs (mostly Nodejs) and so the .conf “location” is usually just a simple reverse proxy - a mere 8 lines of code no “fastcgi”

Obviously I don’t want to break Virtualmin or is everyone else on Virtualmin only a php user? I do seem at odds here by not using Apache

It seems double escaped. It should be:

rewrite "^/(?!.well-known)(.*)" "https://$host/$1" break;

Cannot say exactly. I would assume that leaving server_name, listen, root and access_log and error_log should be enough. Also, for SSL to work you would need ssl_certificate and ssl_certificate_key. I don’t think it’s worth making any manual changes. Virtualmin Pro can handle proxies for you as well. Just go for it.

1 Like

I have never had these in any .conf before as running certbot usually adds its own “managed by Let’s Encrypt” sections to cover this. I Don’t usually like tinkering under the hood but as I have already broken this domain and its website, short of abandoning Virtualmin on this one and building a new droplet to return the old site to live status from a backup I’m beginning to lose faith and run out of options.
The other domains on this box still work well under Virtualmin. (they are all nginx) So it is just this one for some reason.

@Jamie, it was fixed here:

As this is still killing me - for the umpteenth time I deleted the virtual server (from the menu) to start afresh - this time,

even the delete produced errors:
everything OK up to
Applying Nginx configuration 


configuration is invalid : nginx: [emerg] cannot load certificate "/etc/ssl/virtualmin/1667404056106520/ssl.cert": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/ssl/virtualmin/1667404056106520/ssl.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file) nginx: configuration file /etc/nginx/nginx.conf test failed

if it was then why is it still being added to the nginx conf ? on Virtualmin version 7.3-1

You could get bogged down in why if it was fixed, etc. Or you could overwrite the incorrect line with the correct (expected) line in the config and see how you get on?

Neither replacing it with that line nor removing it completely or indeed removing the whole section of the nginx conf seems to have any effect. Just like deleting the virtual domain and then adding it again had no effect until today when I got the above error. There is something really going wrong here.

The only positive is that the other virtual domains still seem to be working.

This week will see me firing up a new box and moving the troublesome domain to that box. Then I give up and reinstall the original pascal box (this domain has been offline now for a week.

The change made (I think) is to the file at the following location:

/usr/share/webmin/virtualmin-nginx/virtual_feature.pl

Get a copy of yours and compare it to the “file” at

and see if you see differences as shown at

If there are differences (the lines nbrs may be slightly different, but the blocks of code changed will be the same) - make a copy of the existing one (to another name) & overwrite the contents of the existing one [wouldn’t expect to have to deal with file permissions\ownership this way].

Worth a go I suppose.

If there are no differences then it’s out of my wheelhouse.

@Dibs
Thanks very much for the suggestion.
I’m afraid I have never been a great fan of Git and frankly too long in the tooth to bother learning how to use it.
I’m also very nervous of breaking other folks code by adding my 5c worth.

Anyway - this morning I fired up a new project on DO with a brand new droplet/box. loaded up Virtualmin (LEMP build of course) assigned a new domain as host domain and checked that works (as expected) the host domain acquired its SSL from Let’s Encrypt. No errors.

So added the old troublesome domain and NO!! once again it fails just as before same error messages as first post.

What is it about this domain name ?

So to test that theory again I added another domain as a virtual server and that worked OK. Let’s Encrypt gave me a certificate and the default Virtualmin page is displayed.

That feeling of dropping down a worm hole is back! :worm: :hole:

I wonder if you’ve exceeded the nbr of tries for cert at LE. I think there is a limit to how many tries in X days it will allow for a given list of host names.

What’s the host names in the list - on the LE Cert tab (for the troublesome domain)?

Just the anoyingdomain.com and www.anoyingdomain.com

Although you may be right about Let’s Encrypt blocking number of attempts NOW but why did it happen back on Nov 1 - the site has been running for years with just the regular update request on expiry it only started to go wrong when I took over admin and moved it to new DO droplet as a Virtualmin virtual server.

What if you change the list to just

www.anoyingdomain.com

and see if it will issue just for that?