I am wondering if I am wrong about LE certs with a basic Radius set up as all you may need is a server certificate. Give it a go. It looks like the file to edit is /etc/raddb/clearos-eap.conf. I would use the fullchain as the certificate and the CA would be /etc/pki/tls/certs/ca-bundle.crt. If that does not work, use the LE cert.pem and concatenate /etc/pki/tls/certs/ca-bundle.crt with chain.pem and use that file. If the latter works, I would regenerate that file every time the certs renew.

Nick Howitt wrote:

Have a look at /etc/raddb/certs/README. It effectively means you can't use Let's Encrypt certificates as you can't create a Let's Encrypt CA cert and you don't know their key. If you use a LE cert as a server cert I don't think it will have the correct x509 extensions. Having said this, I could be wrong. You could try it if you want.
If you use an LE client certificate as your server certificate, you won't be able to create LE client certs. Each user will need to get their own from LE and I don't think that will work.
You don't have to regenerate them every year if you don't want to. You can default_days in /etc/raddb/certs/server.cnf to change the certificate length. When playing around a few years ago I changed it to 3650 days. I believe certificates can be distributed by a Group Policy/RSAT but I don't know Windows server admin.

I see. Yeah, having each user getting their own cert from LE would be a step in the wrong direction for sure.

Of course, been thinking about setting the default_days to something high giving it many years of validity, but this solution would still require new users to manually accept the self-signet certificates first time. At the moment I see some of our users struggling with this, especially on older Windows computers (dont know why).

So, if LE is incompatible with this, then the only solution is to buy a "standard" certificate of a set valid time (ofte 1 year, but could also be more I guess) and manually install it?
Or is self-signed the only option?

Have a look at /etc/raddb/certs/README. It effectively means you can't use Let's Encrypt certificates as you can't create a Let's Encrypt CA cert and you don't know their key. If you use a LE cert as a server cert I don't think it will have the correct x509 extensions. Having said this, I could be wrong. You could try it if you want.
If you use an LE client certificate as your server certificate, you won't be able to create LE client certs. Each user will need to get their own from LE and I don't think that will work.
You don't have to regenerate them every year if you don't want to. You can default_days in /etc/raddb/certs/server.cnf to change the certificate length. When playing around a few years ago I changed it to 3650 days. I believe certificates can be distributed by a Group Policy/RSAT but I don't know Windows server admin.

Could this be done for the radius auth of users (using wpa2 enterprise) also?

I've been updating the certificates manually every year now, but not all of my users are tech-comfortable and sometimes there is confusion to why and how they should accept the wifi-certificate.

So it would be much nicer to use the same auto-updating Lets Encrypt certificate for the wifi too, so that they wont have to manually accept the certificate.

Following this guide every year:
https://documentation.clearos.com/content:en_us:7_ug_radius

I guess that could be the basis of getting the Lets Encrypt cert used by the radius auth too?

Sorry for hogging this thread with a semi-connected issue. I'll create a new thread if that's better.
Thanks!

Dag Ove Hoel wrote:
But do you think the transfers are still encrypted in our case?

Yes they will be encrypted.

Nick Howitt wrote:

Lots of apps don't really care about the full validity of a certificate. Postfix and cyrus-imap don't care if your certificate is out of date and the domains don't match. They probably just want the certificate for encryption. I think you can validate a full certificate chain with openssl but you'll need to google something like "openssl verify remote certificate chain".

Like you said, I think a web browser would give a warning with a certificate chain like yours. We did have a misconfigured server at one point with a similar issue and I noticed it in a browser.

Thanks, I'll do some digging.

But do you think the transfers are still encrypted in our case?

Lots of apps don't really care about the full validity of a certificate. Postfix and cyrus-imap don't care if your certificate is out of date and the domains don't match. They probably just want the certificate for encryption. I think you can validate a full certificate chain with openssl but you'll need to google something like "openssl verify remote certificate chain".

Like you said, I think a web browser would give a warning with a certificate chain like yours. We did have a misconfigured server at one point with a similar issue and I noticed it in a browser.

Nick Howitt wrote:
I did a Base Domain change years ago and thought I'd lost everything as well. I managed to recover by running the deploy/install and deploy/upgrade routines from the failing apps (there were 3 - I remember Samba and OpenVPN but not the third. There is a forum thread on it somewhere). I have never dared try again.

After finally getting everything working I can only wonder: is there any situation where it would be required to change the Base Domain? I was thinking it was the reason we couldn't establish a secure connection (e.g. certificate did'nt match the "system.lan" domain) but right now it seems to be purely cosmetic and no practical use at all.

