multiserver ispconfig system. 1 webserver also runs the ispconfig interface, another 2 webservers. dedicated mailserver. ispconfig is 3.1.13 roundcube (1.3.6) is installed on each webserver and on the mailserver. all connect to the same roundcube db hosted on the mailserver. default php is 7.2 on ubuntu 18.04, php5.6 and 7.3 installed as additional php's. (all installed using ondrej repo) all roundcube configs are identical. we have a geotrust wildcard certificate for our own domain, the same certificate is used on all servers, located in /usr/local/ispconfig/interface/ssl all ftp/postfix/dovecot certificates link back to these certificate files. openssl_cafile is set to /etc/ssl/certs/ca-certificates.crt in all php.ini files the ca-certificates.crt file is identical on all servers webmail access was working fine on all servers. yesterday I installed php7.4 as an additional php on all 3 webservers. process was identical on each server. webmail is now working fine on the server that runs the ispconfig interface, and on one of the other webservers, on the 3rd webserver it isn't working. I can get to the login screen fine, but when logging in all I get is 'failed to connect to imap server', a customer claims they are getting 'failed to connect to storage server', but I can't replicate that one. I've double-checked, and triple checked everything, and I can't find anything different in any configs on this server. this is the error logged by roundcube: Code: [03-Dec-2019 09:22:58 UTC] PHP Warning: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed in /usr/share/roundcube/program/lib/Roundcube/rcube_imap_generic.php on line 1027 [03-Dec-2019 09:22:58 +0000]: <umr9uq87> IMAP Error: Login failed for [email protected] from 81.140.13.15. Unable to negotiate TLS in /usr/share/roundcube/program/lib/Roundcube/rcube_imap.php on line 196 (POST /webmail/?_task=login&_action=login) I've removed tls:// from the default_host setting in roundcubes config.inc.php and the login works, but sending email fails. I don't want to remove tls from the smtp server, or start submitting to port 25. i'm at a complete loss of what else to look at now, I have no idea why it's only affecting this one server, and i'm unable to find any differences. anyone have any ideas? suggestions..
Can you run older PHP ? update-alternatives --config php update-alternatives --config php-cgi systemctl reload apache2.service
i'd already set php back to 7.2 using update-alternatives. I did that right after first installing php7.4, didn't do php-cgi though. just done them both again and reloaded apache, so this is what update-alternatives comes up with now: Code: update-alternatives --config php There are 5 choices for the alternative php (providing /usr/bin/php). Selection Path Priority Status ------------------------------------------------------------ 0 /usr/bin/php7.4 74 auto mode 1 /usr/bin/hhvm 40 manual mode 2 /usr/bin/php5.6 56 manual mode * 3 /usr/bin/php7.2 72 manual mode 4 /usr/bin/php7.3 73 manual mode 5 /usr/bin/php7.4 74 manual mode Press <enter> to keep the current choice[*], or type selection number: update-alternatives --config php-cgi There are 4 choices for the alternative php-cgi (providing /usr/bin/php-cgi). Selection Path Priority Status ------------------------------------------------------------ 0 /usr/bin/php-cgi7.4 74 auto mode 1 /usr/bin/php-cgi5.6 56 manual mode * 2 /usr/bin/php-cgi7.2 72 manual mode 3 /usr/bin/php-cgi7.3 73 manual mode 4 /usr/bin/php-cgi7.4 74 manual mode still getting the same imap/ssl errors.
nope. did install it, but it's not enabled. Code: apt-get -y install libapache2-mod-php7.4 php7.4 php7.4-common php7.4-gd php7.4-mysql php7.4-imap phpmyadmin php7.4-cli php7.4-cgi libapache2-mod-fcgid apache2-suexec-pristine php-pear mcrypt imagemagick libruby libapache2-mod-python php7.4-curl php7.4-intl php7.4-pspell php7.4-sqlite3 php7.4-tidy php7.4-xmlrpc php7.4-xsl memcached php-memcache php-imagick php-gettext php7.4-zip php7.4-mbstring php-soap php7.4-soap apt-get install php7.4-fpm a2enconf php7.4-fpm service php7.4-fpm restart in /etc/apache2/conf-enabled: Code: apache2-doc.conf@ localized-error-pages.conf@ php5.6-fpm.conf@ php7.4-fpm.conf@ security.conf@ charset.conf@ other-vhosts-access-log.conf@ php7.2-fpm.conf@ phpmyadmin.conf@ serve-cgi-bin.conf@ httpoxy.conf@ pagespeed_libraries.conf@ php7.3-fpm.conf@ roundcube.conf@ in /etc/apache2/mods-enabled: Code: access_compat.load authn_file.load dav_fs.load fcgid.load mime.load python.load ssl.load actions.conf authz_core.load deflate.conf filter.load mpm_event.conf reqtimeout.conf status.conf actions.load authz_host.load deflate.load geoip.conf mpm_event.load reqtimeout.load status.load alias.conf authz_user.load dir.conf geoip.load negotiation.conf rewrite.load suexec.load alias.load autoindex.conf dir.load headers.load negotiation.load setenvif.conf auth_basic.load autoindex.load env.load http2.load proxy.conf setenvif.load auth_digest.load dav.load expires.load include.load proxy.load socache_shmcb.load authn_core.load dav_fs.conf fcgid.conf mime.conf proxy_fcgi.load ssl.conf ] so all the php-fpm#.# enabled, and the mpm_event worker enabled. same install as on the other 2 webservers, which don't have any problems.
Are your certificate still ok ? Check /etc/dovecot/dovecot.conf ssl = yes ( or ssl = required ) Possible rerun ispconfig and "reconfigure services" to fix config for Dovecot ? PHP upgrade should not break Roundcube with that error message.
dovecot.conf is identical to it's counterpart on working servers certificate was working prior to php7.4 install. certificate files (pem, bundle, crt, csr & key) are unchanged and identical to certificate files on working servers.
To be sure, put a info.php file in the folder where phpmyadmin is located, call it in the browser and check which PHP version is used to process phpmyadmin files.
ok. this is getting stranger. I put phpinfo.php into the phpMyAdmin folder (/usr/share/phpMyAdmin) this is the server where webmail isn't working: Code: System Linux shared-host-ireland-02 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 Build Date Nov 28 2019 07:27:06 Server API FPM/FastCGI Virtual Directory Support disabled Configuration File (php.ini) Path /etc/php/7.4/fpm Loaded Configuration File /etc/php/7.4/fpm/php.ini Scan this dir for additional .ini files /etc/php/7.4/fpm/conf.d and this is the start of phpinfo results on the server where webmail is still working... Code: System Linux shared-host-ireland-01 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 Build Date Nov 28 2019 07:27:06 Server API FPM/FastCGI Virtual Directory Support disabled Configuration File (php.ini) Path /etc/php/7.4/fpm Loaded Configuration File /etc/php/7.4/fpm/php.ini Scan this dir for additional .ini files /etc/php/7.4/fpm/conf.d
When you enable a php-fpm .conf it specifies the default php interpreter for the system - you should only enable the version which you want to be used, not all of them. I would have guessed 5.6 was in use since it would load first, but you show 7.4, so it must be the one loaded last which is in effect. Fix that, then look into your (open)ssl library versions/settings if it still doesn't work; I have not checked, but 7.4 sure may require newer tls version/parameters and could cause a failure if incompatible with your server.
ah.. ok.. I've always thought each php#.#-fpm needed to be enabled. I guess the default one should then be left as the one first installed to the system.
ok, all working on that server now. left the default php-fpm version as 7.2 still not sure why it all worked without problems on the other servers... guess I just got lucky on them. i'll leave them as they are until tomorrow now. don't want to risk breaking anything else today. thanks guys, would still be bashing my head into a wall without the help.
Just extra info, I did look into this and see some SSL changes including: Added TLS 1.3 support to streams including new tlsv1.3 stream. Added openssl_x509_verify function. but nothing deprecated immediately looks to be related. No idea why your other servers worked (maybe apache didn't get restarted?), but glad this one is good now.
