Good luck.
I saw that your domainname is a FQDN, so: external name = internal name, right?
As I use Let’s encrypt certificates for our server I need to copy the certificate (via cronjob) to this directory. Maybe there’s the problem in your setup??
Greetings,
Michael
Thanks,
No, the domain name is just an internal address, so it’s not fqdn, I tried eltetrefort.lan and eltetrefort.org to see if it matters, I used the former under Linuxschools without problems and the latter under Sambaedu, so I guess the domain name alone shouldn’t be a problem.
Our external ip address itself and our name resolver are part of a larger organisation (ELTE University, the external ip 157.181.x.x all belong to it), it is important to use their 157.181.3.1 (or 157.181.42.42) name resolver, as it will translate a lot of things inwards (mostly elte. hu), which is the only way to get it to work correctly, and this hasn’t caused any problems for Linuxschools and Sambaedu either, but hopefully we’ll be smarter on Monday when I’ll look into the above you suggested.
Ok … just a few ideas:
You can also check
journalctl -u samba-ad-dc
for more detailed log-files.
Or you can increase the log-level for Samba here:
cd /etc/samba/
mcedit smb.conf
-->
#Normal Mode (deactivate this entry):
log level = 1 auth_audit:3
# Debug-Mode (increase from 1 to 3 and activate this):
#log level = 3 passdb:5 auth:5 auth_audit:3… and of course
systemctl restart samba-ad-dcGood luck.
Hello,
The contents of the samba.conf file also confirms that the server cert.pem key is not/has not been created, which is not helped by the cert renewal script mentioned above. So the origin of the problem has been identified, question how to proceed from here?
Thanks, Fenyő
Hm – that’s strange … did you check the rights and the size of the files in /etc/linuxmuster/ssl?
Here:
-rw-r--r-- 1 root ssl-cert 7253 Mai 15 04:06 server.cert.bundle.pem
-rw-r--r-- 1 root ssl-cert 374 Apr 21 18:08 server_cert_ext.cnf
-rw-r----- 1 root ssl-cert 2208 Mai 15 04:06 server.cert.pem
-rw-r----- 1 root ssl-cert 1724 Mai 15 04:06 server.csr
-rw------- 1 root ssl-cert 3243 Mai 15 04:06 server.key.pemand:
cat server.cert.bundle.pemstarts with
-----BEGIN CERTIFICATE-----
MIIGM ....Are the rights and owner of your files correct? (-rw-(r)–(r)-- and root:ssl-cert)?
(ls -la * /etc/linuxmuster/ssl )
If you just need to create a new (self-signed) certificate you can also follow these instructions (but of course it should work with linuxmuster-renew-certs as wel) :
https://arminreiter.com/2022/01/create-your-own-certificate-authority-ca-using-openssl/
yes the permissions seem to be ok in the ssl directory and the contents of the bundle file are readable. the renew script does nothing unfortunately. The manual solution if I understand correctly creates a crt and key file, but I’m lost from the fourth step, we don’t have a webserver, or rather we don’t run our website, but on a server of ELTE.
That’s the problem … your bundle does not consist of the certificate AND the key but ONLY of the key.
(and you don’t need the steps for the webserver … just the recreation of the server-cert and the bundle)
Yes, the key pairs were not created during the installation, that’s clear and for some reason the renew script can’t create them either. With this manual method I can create a crt and a key file, but it is not clear if I should then rewrite the smb.conf file or rename the created files and then rename key to pem or which of the 2 files created should be which?
Ok, I think both ways should be possible. But the easiest and best way should be to keep the entries and rename files.
Else you will have the same problem later with the file
/etc/linuxmuster/api]$ cat config.ymlThere’s also the filename ssl_certfile: /etc/linuxmuster/ssl/server.cert.bundle.pem
(it’s no problem to rename a crt to pem by the way … → https://stackoverflow.com/questions/63195304/difference-between-pem-crt-key-files )
In your case I would try
cat trefortserver.fullchain.pem trefortserver.key.pem > trefortserver.cert.bundle.pem
to recreate the new bundle-file.
Afterwards:
chown root:ssl-cert trefortserver.cert.bundle.pem
and of course
systemctl restart samba-ad-dc
and see if it works with a new certificate… 
There is no /etc/linuxmuster/api directory, is this again cause or effect? The trefortserver.cert.pem file is missing in samba, the bundle and fullchain files exist, so I don’t really understand the proposed merge. Based on the linked description I can generate a crt and a key file, if renaming them would work, which one should I rename to which? Also, I noticed in systemctl that the quota service is not running alongside samba, but I guess this will be an depend of samba.
Hi.
Ok, the bundle-file exists … but it does not contain all needed parts as far as I see it 
.
The server.cert.bundle.pem consists of three parts:
-----BEGIN CERTIFICATE-----
bla bla
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
bla bla
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
bla bla
-----END RSA PRIVATE KEY-----but in your case this file has exactly the same size than trefortserver.key.pem – so something is wrong with this bundle (in my opinion). That’s why I suggested to append all three files (with the cat-Command) to one file:
cat trefortserver.fullchain.pem trefortserver.key.pem > trefortserver.cert.bundle.pem
Can you give it a try?
In the meantime I reinstalled the linuxmuster api package so it now appears under /etc/linuxmuster.
Yes, but which third file should I add, the above two didn’t work, it still misses trefortserver.cert.pem, which doesn’t exist.
I’m still a bit confused by the names … now the cert is called lmnapi.pem?
cat trefortserver.fullchain.pem trefortserver.key.pem > trefortserver.cert.bundle.pem
The fullchain should consist of two parts … and the key is the third part. These three parts are copied to the bundle-file …
This is the content of the api directory (lmnapi.pem) you asked me to list above.
Unfortunately, the 2 files concatenated to bundle.pem do not work (permissions set of course), and the cert.pem file is still missing in samba.
I even found this in the setup.final.log, ovsdb-server.service is not running on the opnsene, but I don’t see a service with that name under the plugins tab.
Hi Fenyo,
your IP setup is a bit unusual.
We use
10.0.0.0/24
most often.
Is there a reason to use that?
Are you sure that there is no such Net outside your OPNsense in your Network?
Did you install the OPNsense wit a „blue“ Network?
What IP Net do you have there?
Yours
Holger
Hello,
Mostly I use 172.16.0.0/16 for inherited stuff, because the printers and other servers (openmediavault, camera systems etc) are here and it would be a pain to change the ip addresses of the installed printers on a hundreds of clients, and importing clients would be easier this way. And using 172. 16.0.254 is not used because it has a switch administration ip address (of course I can clean it up elsewhere if necessary) , so I arbitrarily made 172.16.0.11 the address of the lan leg of opnsense. Unfortunately I don’t know what the term „blue“ network means. First I had only one opnsense with the wan leg set directly to the fixed external ip address of the provider (ELTE). Its gateway was always overwritten by the websetup to the internal leg of the opnsense, which could be reset, but nameserver is always a problem, the lmn sets it to itself, but it can’t resolve anything on the fly, only if I add another nameserver, but then the lmn is not accessible from client to browser anymore. So I obtained a router, on the one hand, to test separately on another network regardless of the time, and on the other hand, the gateway configuration problem is gone, „only“ namserver remains.
Of course I can try it with default ip settings to see if it makes a difference.
Before reinstalling deafult ip addressing, I checked what the command line setup says, and it also misses trefortsetver.cert.pem file, so this seems to be the root of the problem.
I checked then with default ip addressing (10.0.0.1 server 10.0.0.254 opnsense lan), but it doesn’t make any difference, so as you would expect the default ip addressing can be changed, the problem in my case is that the server ssl authentication keys are not generated during installation and the renew script can’t generate them either. It could be tried manually in principle, but unfortunately I don’t know how to do that, so I’m stuck here.
What I can try is to do an installation at home to see if the problem exists from another wan network.
Hi. I don’t know why … but you can generate new ones manually … the v7-Server is alreaday a CA by itself.
Step 1: Generate trefortserver.csr (CERTIFICATE REQUEST) and trefortserver.key.pem (PRIVATE KEY)
openssl req -new -nodes -out trefortserver.csr -newkey rsa:4096 -keyout trefortserver.key.pem -subj '/CN=Self-Signed-Cert/C=DE/ST=NDS/L=Location/O=Organisation'Step 2: Find the CA pass phrase
cd /etc/linuxmuster/.secret
cat cakeyStep 3: Sign the certificate
cd /etc/linuxmuster/ssl ← there should be the CA-Cert and the CA-Key (maybe with different names than shown here?! If these files are present … create the missing cert manually:
openssl x509 -req -in trefortserver.csr -CA cacert.crt -CAkey cakey.pem -CAcreateserial -out trefortserver.cert.pem -sha256… this command should do the job and create a new self-signed cert named trefortserver.cert.pem. Afterwards you can create the bundle-File…
Does this work?
Check the new certificate with
openssl x509 -in trefortserver.cert.pem -text -nooutGood luck.
Michael