Thank you for the help @schoen ! ! ! Now waiting Webuzo team to try to fix this. Will update here.
@luffy56 also you try to fix again with Webuzo Team, we can be near at the solution and help the control panel to have a good let’s encrypt certificate 
Hi,
@schoen Thanks for the reply
Actually I removed the certificate few days back from the mail Server config for testing and configured the self-signed one.
But as you can see the from https://crt.sh that cert for my domain exist as the Screenshot of The Telnet Output shows this when I had it installed.
Further more the output of
php -r "print_r((openssl_get_cert_locations()));"
gives me the following output
[default_cert_file] => /usr/local/apps/etc/openssl/cert.pem
[default_cert_file_env] => SSL_CERT_FILE
[default_cert_dir] => /usr/local/apps/etc/openssl/certs
[default_cert_dir_env] => SSL_CERT_DIR
[default_private_dir] => /usr/local/apps/etc/openssl/private
[default_default_cert_area] => /usr/local/apps/etc/openssl )
I have symlinked the file /usr/local/apps/etc/openssl/cert.pem from /etc/pki/tls/cert.pem so the openssl.cafile issued was resolved.
Now the strange thing I notice is that the cert and private key directory mentioned are in /usr/local/apps/etc/openssl/ and the LE certs and private key is present in the /etc/ssl/ directory
So is this the issue ?
Telnet does not use SSL certificates at all so makes for a bad testing ground
OpenSSL is not related to Let’s Encrypt Certificates.
How PHP and PHP Mail Works
A) User Script --> PHP Mail
B) PHP Mail --> PHP Global Configs
C) PHP Global Configs --> OpenSSL
D) OpenSSL --> Mail Server
Working back from this - find location of OpenSSL version PHP is working with
Test with that version of OpenSSL against the mail server
If there are issues - fix the mail server
Andrei
The screenshot suggests that @luffy56 was using openssl s_client, which is a valid alternative to telnet for this kind of testing purpose. It can show what certificate a particular TLS server is using.
Finally was able to resolve the issue.
Thank you @schoen and @ahaw021 for guiding me through and answering my dumb questions.
So here is the solution if anyone is facing the same in Webuzo
If you are adding the following in your Exim conf
tls_certificate = /etc/ssl/cert/yourdomain.pem
the .pem file is missing the letsencrypt X3 intermediate certificate so I downloaded the same from here and pasted in the yourdomain.pem
And now the mails are being correctly delivered.
So it’s Let’s Encrypt that does not include the intermediate certificate in the .pem file and comodo does? It’s a let’s Encrypt issue or Webuzo issue? I AM confused… because with Comodo Positive SSL all works, with Let’s Encrypt not.
@schoen Deos the .pem issued from Let’s Encrypt doesn’t contain letsencrypt X3 intermediate certificate?
Webuzo uses ACME script to issue LE cert’s, does certbot has the same behavior or it’s different ?
Certbot - which is the official client of Let’s Encrypt generates a fullchain.pem file which contains the intermediate and the certificate
As Webuzo controls how they download and configure exim they need to keep this in mind when configuring certificates
Note: Webuzo also supports multiple mail servers (not just exim) and this rule (having cert and intermediate in one file) is not the same for all email servers
Andrei
1 Like
So this seems to be an ACME issue? In that case should contact ACME support or understand if this issue can be solved… as I think is good that .pem file contain CA intermediate certificate for work also with mail server @luffy56
@ahaw021 Webuzo default mail server is Exim / Dovecot
No this is not an ACME issue.
ACME is a protocol that specifies how to obtain certificate using machine based interactions
It’s up to administrators to use the certificates in a way that is in line with their products
There is no consistent ways certificates are used by products
e.g. some like DER, some like certificates in PFX format, some like certificates in JKS format
ACME doesn’t care - it will supply a certificate that is PEM encoded that you can do what you need with it. The ACME protocol does specify that all that a CA needs to provide is a link to a certificate that is in a certain format.
Well written clients also help with this. If webuzo want to support lets encrypt fully across all their products they should account for this with their servers (nodejs etc, exim, dovecot, ftps etc)
On a more personal note: this should have been a chance to learn but my feeling is that you have tried to palm this off to Let’s Encrypt without fully understanding the roles that a CA and a service provider (softaculous) play. If you want a better experience you should be petitioning softaculous for improvements as you are a user of their product and its up to their developers and help-desk staff to create products that work seamlessly or provide knowledge base articles on how to make them work.
Andrei
Thanks @ahaw021 today a Webuzo Team member has told me there is nothing to fix, maybe there are something to fix 
they are kind and very helpful because are a human staff who always are available for help you.
I AM just an user but my topic here is also be forwarded to Webuzo Team and they are working to understand better the issue, now seems they have found it, maybe they need just to understand if they can fix the issue by including what is necessary in the.pem file that with Comodo Positive SSL all work fine so it’s maybe an issue on how Let’s Encrypt are generated and used in Webuzo… if this is not ACME script issue.
Thank you, hope Webuzo will understand and solve also this. They maybe will create a new guide for configure certificate and mail server but I think the better solution will be include the intermediate certificate in the .pem file as in the Comodo Positive SSL all is correct because is issued by Comodo.
Exim doesn’t seem to support a directive to include a chain.pem/fullchain.pem file separately.
Only:
tls_certificate = /some/file/name
tls_privatekey = /some/file/name
13 Certificate chains
The file named by tls_certificate may contain more than one certificate. This is useful in the case where the certificate that is being sent is validated by an intermediate certificate which the other end does not have. Multiple certificates must be in the correct order in the file. First the host’s certificate itself, then the first intermediate certificate to validate the issuer of the host certificate, then the next intermediate certificate to validate the issuer of the first intermediate certificate, and so on, until finally (optionally) the root certificate. The root certificate must already be trusted by the recipient for validation to succeed, of course, but if it’s not preinstalled, sending the root certificate along with the rest makes it available for the user to install if the receiving end is a client MUA that can interact with a user.
2 Likes
This and the rest of the description corresponds to what fullchain.pem already is, so the right solution would appear to be simply using fullchain.pem. it contains the host certificate followed by the intermediate certificate.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.