Yes, I confirm that System Diagnostic is still reporting the error. I think that we need to wait until a definitive solution with an official update.
Unfortunately the update to version 4.4-7 errata863 did not fix the problem with the LetsEncrypt certificate chain.
Same as on my UCS now.
It is possible to cleanly revert back from Letsencrypt to self-signed certs?
Self signed certificates may cause problems in communication with clients (brovsers, mobile devices, mail communication and more)
In December Lesencrypt had announced a new Certbot under Python starting january 2021, but as far as I know UCS uses other scrips for renewing. I do not know. whether there are more changes.
See:
https://letsencrypt.org/de/docs/client-options/ (German)
https://letsencrypt.org/docs/client-options/ (English)
(last update: Jan. 8th 2021)
btw.:
Since installation in year 2019 I have these settings in default-SSL.conf:
...
SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
SSLCertificateChainFile /etc/univention/letsencrypt/intermediate.pem
...
I did the following:
root@ucs:/etc/univention/letsencrypt# openssl s_client -connect ucs.<mydomain>.de:443
CONNECTED(00000003)
depth=0 CN = ucs.<mydomain>.de
**verify error:num=20:unable to get local issuer certificate**
verify return:1
depth=0 CN = ucs.<mydomain>.de
**verify error:num=21:unable to verify the first certificate**
verify return:1
---
Certificate chain
0 s:/CN=ucs.<mydomain>.de
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGbzCCBVegAwIBAgISA40AgVyo26SJWZTBnpspi+CDMA0GCSqGSIb3DQEBCwUA
...
QxuLNPKx9oyvshRHIJh8rOiChQ==
-----END CERTIFICATE-----
Did you get the same errors as mentioned above?
I also tested “openssl s_client -connect …” on annother server with Ubuntu and Letsencrypt via Certbot andI didn’t get any verify error.
So my conclusion ist,that the error either is UCS- or Letsencrypt ACME- related.
And again: The next update to version 4.4-7 errata868 did not fix the problem with the LetsEncrypt certificate chain.
After changing SSLCertificateChainFile to signed_chain.crt
SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
SSLCertificateChainFile /etc/univention/letsencrypt/**signed_chain.crt**
the command
openssl s_client -connect ucs.<mydomain>.de:443
shows no error anymore.
But yesterday I found out, that Letsencrypt issued new root- and intermediate certificate in September 2020.
I don’t know, how UCS verifies the certificates but it seems, that the validation procedure in the Letsencrypt-App is outdated.
Same problem in that thread:
https://help.univention.com/t/letsencrypt-verification-failed/17006/7
with a link to bugreport and possible workaround.
I am having the same problem and couldnt find a proper solution. Why no staff member got interest on this topic ?
Best Regards,
Talion
Our certificate is a SAN certifcate (Subject Alternative Name). Maybe this is the reason for the problem?
same after update to 4.4-7 errata870: No valid certificate chain.
We only can wait, until Letsencrypt-App will have been upgraded by Univention.
But time is running, our workaround has only a few days left
1 Like
Groundhog Day: update to 4.4-7 errata873: No valid certificate chain
But in https://forge.univention.org/bugzilla/show_bug.cgi?id=52517 the bug is marked as RESOLVED FIXED
Does it mean I have to reinstall the LetsEncrypt app?
The UCS system diagnostic module has issues when trying to verify certificates from external CAs, so this may be a false positive.
Are any services currently restricted in the environment? Or is only the diagnostic module complaining.
See also the following bugs, there is some information why openssl verify is not always the best tool to check cert chain validity, especially https://mail.python.org/pipermail/cryptography-dev/2016-August/000676.html
https://forge.univention.org/bugzilla/show_bug.cgi?id=52517
https://forge.univention.org/bugzilla/show_bug.cgi?id=52546
Thx for having a look and comming back to us!
As already stated in my first posting the certifcate seems to be valid (currently).
Correct, it seems that '“only” the diagnostic module is complaining - And tbh, its not nice at all when system diagnostic is reporting an critical issue since over a month now.
Okay? Why not change the logic then or fix it?
Okay? Not sure what you want me to do instead …
Thanks, i just wanted to make sure.
I understand and totally agree, it causes uncertainty. I will try to bump the priority in our backlog for Bug 52546 - LetsEncrypt signing chain broken - UCS System Diagnostic reports errors now
Sorry if this came across wrong, i just wanted to provide more information for the technically interested readers.
damrose,
Thank you for your provided feedback and taking care.
Our certificate problem was noch only this “signed_chain” verify error and the critical message in the system diagnosis GUI, but also the ost connection to the mail server.
Right now after drawing some screws (and go backward) and 3 UCS updates, I tried to renew the certificate. Both errors (openssl verify and GUI system diagnosis) still appear, but now themail transfer works. So we only have to ignore the error messages.
When checking the certificate in Mozilla Firefox it seems to be valid.
Hi,
I can confirm that with the todays release of Letsencrypt (version 1.2.2-16) system diagnostic is green now and back to normal. 
BR,
Thomas
1 Like