Forums

Resolved
0 votes
Hello all,
I imported into my system a wildcard certificate. I installed it and declare it to use with the webconfig console.
Now, I need to connect to my OpenLDAP server from other applications and I wanted to use my certificate. But, as I can see, my OpenLDAP still use my orginal self-signed certificate.
Is there a way to change that to make my ldap use my imported certificate ?
Thanks to all for your help
Monday, April 06 2020, 07:30 AM
Share this post:

Accepted Answer

Monday, April 06 2020, 09:18 PM - #Permalink
Resolved
0 votes
The reply is currently minimized Show
Responses (26)
  • Accepted Answer

    Tuesday, March 22 2022, 09:32 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, March 21 2022, 10:49 PM - #Permalink
    Resolved
    0 votes
    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?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, March 20 2022, 09:29 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, March 20 2022, 09:08 PM - #Permalink
    Resolved
    0 votes
    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!
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, March 17 2022, 05:04 PM - #Permalink
    Resolved
    0 votes
    Dag Ove Hoel wrote:
    But do you think the transfers are still encrypted in our case?
    Yes they will be encrypted.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, March 17 2022, 04:55 PM - #Permalink
    Resolved
    0 votes
    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?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, March 17 2022, 04:35 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, March 17 2022, 03:51 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, March 17 2022, 11:19 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, March 02 2022, 08:41 PM - #Permalink
    Resolved
    0 votes
    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)

    :o

    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
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 07 2020, 05:40 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 08:46 PM - #Permalink
    Resolved
    0 votes
    ok, thank you very much Nich, I'll re-read the whole
    Have a good night
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 08:16 PM - #Permalink
    Resolved
    0 votes
    Please re-read my first post.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 08:11 PM - #Permalink
    Resolved
    0 votes
    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 ?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 07:31 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 06:36 PM - #Permalink
    Resolved
    0 votes
    :) 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 ?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 03:18 PM - #Permalink
    Resolved
    0 votes
    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]
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 02:33 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 11:51 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 10:25 AM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 10:04 AM - #Permalink
    Resolved
    0 votes
    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 line:pem_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?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 09:42 AM - #Permalink
    Resolved
    0 votes
    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/...
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 09:34 AM - #Permalink
    Resolved
    0 votes
    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 line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
    [root@master certificate_manager.d]# ls -l
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 09:21 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 08:18 AM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Monday, April 06 2020, 08:08 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
Your Reply