LDAP Generate SSL Certificate is broken

I was trying to configure LDAP with SSL and used the generate SSL certificate button to create a self signed cert. The cert that it generates is invalid. When you look at the cert, one of the keys has .lock on it, and it's an empty file. I had to generate a self signed certificate with openssl and that worked fine.

Status: 
Fixed (pending)

Comments

Which page in Virtualmin were you using to generate this SSL cert exactly?

somehow a nested call to "open_lock_tempfile" is broken, either generally or local, I'm not a perl expert.

fixed sniplet in webmin-lib.pl:

sub parse_ssl_key_form
{
.
.
.
.
my ($kfh, $cfh);

&open_lock_tempfile($kfh, ">$keyfile");
&print_tempfile($kfh, $keyout);
if (!$certfile) {
# Both go in the same file
&print_tempfile($kfh, $certout);
&close_tempfile($kfh);
}
else {
# Separate files
&close_tempfile($kfh);
&open_lock_tempfile($cfh, ">$certfile");
&print_tempfile($cfh, $certout);
&close_tempfile($cfh);
&set_ownership_permissions(undef, undef, 0600, $certfile);
}
&set_ownership_permissions(undef, undef, 0600, $keyfile);

return undef;
}

Did you get any error message in your browser after trying to generate a cert, or did it just fail silently?

no error message, died silently, messed up the ldap's config checksum, ldap.key.lock file was filled with a number, possibly a file-handle, could not figure out where the problem is, I don't really know perl, maybe a global variable somewhere which messes up nested calls to the mentioned function... maybe

Sounds like the lock file was created but never cleared up.

Did anything get logged to /var/webmin/miniserv.error when this happens?

Negative, no error in this logfile. It's somehow more than just not cleaning up. Content is also wrong. Closing $kfh before opening a new tempfile was the only way I found to get it work.

Is there any integrity check script for the whole installation? Not that some files are from different version or missing ... I also got a different problem where key/value pairs were missing from a config file which would have been mandatory.

Let me see if I can reproduce this. Is your system a fresh Debian 8 install, or an upgrade?

Actually its a fresh Debian 4.9.110-3+deb9u4 + LAMP from Hetzner.de with preinstalled webmin.

Wait, Debian 4.9? Are you sure about that version?

Also, can you attach the contents of your system's /etc/ldap/slapd.d/cn=config.ldif file to this bug report? That will show me which paths are being used for the certificate files.

--------------------
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 7e11a361
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: b19152be-529e-2038-96ee-f75049623566
creatorsName: cn=config
createTimestamp: 20180922103330Z
entryCSN: 20180922103330.819799Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20180922103330Z
-------- origi ----------

--------- added by webmin:
olcTLSCertificateFile: /etc/ldap/slapd.d/ldap.cert
olcTLSCertificateKeyFile: /etc/ldap/slapd.d/ldap.key
----------------------------------------------

Got the same problem on a newly installed Ubuntu18.04

No errors in /var/webmin/miniserv.error

Got a key.lock with a random number in it.

Output of /etc/ldap/slapd.d/cn\=config.ldif:

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 e8d5f942
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: 712cff9e-86aa-1038-9235-e35ff5d75f15
creatorsName: cn=config
createTimestamp: 20181127160837Z
entryCSN: 20181127160837.213292Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20181127160837Z
olcTLSCertificateFile: /etc/ldap/slapd.d/ldap.cert
olcTLSCertificateKeyFile: /etc/ldap/slapd.d/ldap.key

I tried using an existing wildcard certificat, which I successfully used to access webmin itself, but then the checksum on the ldif file fails

I assume you're running the latest 1.900 release of Webmin?

Also, make sure that your system isn't out of disk space or inode space.

Operating system Ubuntu Linux 18.04.1 Webmin version 1.900 Usermin version 1.741 Virtualmin version 6.04

Real memory 1.40 GB used / 9.53 GB total Virtual memory 0 bytes used / 957.03 MB total Local disk space 29.78 GB used / 460.43 GB free / 490.21 GB total

I tried to generated it now, but this time it does nothing. After 10 minutes I reloaded the page and got the following lines in syslog:

Dec  3 08:49:47 *** slapd[399]: @(#) $OpenLDAP: slapd  (Ubuntu) (Oct 23 2018 13:01:47) $#012#011Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Dec  3 08:49:47 *** slapd[399]: daemon: bind(7) failed errno=98 (Address already in use)
Dec  3 08:49:47 *** slapd[399]: daemon: bind(7) failed errno=98 (Address already in use)
Dec  3 08:49:47 *** slapd[399]: slapd stopped.
Dec  3 08:49:47 *** slapd[399]: connections_destroy: nothing to destroy.
Dec  3 08:49:47 *** slapd[401]: @(#) $OpenLDAP: slapd  (Ubuntu) (Oct 23 2018 13:01:47) $#012#011Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>

What do df -h and df -i output on your system?

Some parts are masked by '…':

root@…:~# df -h
Filesystem                        Size  Used Avail Use% Mounted on
udev                              4.9G     0  4.9G   0% /dev
tmpfs                            1000M  860K  999M   1% /run
/dev/mapper/…--vg-root           491G  5.1G  461G   2% /
tmpfs                             4.9G     0  4.9G   0% /dev/shm
tmpfs                             5.0M     0  5.0M   0% /run/lock
tmpfs                             4.9G     0  4.9G   0% /sys/fs/cgroup
…:/volume1/… 3.9T  3.1T  855G  79% /Backups/…
…:/volume1/…      11T  4.1T  6.8T  38% /Backups/…
tmpfs                            1000M     0 1000M   0% /run/user/0
root@…:~# df -i
Filesystem                          Inodes  IUsed     IFree IUse% Mounted on
udev                               1271337    424   1270913    1% /dev
tmpfs                              1279028    770   1278258    1% /run
/dev/mapper/…--vg-root           32710656 235167  32475489    1% /
tmpfs                              1279028      1   1279027    1% /dev/shm
tmpfs                              1279028      6   1279022    1% /run/lock
tmpfs                              1279028     18   1279010    1% /sys/fs/cgroup
…:/volume1/…     262144000  18943 262125057    1% /Backups/…
…:/volume1/… 365682688   9986 365672702    1% /Backups/…
tmpfs                              1279028     10   1279018    1% /run/user/0

Looks like you have plenty of free space. I think to debug this further I'd need to login to your system myself ..

Well I don't think that is going to happen …

It a freshly installed Virtual Server with plain Ubuntu 18.04 The only changes i did were: - changed ssh port. - added two rules in Firewall to allow this port and icinga/nagios via an other one - redirected the root email adress - install dkim - added some fail2ban jails - added some cronjobs (only checking stuff an sending emails if something is wrong) - install pflogsumm - changed mail.log rotation to daily and keeping more versions - added nameservers and binding of these

Now the only change that could cause this: - added a new webmin user with the same rights ass root - disabled the default root user

… I will reenable the root user and try generating the certificat with it

Using root user to generate the certificate did not help. Same result: ldap.key.lock file with random numbers in it

This file should exist in /etc/webmin/webmin/?

That folder is empty, except for: config, root.acl, letsencrypt.pem, and .cert .chain .key for the website active on the server …

I added the webmin-lib.pl to the folder, restarted webmin, an tried generating a certificate, but nothing happened …

No it should be in /usr/share/webmin/webmin

Status:
Active
»
Fixed (pending)

Great, thanks!