• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue SSL Certificate Issues + Ioncube

S

safemoon

Basic Pleskian
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: <br>The file <strong>/var/www/vhosts/example.com/httpdocs/index.php</strong> 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
github.com

'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 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.
 
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
 
It seems like the curl (http) get requests that are done on PHP level, can not identify/trust the new SSL certificates
 
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 talk.plesk.com
 
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 talk.plesk.com
Click to expand...
so the resolution is to renew the server's root certificates? if yes how? i am on ubuntu 20
 
I think it should be the same as in Debian, not perfectly sure, but normally these two are quite similar.
 
Peter Debik said:
I think it should be the same as in Debian, not perfectly sure, but normally these two are quite similar.
Click to expand...
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
Click to expand...

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.
Click to expand...
This is a complicated part for me, can I have a better explanation please?
 
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.
 
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.
Click to expand...
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...
 
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)
 
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)
Click to expand...
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.
 
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:
support.plesk.com

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 support.plesk.com
 
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
}
}
}
 
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
 
- 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?
 
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.
 
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?
 
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.
 
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: <br>The file <strong>/var/www/vhosts/example2.com/httpdocs/index.php</strong> could not be decoded as an encoding key was not found. in Unknown on line 0'
 
You must log in or register to reply here.

Similar threads

D
Issue Automatic renewal via SSLit doesn't work for wildcard certificates
Replies
0
Views
483
D3nnis3n
D
K
Question How do I restore an SSL Certificate on a different server?
Replies
4
Views
454
Kroptokin
K
Hangover2
Forwarded to devs SSL It! breaks renewal and usage of Let's Encrypt wildcard certificates when subdomains are involved
2
Replies
28
Views
5K
marcoherzog
M
B
Issue SMTP not working: certificate verify failed
Replies
2
Views
217
Bitpalast
Bitpalast
Azurel
Resolved Mail for "Let`s Encrypt certificates for ***** have been issued/renewed" missing?
Replies
2
Views
257
Azurel
Azurel
Back
Top