paulie

We often have support requests submitted via email which contain many images as part of the signature like social media links and other crap. So when we process the ticket we generally edit the ticket to delete the unnecessary images. Since upgrading, every time we try to do that we get an error as per below. Is anyone else experiencing this?

Hi Rasmus, This sounds like a network connectivity issue. If you have access to the hosting server you can try to connect using CURL. You should get a response back as per below. root@hanus:~# curl https://api.stripe.com/v1/customers { "error": { "message": "You did not provide an API key. You need to provide your API key in the Authorization header, using Bearer auth (e.g. 'Authorization: Bearer YOUR_SECRET_KEY'). See https://stripe.com/docs/api#authentication for details, or we can help at https://support.stripe.com/.", "type": "invalid_request_error" } } If there is no response looks like a firewall or routing issue

Ah, that makes sense. So you must be logged in to your Stripe Account in the same browser. Also after changing the settings, I had to log out of WHMCS, then log back in for the message to finally be removed. Thanks for the help

After upgrading to 8.11 we get a message "You must update your Stripe configuration to use the correct keys. Click here to update the configuration". Following the link it takes you to a page "Click here to activate and configure the WHMCS app in my Stripe account." This link takes you to https://marketplace.stripe.com/apps/whmcs-restricted-auth-keys and not anywhere to update the configuration. Bit confusing?

Ubuntu 22.04 comes with OpenSSL 3.0.2 however the ENOM API does comply with OpenSSL 3. The ENOM API does not send the mandatory close_notify signal which causes this error. The problem is that ENOM are not interested in fixing this, which only leaves one real solution in my opinion.

Here is the Version Information Ubuntu 22.04.3 LTS OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.16 Release-Date: 2022-01-05 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd PHP Version => 8.1.2-1ubuntu2.14

Just an update on this issue. On Ubuntu 22.04 this has been traced to the use os OpenSSL 3.0.X. There is a link that offers a resolution, ttps://github.com/openssl/openssl/issues/18866 however this uses a new setting called SSL_OP_IGNORE_UNEXPECTED_EOF which reverts to using legacy insecure renegotiation between OpenSSL to support broken and unpatched servers. The main cause of this is that the ENOM API does not send the mandatory close_notify alert on shutdown. If the client application tries to wait for the close_notify alert but the peer closes the connection without sending it, this error is generated. When this option is enabled the peer does not need to send the close_notify alert and a closed connection will be treated as if the close_notify alert was received. From a security point of view, there is nothing good about the solution above and it causes apache2 to fail starting. The ENOM API has not been updated for over 7 years and it still at version 1.0 https://api.enom.com/changelog. So it looks like development of the API has been abandoned and does not comply with OpenSSL3 standards. I have been in contact with ENOM but they are not interested and are not willing to look into the issue. So, I think it's time to ditch ENOM as a provider.

Is anyone taking responsibilty for this issue? We have Ubuntu 22.04 with CURL 7.81.0 and the ENOM module is defective. curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.16 Release-Date: 2022-01-05 The workaround, which is to roll back to an insecure version of CURL is not an option. so when will a proper solution be implemented. Failing that we may need to ditch ENOM as a provider.

I went to update 8.2.1 to 8.3 today and am getting the message as per attachement. My confidence level just fell by 50%.

I had to do a manual update in the end which processed the update fine. Interesting no problems reported in the tblupdatelog

I held off on performing an upgarde a few days ago and I decided to perform upgrade today. This is what I got after about 15sec Then after trying again as requested I got Then after removing install folder i get No my WHMCS is down and out and completely broken. Any suggestions?

Hi John, No I cant say that I have, but was able to resolve by enabling, then disabling. Thanks for your response.

We had Application Links for cPanel turned off. We just noticed that after upgrading to WHMCS8 all our cPanel servers have it enabled again. Just checked the WHMCS settings and its says that its off, but all our cPanel servers have it enabled. What do we do?

Thanks Jay, I thought it may be the case. I was just getting a bit anxious as active support for PHP v7.3 ends in 4 months. Paul

Hi, I am trying to do a new install on Ubuntu 20.04 . This comes with PHP 7.4.3. Ioncube 10.4.0 supports PHP 7.4 and my php.ini as as per below zend_extension = /usr/lib/php/20190902/ioncube_loader_lin_7.4.so But I am getting segmentation faults. I have tested other LAMP packages and phpinfo for any configuration issues and work fine, so I am guessing the Ioncube loader and WHMCS are not ready yet? Has anyone else tried this? Paul