Nick Howitt wrote:
Your update to the LDAP certificates looks incorrect. Looking at the docs you need to use the cert.pem and key.pem as you have done. The problem is the CA and chain. What you've done is broken the link to the CA. Also you should really use the chain file rather than the fullchain file as well but it is not very important.

The docs say you should add the chain file to the end of the CA file. The chain file just about never changes, but let's assume it does. Then, in your update script it may be easiest to generate a new file every time which is the result of concatenating the two files together, and point your TLSCACertificateFile to the file you create.

Well, thats strange. It was the only combination that was accepted and viewed as secure by all ldap-browsers, ranging from pure php-scripts on our own web-host to ApacheDirectoryStudio to public online LDAP-browsers. Nothing points to this being a faulty ssl-connection, and for us it doesn't really matter as long as its secure (encrypted transfer, because of users passwords etc).

How would be be able to verify that the connection is in fact secure? If we used the certificates in this way to secure a web-connection trough 443 then I would assume that the web-browser's url-symbol/site-information could expose a broken ssl connection, but for the various ldap-browsers I can't see any similar possibilities.

I did a Base Domain change years ago and thought I'd lost everything as well. I managed to recover by running the deploy/install and deploy/upgrade routines from the failing apps (there were 3 - I remember Samba and OpenVPN but not the third. There is a forum thread on it somewhere). I have never dared try again.

Your update to the LDAP certificates looks incorrect. Looking at the docs you need to use the cert.pem and key.pem as you have done. The problem is the CA and chain. What you've done is broken the link to the CA. Also you should really use the chain file rather than the fullchain file as well but it is not very important.

The docs say you should add the chain file to the end of the CA file. The chain file just about never changes, but let's assume it does. Then, in your update script it may be easiest to generate a new file every time which is the result of concatenating the two files together, and point your TLSCACertificateFile to the file you create.

Nick Howitt wrote:

I am not sure that you need to. Generally, I believe, you can just import the ClearOS CA into the third party apps.

If you do want to use Let's Encrypt certificates, have a look at the Let's Encrypt howto and adapt one of the cyrus-imap or smtp/postfix methods. The file you need to edit is probably /etc/openldap/slapd.conf where there are three PEM entries. Guessing, but TLSCACertificateFile must point to the CA bundle (/etc/pki/tls/certs/ca-bundle.crt), TLSCertificateFile to your fullchain file and TLSCertificateKeyFile to your key file. When you get it all working and have confirmed it is is working with your third part app, please post back with the details and I'll add it to the howto.

Thanks guys!

Been through some "heavy learning" these last 3 days, trying to get the directory server to accept connections from outside LAN (first and foremost from Apache Directory Studio from home/vpn, but next step is to get it working from our website using php ldap which has not been an easy task so far)...

...and it's been ROUGH

I wont go into details here, but let me tell you: Never ever ever change the "Base Domain" entry for your Directory Server! I have no idea why its even possible to change this, because it wrecks EVERYTHING. And even then, trying to change the Base Domain everywhere else, reconfiguring, reading logs, rebooting, resetting, it will STILL NOT WORK as expected. Doing this on a production server has been nerve wrecking, but I finally came to my senses and restored the backup and everything was finally back to normal (or so it seems)



Aaaaaanywho, I'm here to spread some good news:
I've managed to get the Directory Server to correctly utilise the Let's Encrypt certificates (that I also use on the webserver, the webconfig, and home assistant) by editing slapd.conf with these entries:

TLSCertificateFile /etc/letsencrypt/live/our.custom.domain/cert.pem
TLSCertificateKeyFile /etc/letsencrypt/live/our.custom.domain/privkey.pem
TLSCACertificateFile /etc/letsencrypt/live/our.custom.domain/fullchain.pem

(replace our.custom.domain)

As mentioned in this thread I also did the chown and the chmod for these files and added the user ldap to the ssl-cert group.
I guess this could now be added to the How-To, right?


###

This pointed me in the correct direction
https://www.linuxquestions.org/questions/linux-server-73/openldap-with-let%27s-encrypt-ssl-certificate-4175620610/

Notice also that I have completely excluded /etc/pki/tls/certs/ca-bundle.crt

Im just happy that it's working! Finally the clients are not complaining about self-signed certificates :-D

Hello Nick,
I finally was able to change my certificate for my OpenLDAP server ....
so many hours lost , sorry for that.
Finally, changing the name of my certificates was a (very) bad idea...
I just copied them without changing anything to my clearos folder and modified the entries in my slapd.conf file..
Let me know if you need more informations
Thanks very much for your help

