Letsencrypt ssl.cert/key in /etc/webmin not in /home/user

Help! (Home for newbies)
1

Hi, I am new to virtualmin. I read a lot of posts and searched the forum but didnt found a solution.

I have a https website with self signed certificats up and running.
Now I want to use letsencrypt certificates.
Go to “Virtualmin -> Server configuration -> SSL Certificate -> Lets encrypt” and Request certificate:

Requesting a certificate for www.some-domain.de, some-domain.de from Let's Encrypt .. .. request was successful!

Configuring webserver to use new certificate and key …
… done

Applying web server configuration …
… done

Everything seems fine.

Bute the lets encrypt certificates are only stored in the folder /etc/webmin/webmin not in the home directory of the user.

The apache web config is altered to use:
/home/some-domain/ssl.cert/key/ca
Bute the ssl.cert/key/ca is missing in the home directory.
If I made symlinkgs from /home/some-domain/ssl* to /etc/webmin/webmin/some-domain* everything works fine.
Bute after a renewal the configuration is broken again.
(If the ssl.cert/key/ca is missing apache didnt start - even webmin didnt start).

  1. Is this a bug or is the problem in front of the monitor :slight_smile:

  2. If not fixable, can I place a automatic script after the letsencrypt renewal wich creates the symlinks?

My System:
Debian 10 4.19.0-6-amd64
ii webmin 1.930 all web-based administration interface for Unix systems
ii webmin-virtual-server 6.07.gpl all Webmin module Virtualmin Virtual Servers
Mostly a complete new and clean installation…

2

Virtualmin hasn’t been released with support for Debian 10. (many of us are waiting impatiently for it!) so you are living dangerously!

On Debian 9, I have ssl.ca, ssl.cert, ssl.combined, ssl.everything and ssl.key in home directories, and these are copies (not symlinks) of files in /etc/webmin/webmin. I guess you could copy the files and/or set up a script to do it, or even use symlinks like you are doing (seems a good idea: I don’t know why it makes copies) but that may not be the last of your problems…

3

Oh okay, that’s new to me… but everything else woks fine (Webmin+Letsencrypt / Postfix,Procmail,Dovecot / Virtualmin + Domains, Subdomains, some Mailusers / MariaDB / Samba / Squid / DHCP palaver palaver) …

The problem with manually creating links (or copys): They are deleted by the next letsencrypt certificate renewal.
Iam looking for a possibility to run a own script after the automatic letsencrypt renwal (which creates the links)… is there a hook where I can add a own script?

4

I’d hardly know where to look for a hook from the Letsencrypt renewal, but perhaps you could write an hourly cron job that checked all the home directories for ssl files and replaced them when missing. Don’t quote me on that though, it’s not so much advice as stating the obvious and a horrible hack as your SSL files will be missing for up to an hour once every two months.

I’m not upgrading my server to Buster until Virtualmin is ready, but it’s reassuring to know that most of the rest of it works already. (I thought there were some issues with MariaDB, though.)

5

Hi, I fixed the problem (for me) by adding some “hack” to virtualmins /usr/share/webmin/virtual-server/feature-ssl.pl in function install_letsencrypt_cert .
The code is only executed if the ssl.key ssl.cert or ssl.ca is not created like intended.
It creates symlinks from /home/some_domain to the directory where the letsencrypt certificates are stored (on my system under /etc/webmin/webmin )

I didnt found a way to execute a script after letsencrypt renewal… If you dont like such “ugly hacks” or a seperate cronjob who fixes this problem maybe its a better idea not using virtualmin for letsencrypt - have look on certbot…
But I wanted a virtualmin solution…

# install_letsencrypt_cert(&domain, certfile, keyfile, chainfile) # Update the current cert and key for a domain sub install_letsencrypt_cert { my ($d, $cert, $key, $chain) = @_;

Copy and save the cert

$d->{‘ssl_cert’} ||= &default_certificate_file($d, ‘cert’);
my $cert_text = &read_file_contents($cert);
&lock_file($d->{‘ssl_cert’});
&unlink_file($d->{‘ssl_cert’});
&open_tempfile_as_domain_user($d, CERT, “>$d->{‘ssl_cert’}”);
&print_tempfile(CERT, $cert_text);
&close_tempfile_as_domain_user($d, CERT);
&set_certificate_permissions($d, $d->{‘ssl_cert’});
&unlock_file($d->{‘ssl_cert’});
&save_website_ssl_file($d, “cert”, $d->{‘ssl_cert’});

And the key

$d->{‘ssl_key’} ||= &default_certificate_file($d, ‘key’);
my $key_text = &read_file_contents($key);
&lock_file($d->{‘ssl_key’});
&unlink_file($d->{‘ssl_key’});
&open_tempfile_as_domain_user($d, CERT, “>$d->{‘ssl_key’}”);
&print_tempfile(CERT, $key_text);
&close_tempfile_as_domain_user($d, CERT);
&set_certificate_permissions($d, $d->{‘ssl_key’});
&unlock_file($d->{‘ssl_key’});
&save_website_ssl_file($d, “key”, $d->{‘ssl_key’});

Let’s encrypt certs have no passphrase

$d->{‘ssl_pass’} = undef;
&save_domain_passphrase($d);

And the chained file

if ($chain) {
$chainfile = &default_certificate_file($d, ‘ca’);
$chain_text = &read_file_contents($chain);
&lock_file($chainfile);
&unlink_file_as_domain_user($d, $chainfile);
&open_tempfile_as_domain_user($d, CERT, “>$chainfile”);
&print_tempfile(CERT, $chain_text);
&close_tempfile_as_domain_user($d, CERT);
&set_permissions_as_domain_user($d, 0755, $chainfile);
&unlock_file($chainfile);
$err = &save_website_ssl_file($d, ‘ca’, $chainfile);
$d->{‘ssl_chain’} = $chainfile;
}


#jackass23 fix
if (! (-e $d->{‘ssl_cert’}) ) {
if ( eval { symlink( $cert,$d->{‘ssl_cert’}); 1 } ) {
#nothing
}
}
if (! (-e $d->{‘ssl_key’}) ) {
if ( eval { symlink( $key,$d->{‘ssl_key’}); 1 } ) {
#nothing
}
}
if ($chain) {
if (! (-e $d->{‘ssl_chain’}) ) {
if ( eval { symlink( $chain,$d->{‘ssl_chain’}); 1 } ) {
#nothing
}
}
}

Create the combined cert file

&sync_combined_ssl_cert($d);
}

The symlinks and the original letsencrypt cert files belongs to root (rw only for user root). But apache can read it and the websites are “green”.
I tont know how this could work the apache server runs as user “www-data”… something I can worry tomorrow…