Issue SSL Certificate Issues + Ioncube

safemoon · Oct 2, 2021

Hello Pleskians,

So after the Let's Encrypt issue (certificates expired) im having issues with creating a proper certificate, I tried reissuing a new lets encrypt certificate, i even paid for the positive ssl but i still cant get it to work.

Here is my problem
1) I have PHP applications encoded with Ioncube on many different servers.
2) I use the external key method on Ioncube to encode my PHP Apps
3) Since the 30th of Sept i am getting the following error
AH01071: Got error 'PHP message: PHP Warning: main(): SSL operation failed with code 1. OpenSSL Error messages:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in on line 0PHP message: PHP Warning: main(): Failed to enable crypto in on line 0PHP message: PHP Fatal error: The file /var/www/vhosts/example.com/httpdocs/index.php could not be decoded as an encoding key was not found. in Unknown on line 0'
4) This is because the runtime path to the encoding key is on example 2 understand – Interesting articles to read. Free tutorials and HOW-TOs and it is not accessible, although from the browser it is accessible
5) I could not even make a GET request through postman because i was getting an error "certificate expired". However after the latest update it works on Postman

'Certificate has expired' error for Let's Encrypt certificates (DST Root CA X3 issued) · Issue #10338 · postmanlabs/postman-app-support

Is there an existing issue for this? I have searched the existing issues Describe the Issue I've seen that this problem has happened before: #8589 The problem started today. Postman says the SLL ce...

github.com

2 days passed and i still cant get the SSL to work properly on the example2.com domain where i have the encoding keys. Which makes all of the apps not to work.

Is there any workaround to this? I tried many SSL tests and they seem fine, but Ioncube loader still can not read the encoding key because of the ssl certificate.

safemoon · Oct 2, 2021

4) This is because the runtime path to the encoding key is on https:// example2.com/folder/file.jpg and it is not accessible, although from the browser it is accessible

safemoon · Oct 2, 2021

It seems like the curl (http) get requests that are done on PHP level, can not identify/trust the new SSL certificates

Bitpalast · Oct 2, 2021

Have you seen this thread and the proposed solutions for different operating systems?

Resolved - Lets Encrypt root certificate expiration on 30 September 2021

Asking for some guidance and knowledge please. Certificate chains are among the few things I haven't delved into much so far. The Lets Encrypt root certificate expiration on 30 September 2021. Anyone still running Plesk on CentOS 7 servers are apparently affected as that OS still uses OpenSSL...

talk.plesk.com

safemoon · Oct 2, 2021

Peter Debik said:
Have you seen this thread and the proposed solutions for different operating systems?

Resolved - Lets Encrypt root certificate expiration on 30 September 2021

Asking for some guidance and knowledge please. Certificate chains are among the few things I haven't delved into much so far. The Lets Encrypt root certificate expiration on 30 September 2021. Anyone still running Plesk on CentOS 7 servers are apparently affected as that OS still uses OpenSSL...

talk.plesk.com

so the resolution is to renew the server's root certificates? if yes how? i am on ubuntu 20

Bitpalast · Oct 2, 2021

I think it should be the same as in Debian, not perfectly sure, but normally these two are quite similar.

safemoon · Oct 2, 2021

Peter Debik said:
I think it should be the same as in Debian, not perfectly sure, but normally these two are quite similar.

For Debian use:
sudo cp /etc/ca-certificates.conf /etc/ca-certificates.conf.orig
sudo nano /etc/ca-certificates.conf
Change “mozilla/DST_Root_CA_X3.crt” in “!mozilla/DST_Root_CA_X3.crt” an save
sudo update-ca-certificates

I went to do the above steps but It was already like that. Updated the certificates, still no luck.

If the problem persist, regenerate your certificates and force in your Apache config file for your website the new chain certificate (add SSLCertificateChainFile path to SSL options). You can find it in /opt/psa/var/modules/sslit/etc/live/website/chain.pem or /opt/psa/var/modules/letsencrypt/etc/live/website/chain.pem.

This is a complicated part for me, can I have a better explanation please?

Bitpalast · Oct 2, 2021

I think for the last step on a Plesk system it could be sufficient to manually renew the SSL certificate for the affected domain (click on the "renew" option in SSLIt extension). Not tested, but I'd guess that this will replace the chain, too.

safemoon · Oct 3, 2021

Peter Debik said:
I think for the last step on a Plesk system it could be sufficient to manually renew the SSL certificate for the affected domain (click on the "renew" option in SSLIt extension). Not tested, but I'd guess that this will replace the chain, too.

Tried it already, but doesnt do the trick.
The sites of my webapplications are still down (500 error) because they can not access the encoding key on my licensing server...

Bitpalast · Oct 3, 2021