ok, thank you very much Nich, I'll re-read the whole
Have a good night

Please re-read my first post.

yes I will but ...(please don't shout at me)

in the slapd.conf file, you have 3 lines to config the certificates.

TLSCACertificateFile

TLSCertificateFile
TLSCertificateKeyFile

I've these 3 different files but If I combine 2 of them I could only fill in two of the three lines .. so If I understant correctly what you wrote here above :

cat /etc/clearos/certificate_manager.d/GFBienne.crt  /etc/clearos/certificate_manager.d/GFBienne.key > /etc/clearos/certificate_manager.d/GFBienne.combined

you combine the certificate and the key in 1 file. So there will still be the CA file.

so I'll define my

TLSCACertificateFile /etc/clearos/certificate_manager.d/GFBienne.intermediate

and maybe

TLSCertificateFile /etc/clearos/certificate_manager.d/GFBienne.combined

and so I let the option

TLSCertificateKeyFile

empty ?

No:

cat /etc/clearos/certificate_manager.d/GFBienne.crt  /etc/clearos/certificate_manager.d/GFBienne.key > /etc/clearos/certificate_manager.d/GFBienne.combined

You should be replacing the existing entries, not adding to them, so it should not be using the ClearOS ones.

thanks very much Nick .. sorry for my bad english . .. trying to do my best

I found a post to combine 2 certificates :

cat my_site.pem ca_chain.pem my_site.key > combined_cert.pem

but then, If I correctly understand, I'll have in my sldap.conf file 2 different cerfifcates ; the one I've with my official domain name (gfbienne.ch) and the one created by clearos ?

Noooooooo! Also I thought you were using Let's Encrypt.

Put your intermediate certificate and certificate into a single file. I don't know if the order matters. if it does, look an a Let's Encrypt fullchain file. Then:

TLSCACertificateFile     /etc/pki/tls/certs/ca-bundle.crt

TLSCertificateFile     /etc/clearos/certificate_manager.d/GFBienne.combined

TLSCertificateKeyFile  /etc/clearos/certificate_manager.d/GFBienne.key

[edit]
Edited slightly to combine the certificates
[/edit]

sorry,
Maybe I misunderstood what you wrote.
So, I added ldap to the ssl-cert group and i just made a try with the orignial certificates :

[root@master certificate_manager.d]# usermod -a -G ssl-cert ldap

and i just made a try with the orignial certificates :

TLSCACertificateFile     /etc/clearos/certificate_manager.d/GFBienne.intermedidate

TLSCertificateFile     /etc/clearos/certificate_manager.d/GFBienne.crt

TLSCertificateKeyFile  /etc/clearos/certificate_manager.d/GFBienne.key

but I still have the same error :

[root@master certificate_manager.d]# systemctl status slapd -l

● slapd.service - OpenLDAP Server Daemon

   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)

   Active: failed (Result: exit-code) since lun. 2020-04-06 16:30:33 CEST; 2min 27s ago

     Docs: man:slapd

           man:slapd-config

           man:slapd-hdb

           man:slapd-mdb

           file:///usr/share/doc/openldap-servers/guide.html

  Process: 7697 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=1/FAILURE)

  Process: 7667 ExecStartPre=/usr/libexec/openldap/prestart.sh (code=exited, status=0/SUCCESS)

 Main PID: 30479 (code=exited, status=0/SUCCESS)



avril 06 16:30:33 master.gfb.lan prestart.sh[7667]: Configuration directory '/etc/openldap/slapd.d' does not exist.

avril 06 16:30:33 master.gfb.lan prestart.sh[7667]: Warning: Usage of a configuration file is obsolete!

avril 06 16:30:33 master.gfb.lan runuser[7671]: pam_unix(runuser:session): session opened for user ldap by (uid=0)

avril 06 16:30:33 master.gfb.lan runuser[7671]: pam_unix(runuser:session): session closed for user ldap

avril 06 16:30:33 master.gfb.lan slapd[7697]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 11 2019 15:35:58) $

                                                      root@build-x86_64-1.orem.clearos.com:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd

avril 06 16:30:33 master.gfb.lan systemd[1]: slapd.service: control process exited, code=exited status=1

avril 06 16:30:33 master.gfb.lan systemd[1]: Failed to start OpenLDAP Server Daemon.

avril 06 16:30:33 master.gfb.lan systemd[1]: Unit slapd.service entered failed state.

avril 06 16:30:33 master.gfb.lan systemd[1]: slapd.service failed.

