When roundcube connects to an imap or smtp server it's being a client therefore I think it would be logical that the client needs to validate the chain. When you are connecting to roundcube webinterface you are connecting to the server serving it, in that setting the browser is the client and the apache/nginx being the server. It's all a matter of who is the client and who is the server perspective as in who needs to validate and who needs to show they have a valid chain.
On 03/03/2018 12:44 PM, Reindl Harald wrote:
Am 03.03.2018 um 12:29 schrieb Reindl Harald:
Am 03.03.2018 um 10:08 schrieb Maarten:
If I understand ssl correctly I don't see the point to putting fullchain.pem letsencrypt there, because of the following. Your browser has the Root certificates installed, a php application does not. So when
you go to a webpage using letsencrypt certificates . You will see something like this:
DST Root CA X2 --> Root Certificate in browser
Let's encrypt Authority X3 -->
webmail.yourdomain.com --> your certificate
So the web browser uses the Root Certificate to verify the chain of certificates to be valid. As far as I know a php application has no way knowing if the service it's connecting to is using a valid ssl chain, I don't know enough about php to be sure about this but sounds correct. If I am wrong about this someone may correct me about this and explain it to me how this works in php.
exactly the same way as on the browser side no idea why you think PHP is special here
"As far as I know a php application has no way knowing if the service it's connecting to is using a valid ssl chain" is pure bullshit - get a proper maintained operating system and you have all working out-of-the-box
http://php.net/manual/en/migration56.openssl.php
All encrypted client streams now enable peer verification by default. By default, this will use OpenSSL's default CA bundle to verify the peer certificate. In most cases, no changes will need to be made to communicate with servers with valid SSL certificates, as distributors generally configure OpenSSL to use known good CA bundles
it's using even the same ca-bundle than everything else on the system, the ca-bundle from mozilla - frankly do you think the php-devleopers are idiots and enable verification by default when it won't work on any reasonable server?
[harry@srv-rhsoft:~]$ rpm -q --filesbypkg openssl-libs-1.1.0g-1.fc27.x86_64 openssl-libs /etc/pki/tls openssl-libs /etc/pki/tls/certs openssl-libs /etc/pki/tls/misc openssl-libs /etc/pki/tls/openssl.cnf openssl-libs /etc/pki/tls/private ....
[harry@srv-rhsoft:~]$ ls /etc/pki/tls/certs total 4.0K -rw-r--r-- 1 root root 2.5K 2017-11-06 09:24 Makefile lrwxrwxrwx 1 root root 49 2018-02-06 14:48 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem lrwxrwxrwx 1 root root 55 2018-02-06 14:48 ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
[harry@srv-rhsoft:~]$ rpm -q --file /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem ca-certificates-2018.2.22-1.0.fc27.noarch
[harry@srv-rhsoft:~]$ rpm -q --info ca-certificates-2018.2.22-1.0.fc27.noarch Name : ca-certificates Version : 2018.2.22 Release : 1.0.fc27 Architecture: noarch Install Date: Thu Feb 8 09:43:10 2018 Group : System Environment/Base Size : 974873 License : Public Domain Signature : RSA/SHA256, Tue Feb 6 14:57:19 2018, Key ID f55e7430f5282ee4 Source RPM : ca-certificates-2018.2.22-1.0.fc27.src.rpm Build Date : Tue Feb 6 14:48:33 2018 Build Host : buildvm-ppc64le-04.ppc.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : https://fedoraproject.org/wiki/CA-Certificates Summary : The Mozilla CA root certificate bundle Description : This package contains the set of CA certificates chos
-
Maarten