Hi all,
all the sudden, I get this error when I run system diagnostic:
Nevertheless the Letsencrypt certificate creation process still runs smooth and the certificates are still updated and valid (Apache).
The provided link (UCS Support DB) within the error message covers “self signed” certificates and is not very helpful - I guess …
Any hint for how to further troubleshoot or fix this, would be much appreciated.
Thx and best regards
Thomas
It seems that the same issue was already reported a while ago here:
Unfortunately the proposed solution (run “update-ca-certificates”) does not work for me.
Not even a little hint what I could check?
Hello @tpfann,
please check the symbolic link under /usr/local/share/ca-certificates.
There should be a link like this:
root@ucs:/usr/local/share/ca-certificates# ls -l
lrwxrwxrwx 1 root staff 44 Mai 30 2020 lets-encrypt.crt -> /etc/univention/letsencrypt/intermediate.pem
Best regards
@Martin
Hi Martin,
thank you for your reply!
I have checked the link as proposed and it seems to be okay:
What else could I check?
Best regards
Thomas
Please check /var/log/univention/letsencrypt logifiles and the date of certificate files.
The file date shoud be within the last three months (depending on last certificate renewal).
thank you for your reply!
What I was trying to achieve is, to turn on the “Postfix” option and rerun the Letsencryt certificate creation process.
Afterwards system diagnostic gave me the error above (invalid certificate).
The last valid certificate was created on Dec. 1st.
Comparing the two certificates shows me that there is a different name for the intermediate now?!
Meanwhile I have switched off the “Postfix” option again and copied back the certificate from Dec. 1st. System diagnostic is back green now, but I consider this as a workarround only.
Sorry, but I cannot help you very much with Letsencrypt.
A few ideas:
Did you check the logfile /var/log/univention/letsencrypt.log, what happened after activating “Postfix” in Letsencrypt?
There should be mentioned, why creation of the chertificate of postfix failed, if it did so.
In addition you will need to set the correct certificate for Postfix in Univention registry.
Hi,
thanks again for having a look.
The relevant parts in the logfile look identical (everything okay) and neither “Apache” or “Postfix” are mentioned in the logfile: letsencrypt.log (2.7 KB)
The certifcate itself seems to be okay in all cases as it shown as valid in the browser.
The logfile looks good.
What about the settings in the Univention registry (after login with browser: System - Univention Configuration Registry and search for postfix (with stars)?
Maybe I am on the wrong way, if activation of Postfix in Letsencrypt I see no other source.
On my system I found:
mail/postfix/ldaptable/tlscacertfile /etc/univention/ssl/ucsCA/CAcert.pem
…
mail/postfix/smtpd/tls/smtpd_tls_cert_file /etc/univention/letsencrypt/chain.pem
mail/postfix/smtpd/tls/smtpd_tls_key_file /etc/univention/letsencrypt/domain.key
…
mail/postfix/ssl/certificate /etc/univention/letsencrypt/chain.pem
mail/postfix/ssl/key /etc/univention/letsencrypt/private.pem
Only the first variable is filled identical on my system:
mail/postfix/ldaptable/tlscacertfile /etc/univention/ssl/ucsCA/CAcert.pem
The other 4 variables are currently not filled or not even existing.
But keep in mind, the option “Postfix” is currently disabled (due to fallback) - So this could be an expected behaviour?!
I will give it another try (enable “Postfix”) later and will check the value of the variables again.
Tanks for your support!
I had seen it. But after enabling Postfix the variables should have been set or you will need to set them manually.
Hi,
after the cronjob for the certificate renewal was executed last night (every 1.st of month) - The above discribed error is back now - The Postfix-option is still diabled.
The Letsencrypt log-file looks good and the fresh created certificate is shown as valid in my browser.
The only noticable difference to the last certificate (from Dec. 1st) is the change of the name for the intermediate) - as already discribed above.
I dont know what exactly is checked by the “System Diagnostic”, could it be that files like intermediate.pem or chained.pem need to be updated manually, they are quite old on my system (from 2018)?
Best regards
Thomas
Did some more checks and it really seems that for some reason the signing chain is broken on my system.
when I check the last valid certificate (from Dec. 1st) on my system I get:
openssl verify signed_chain.crt_20201201-033135
signed_chain.crt_20201201-033135: OK
When I do the same check on the new created certificate (from Jan. 1st) I get:
openssl verify signed_chain.crt
CN = remote.xxxxx.de
error 20 at 0 depth lookup: unable to get local issuer certificate
error signed_chain.crt: verification failed
What is the “local issuer certificate”? Is it the CAFile that can be found under /etc/ssl/certs?
How can it be updated than? - running “update-ca-certificates” didnt change anything.
In /etc/ssl/certs I found lets-encrypt.pem that is linked to:
-> /usr/local/share/ca-certificates/lets-encrypt.crt
/usr/local/share/ca-certificates/lets-encrypt.crt is linked to:
-> /etc/univention/letsencrypt/intermediate.pem
My feeling is that the issue on my system is somehow related to this and/or my system missed an update in order to adapt it: https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html
Same porblem here. Kopano z-push sync no longer working. After logging on to the UCS Server I was able to download the R3 certifcate and paste it into /etc/univention/letsencrypt/intermediate.pem and restarted apache
This fixed some problems (Android Devices can now sync again) but I still get the diagnostic error and SSLabs reports " Chain issues Incorrect order, Extra certs"
It all has to do with the letsencrypt change to a new root certifcate as far as I understand.
Any further help is appreciated
Update: I replaced /etc/univention/letsencrypt/intermediate.pem with https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem - restarted apache and now SSLabs does not have any issues anymore! Everything seems to work - except for the UCS System Check Error Message: UCS Fehlermeldung:
Ungültiges Zertifikat ‘/etc/univention/letsencrypt/signed_chain.crt’ gefunden: error /etc/univention/letsencrypt/signed_chain.crt: verification failed
I am experiencing the same issue.
Thanks for sharing you findings and your workarround with us.
Unfortunatley this workarround isn’t working for me.
System diagnotics is also okay now on your system?
Besides restarting Apache, did you also recreated the cetificate?
No - System diagnostics still reports the same error 
- but the system works as usual and SSLabs reports no errors. The Letsencrypt App renewed the certificate on January 1st. Thats where the problem started. Besides Apache restart I executed /usr/sbin/univention-certificate-check-validity. Thats all
I have exactly the same problem…
Same Problem here, tried to solve this all day long. kopano stopped with all e-mail delivery, i think because of the untrusted le-cert in postfix.
output of mail.log:
Jan 4 16:07:49 ucs kopano-spooler[29577]: Connect to SMTP: Error while connecting socket… E-Mail will be tried again later.
Jan 4 16:07:49 ucs kopano-spooler[29577]: Unable to connect to SMTP server, retrying mail for user XXXXX later
I tried to reinstall letsencrypt app with removing all files in /etc/univention/letsencrypt, but now i got: “too many certificates already issued” in app config so i have to try later.