Please re-read my initial post, especially regarding the CA and try using the certificates unconverted. For diagnostics try

systemctl status slapd -l

If that returns nothing search the forum for starting slapd in interactive mode.

thans Nick.

Yes, there's no other error message. Just changing the certficates in my slapd.conf cause this error :

pidfile /var/run/openldap/slapd.pid

argsfile /var/run/openldap/slapd.args



# TLSCACertificateFile   /etc/openldap/certs/clearos-ca-cert.pem

# TLSCertificateFile     /etc/openldap/certs/clearos-cert.pem

# TLSCertificateKeyFile  /etc/openldap/certs/clearos-key.pem



TLSCACertificateFile     /etc/clearos/certificate_manager.d/GFBienne-CA.pem

TLSCertificateFile     /etc/clearos/certificate_manager.d/GFBienne.pem

TLSCertificateKeyFile  /etc/clearos/certificate_manager.d/GFBienne-key.pem

I was able to create my keyfile using , as you said, the rsa option

Arnaud Forster wrote:

Ok, so I'm gonna try to copy an rename it.

Here was the error message I get when trying to convert my key file :

[root@master certificate_manager.d]# openssl x509 -text -outform der -in GFBienne.key -out GFBienne-key.pem
unable to load certificate
140612166498192:error:0906D06C:PEM routines:PEM_read_bio:no start lineem_lib.c:707:Expecting: TRUSTED CERTIFICATE
[root@master certificate_manager.d]# ls -l

Use "rsa" and not "x509" for keys.

You'd have to find out why slapd failed to start. There is no clue in the message you posted. Did you remember to make the user ldap a member of ssl-certs?

O, I was able to convert / rename my certificates but my ldap server refuse them ...

...

Process: 9003 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=1/FAILURE)
Process: 8975 ExecStartPre=/usr/libexec/openldap/prestart.sh (code=exited, status=0/SUCCESS)
Main PID: 30479 (code=exited, status=0/SUCCESS)

avril 06 11:40:33 master.gfb.lan prestart.sh[8975]: Configuration directory '/etc/openldap/slapd.d' does not exist.
avril 06 11:40:33 master.gfb.lan prestart.sh[8975]: Warning: Usage of a configuration file is obsolete!
avril 06 11:40:33 master.gfb.lan runuser[8979]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
avril 06 11:40:33 master.gfb.lan runuser[8979]: pam_unix(runuser:session): session closed for user ldap
avril 06 11:40:33 master.gfb.lan slapd[9003]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 11 2019 15:35:58) $
root@build-x86_64-1.orem.clearos.com:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd
avril 06 11:40:33 master.gfb.lan systemd[1]: slapd.service: control process exited, code=exited status=1

i probably, as you sais, need to copy my certificate in /etc/pki/tls/certs/...

Ok, so I'm gonna try to copy an rename it.

Here was the error message I get when trying to convert my key file :

[root@master certificate_manager.d]# openssl x509 -text -outform der -in GFBienne.key -out GFBienne-key.pem
unable to load certificate
140612166498192:error:0906D06C:PEM routines:PEM_read_bio:no start lineem_lib.c:707:Expecting: TRUSTED CERTIFICATE
[root@master certificate_manager.d]# ls -l

Did slapd give an error? I think you can just rename the certificates.

Note that if you're using Let's Encrypt certificates you won't want to go through the Import Certificate route as it cannot be automated for every time the Let's Encrypt certificate updates. You'll want to do somethng like rsync them across from the originating server. Then have the receiving sever watch for new certificates being received, move them into place and restart slapd.

Hello Nick,
Yes thanls for that, I found the file ... but nex problem .. it seems slapd use .pem certficates and mine are crt ; intermediate and .key ones. I successfully converte my .cert and my .intermediate to .pem certificates but noway for the .key one.

I'll look for that .key file to be converted, If I can't, I'll use the CA certificate.

I come back with the details .
thanks

I am not sure that you need to. Generally, I believe, you can just import the ClearOS CA into the third party apps.

If you do want to use Let's Encrypt certificates, have a look at the Let's Encrypt howto and adapt one of the cyrus-imap or smtp/postfix methods. The file you need to edit is probably /etc/openldap/slapd.conf where there are three PEM entries. Guessing, but TLSCACertificateFile must point to the CA bundle (/etc/pki/tls/certs/ca-bundle.crt), TLSCertificateFile to your fullchain file and TLSCertificateKeyFile to your key file. When you get it all working and have confirmed it is is working with your third part app, please post back with the details and I'll add it to the howto.