Timeout from newkey page when applying net ssl key pair

SYSTEM INFORMATION
OS type and version Debian GNU/Linux 12 (bookworm)
Webmin version 2.402
Virtualmin version 7.30.8 Pro
Webserver version Apache/2.4.62 (Debian)
Related packages SUGGESTED

For a long time the renew letsencrypt function has not worked for WordPress sites. I have consequently used certbot command and uploaded the certs using the “Setup SSL Certificate/Update Certificate and Key” function.
But the last month app. the “Install Now” function has returned timeout from the newkey page.
So now I also have to use cp and restart apache2 to renew certs.

Where to look for what in order to debug and correct this problem?

Thanks in advance.

/ Harald

You presumably have some extra redirects or proxy rules in your .htaccess, maybe added by a plugin or maybe by a changed WordPress configuration option, I dunno. All redirects and proxy rules need to exclude .well-known.

To debug problems you need to look at the actual errors, and post them here if you don’t know what they mean. I’m just guessing, because you haven’t told us what actually happened or the exact/complete error when trying to renew a cert in Virtualmin.

Thank you for your swift reply. I described 2 problems, but I only want help/ideas to the second:
When I have uploaded new cert and key for a site and click “Install Now” on the “Update Certificate and Key” page, I get a timeout error from the “newkey” page.
This has only happened app. the last month, before that it works perfekt.
Only changes on the system are running updates from debian and webmin/virtualmin.
My question is where to look / how to debug that error i.e. which logfile?
The site logs shows nothing.

Are you logged into Webmin on the domain name you are replacing the cert for? Webmin has to restart when that happens, because it will serve the cert for the domain you’re contacting it on, and the TLS connection needs to be built up again.

Generally, renewals are done automatically, so that doesn’t matter. But, if you’re doing it manually, you’d want to connect using a different domain.

I do log in from another domain.
And as I wrote I has worked fine until 1-2 month ago.
I do not know, where virtualmin admin errors are logged?

And the timeout error message is shown only a few seconds, so I cannot screen dump it.

In the Webmin logs in /var/webmin.

If it’s something related to the connection as I suspect, it might show up in the browser web developer console.

No help in miniserv.log:
…32 - root [22/Jul/2025:07:55:57 +0200] “POST /virtual-server/newkey.cgi HTTP/1.1” 200 1518

Sorry here is a little more with a 400 error ?
10.9.10.32 - root [22/Jul/2025:07:54:26 +0200] “POST /virtual-server/cert_form.cgi?dom=15485198856582 HTTP/1.1” 200 42114
10.9.10.32 - root [22/Jul/2025:07:55:57 +0200] “POST /virtual-server/newkey.cgi HTTP/1.1” 400 1518
10.9.10.32 - root [22/Jul/2025:07:55:57 +0200] “POST /virtual-server/newkey.cgi HTTP/1.1” 200 1518
10.9.10.32 - root [22/Jul/2025:07:56:24 +0200] “POST /virtual-server/move_form.cgi?dom=15485198856582 HTTP/1.1” 200 6991
10.9.10.32 - root [22/Jul/2025:07:56:27 +0200] “POST /virtual-server/cert_form.cgi?dom=15485198856582 HTTP/1.1” 200 42107
10.9.10.32 - root [22/Jul/2025:07:57:33 +0200] “POST /apache/virt_index.cgi?virt=mieeje.dk:443 HTTP/1.1” 200 13066

There are other logs. miniserv.error is where I would look for errors.

But, I think the 400 is probably Webmin in the middle of a restart. Connection got mangled. I thought it would usually handle stuff like this correctly, but maybe not in this specific case (I know you can manually renew a Let’s Encrypt cert without issue, even though that also involves restarting Webmin).

Maybe restarting is just really slow for some reason on your system. Try restarting the webmin service on the command line. It should be pretty much instant, at least in terms of beginning to answer requests again…it will preload some libs that take another half second or whatever.

miniserv.error:
[22/Jul/2025:07:55:57 +0200] [10.9.10.32] /virtual-server/newkey.cgi : Timeout : Waited more than 60 seconds for request data

root@tine:~# date; systemctl restart webmin.service ; date
Tue 22 Jul 09:58:17 CEST 2025
Tue 22 Jul 09:58:20 CEST 2025
root@tine:~#

That’s the browser request not completing for some reason. I don’t know what to make of that.

Is there something weird about your network or connection? Are you running through Cloudflare or some other proxy?

Not to my knowledge. And as mensioned it worked for years up until a couple of month ago.
And no known network changes. network is an ordinary c-addr on a Mikrotik router.
I do manage by using certbot with dns verification followed by copying cert and key to homedir ssl.* and restarting apache2.
One day, when I have to upgrade debian 12 to 13, I might create a new server with a fresh install of virtualmin and migrate the sites. Maybe that will fix the problem.
So don’t spent too much time on it.
Thank you so far.

For your info:
oot@tine:~# ip r
default via 10.9.10.1 dev ens18 onlink
10.8.0.0/24 via 10.8.0.97 dev tun0
10.8.0.97 dev tun0 proto kernel scope link src 10.8.0.98
10.9.10.0/24 dev ens18 proto kernel scope link src 10.9.10.54
root@tine:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether e2:3b:f7:42:bb:b1 brd ff:ff:ff:ff:ff:ff
altname enp0s18
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
link/none
root@tine:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether e2:3b:f7:42:bb:b1 brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 10.9.10.54/24 brd 10.9.10.255 scope global ens18
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 10.8.0.98 peer 10.8.0.97/32 scope global tun0
valid_lft forever preferred_lft forever
root@tine:~#

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.