Have you verified that the cause is indeed a wrong certificate chain? For example: Have you wget the file in question locally from the Linux command line? What is the output of e.g.
# wget https:// example2.com/folder/file.jpg
(without the space between https:// and the rest)

safemoon · Oct 3, 2021

Peter Debik said:
Have you verified that the cause is indeed a wrong certificate chain? For example: Have you wget the file in question locally from the Linux command line? What is the output of e.g.
# wget https:// example2.com/folder/file.jpg
(without the space between https:// and the rest)

https:// example2.com/folder/file.jpg
Resolving example2.com (example2.com)... 92.xxx.xx.xxx
Connecting to example2.com (example2.com)|92.xxx.xx.xxx|:443... connected.
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Unable to establish SSL connection.

Bitpalast · Oct 3, 2021

This could point to a different cause. In a first guess, the server might not have newer TLS versions enabled, but only TLS version 1.0, but not 1.2, 1.3. Have you checked that your server supports the new TLS versions?
# plesk sbin sslmng --show-config
More information:

How to enable/disable TLS protocol versions in Plesk for Linux

Applicable to: Plesk for Linux Question How to enable/disable TLS protocol versions in Plesk for Linux? Answer Connect to a Plesk server via SSH. Use the plesk bin server_pref utility to man...

support.plesk.com

safemoon · Oct 3, 2021

The licensing server is quite new so i guess it is compatible

Command Result

{
"full": {
"all": {
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH",
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"cipher_server_order": true
},
"courier": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"mail-imap-pop3": {},
"postfix": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"mail": {
"cert": "/opt/psa/var/certificates/scfgwwQI3",
"certificate": true
},
"autoinstaller": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"nginx": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"sw-cp-server": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"mail-smtp": {},
"apache": {
"ciphers": "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256",
"protocols": [
"TLSv1.3"
]
},
"dovecot": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"strong_dh": true,
"protocols": [
"TLSv1.2"
],
"dhparams_size": 2048
},
"proftpd": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
}
},
"effective": {
"qmail": {
"cert": "/opt/psa/var/certificates/scfgwwQI3",
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH",
"certificate": true,
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"cipher_server_order": true
},
"courier": {
"cert": "/opt/psa/var/certificates/scfgwwQI3",
"certificate": true,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"postfix": {
"cert": "/opt/psa/var/certificates/scfgwwQI3",
"certificate": true,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"dovecot": {
"certificate": true,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"cipher_server_order": true,
"cert": "/opt/psa/var/certificates/scfgwwQI3",
"strong_dh": true,
"protocols": [
"TLSv1.2"
],
"dhparams_size": 2048
},
"autoinstaller": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"nginx": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"sw-cp-server": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"apache": {
"ciphers": "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256",
"protocols": [
"TLSv1.3"
],
"cipher_server_order": true
},
"proftpd": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
}
}
}

safemoon · Oct 3, 2021

The server (Ubuntu 14) where few of the non working applications run is throwing error on that command

Warning: Current locale is unusable. Using 'C' instead.
ERROR: Unrecognised arguments: /usr/local/psa/admin/sbin/sslmng --show-config.
Run sslmng --help to view help.
exit status 2

Bitpalast · Oct 3, 2021

- Ubuntu 14 is unsupported by Plesk Obsidian. It's not a problem, if the server you are connecting to is an Ubuntu 14 server, but it sure is a problem if your Plesk is old and running on an Ubuntu 14.
- The TLS protocol needs to be supported on the requesting server, the one that throws the error on the wget command. Have you actually verified that your server, the one from where you are trying to connect, supports TLS version 1.2 or newer?

safemoon · Oct 3, 2021

The server where the php apps are running is Ubuntu 14 (lets name it Server #1)
The server where i have the encoding key (license server) is Ubuntu 20 (lets name it Server #2)
I have one more server with Ubuntu 18 (lets name it Server #3)

When i do wget on server #2 from server #1 it fails (unable to establish ssl connection)
When i do wget on server #2 from server #3 it does NOT fail (it saves the index.html file)
When i do wget on server #1 from server #3 or server #2 it throws 500 error because ioncube can not decode the apps because it can not get the encoding key from server #2

The command "# plesk sbin sslmng --show-config" throws an error on server #1 so i can not check. I guess that it means its not supported?
I hope its clear now.

Bitpalast · Oct 3, 2021

Supported operating systems for Plesk Obsidian:

Software Requirements for Plesk Obsidian

Read all about the software requirements, specifications and other important details to take full advantage of Plesk Obsidian.

docs.plesk.com

safemoon · Oct 3, 2021

Ok thanks, so the only solution is to upgrade Ubuntu.
Is there any tool on plesk that can guarantee that there will be no losses/failures during upgrade? (restore/backup/migration tool for domains)

Because i have many clients that run on server #1, how can i upgrade without problems?

Bitpalast · Oct 3, 2021

It is not possible to do a safe in-place upgrade from Ubuntu 14. Instead, use Plesk Migrator to migrate all content to a system with a newer OS and Plesk.

safemoon · Oct 3, 2021

It seems like this will not solve the problem, I encoded a file with ioncube and added it to my ubuntu 18 server, the license is still on the ubuntu 20 server.

I get the following error.

When i do the wget command from the ubuntu 18 server to the licensing server, it is successful. I really dont know what is going on here.
I am experiencing these issues since the expired LetsEncrypt certificate...

AH01071: Got error 'PHP message: PHP Warning: main(): SSL operation failed with code 1. OpenSSL Error messages:\nerror:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version in on line 0PHP message: PHP Warning: main(): Failed to enable crypto in on line 0PHP message: PHP Fatal error: The file /var/www/vhosts/example2.com/httpdocs/index.php could not be decoded as an encoding key was not found. in Unknown on line 0'

Issue SSL Certificate Issues + Ioncube

Basic Pleskian

Basic Pleskian

Basic Pleskian

Plesk addicted!

Basic Pleskian

Plesk addicted!

Basic Pleskian

Plesk addicted!

Basic Pleskian

Plesk addicted!

Basic Pleskian

Plesk addicted!

Basic Pleskian

Basic Pleskian

Plesk addicted!

Basic Pleskian

Plesk addicted!

Basic Pleskian

Plesk addicted!

Basic Pleskian

Similar threads