How the server must be configured to be able to connect to mailbox via php script

Question

I have spent 8 hours on this, and still can't get it right. My situation: My server is running on Linux xrm 2.6.32-5-amd64; In console: openssl s_client -connect ns1.example.com:995 works flawlessly, successful connection. But when i execute this script:

a)

$res = imap_open("{ns1.example.com:993}",
"user@example.lv", "password");

Response is: Array ( [0] => [CLOSED] IMAP connection broken (server response) )

b)

$res = imap_open("{ns1.example.com:993/ssl}",
"user@example.lv", "password");

Response: Array ( [0] => Certificate failure for ns1.example.com: self signed certificate: /CN=ns1.example.com/emailAddress=ssl@ns1.example.com )

Is it connected with the fact that, this script is under drupal directory? And it uses different php.ini than server does? Even though when i execute php_info(), it says that imap and imap/ssl is enbaled.

i have tried all the imap_open() flags, but still no luck.

I even can't connect to a standart gmail mailbox. Please get me out of here.

Answer 1

How the server must be configured to be able to connect to mailbox

It depends. The server can use a certificate signed by a public CA if the CA is a trust anchor on the client. The server can use a certifcate signed by a non-public CA used in a private PKI as long as the client uses it as a trust anchor.

The server can also use a self signed certificate if the client trusts the certificate. See Marc B's comments.

In the case of the mail protocols, opportunistic encryption is the next big push. As such, your script should be using DNSSEC and DANE to fetch the certificate from DNS's CERT resource record. See, for example, RFC 6944 and RFC 7218.

As a fallback, the script should be using security diversification techniques like Trust on First Use (TOFU), certificate pinning or public key pinning. Peter Gutmann talks about it in his book Engineering Security. (The other choice - disable validation - is really bad).

---

... via php script

This is likely your problem. Its not robust and it does not do the right thing.

---

In console: openssl s_client -connect ns1.example.com:995 works flawlessly

Probably not. Are you certain about that? I would have expected s_client to return non-0. At minimum, you would have needed the -CAfile option to tell OpenSSL what certificate to use as a trust anchor.

Also, OpenSSL prior to OpenSSL 1.1.0 does not perform hostname matching. So the name in the certifcate could be anything and s_client would accept it as long as its signed by a CA (modulo the -CAfile option). That mistake does not show up anywhere. You have to manually inspect the end entity certificate to discover the problem (if its present).