OpenCart Community

https://www.ups.com/ups.app/xml/Rate works fine, I've just tested it with 2.3.0.2. However, the documentation does suggest that it should be changed to: https://onlinetools.ups.com/ups.app/xml/Rate It could be they are blocking access to the old URL for some locations.

The test URL is the same. Do you get any results in test mode?

What do you get in your logs if you use the new URL (https://onlinetools.ups.com/ups.app/xml/Rate)?

Old (stock) URL in test mode, no logs, no errors
In production, it errors out (internal server error) - Permission denied

New URL https://onlinetools.ups.com/ups.app/xml/Rate
In test mode, no logs, no errors. Says there is no shipping option available
In production, same thing. Says there is no shipping option available

Happening on both a live website and a fresh install (I just downloaded 2.3.0.2 and installed it again today)

-- Okay I just looked through the Error Logs (not in the admin but Error Logs folder)


[Tue Jan 30 05:37:43 2018] [warn] [client 68.200.201.xxx] mod_fcgid: stderr: PHP Fatal error: Call to a member function getElementsByTagName() on null in /var/www/vhosts/demo2.domain.com/httpdocs/catalog/model/extension/shipping/ups.php on line 243, referer: http://demo2.domain.com/index.php?route=checkout/cart

This is line 243

$response = $rating_service_selection_response->getElementsByTagName('Response')->item(0);

Looks like the module is not set up correctly. What are your UPS module settings set to?

What do you get in your logs if you use the new URL (https://onlinetools.ups.com/ups.app/xml/Rate) for UPS DATA SENT: and UPS DATA RECV:?

Pickup method - Daily Pickup
Customer Class code - 01
Shipping Origin Code - US Origin
Origin City - Miami
Origin State - FL
Origin Country - US
Origin Zip - 33156
Test Mode - no
Query Type - Residential
Service - UPS Standard
Enable Ins - yes
Display delivery weight - no
Weight Class - Pound
Length Class - Inch
Dimensions - 1 x 1 x 1
Tax class - none (tried both none and taxable goods)
Geo Zone - All zones
Status - Enabled
Debug Mode - enabled

--I get no logs (from the admin) when using the new URL and no error messages, it just says 'No shipping option' when I check out
When I FTP and download the error_log I get:
mod_fcgid: stderr: PHP Fatal error: Call to a member function getElementsByTagName() on null in /var/www/vhosts/website.com/httpdocs/catalog/model/extension/shipping/ups.php on line 243, referer:

** I did receive an email from someone about TLS upgrade, not sure if this has anything to do with it:
Data Security Upgrade: UPS
Effective 12/31/2017, UPS will only accept TLS 1.1 and TLS 1.2 security protocols.
https://www.ups.com/us/en/help-center/t ... urity.page
WorldShip Message Center: UPS

I did check my SSL and it is using 1.1 and 1.2, (got an A- when checking ssllabs.com) not sure how to force 1.1 or 1.2

Have you tried selecting all the services? I think UPS Standard is an international service.

If you want to test the connection to the UPS server is working correctly, so you know you have the correct version of TLS, try something like the following. Put in in a file like upstest.php run it on your server by going to it in a web browser. Try it for all the UPS URLs (old, new and test). Remember to delete the php file once you have finished testing.
You should see something like this if it worked. Similar to what you see if you go to the URLs directly in a web browser.
Service Name: Rate
Remote User: null
Server Port: 443
Server Name: onlinetools.ups.com
Servlet Path: /Rate
upstest.php:6:boolean true
upstest.php:7:string '' (length=0)

Okay I hope this is getting somewhere:

Using old URL: http://www.ups.com/ups.app/xml/Rate - Not sure

�m���@�w���KQ7SoP0��s�'Ԝ 8E�^�թ���W�E睼e1dz��=&;��I,����~�2�/<�Δ�4�bX�ӕ,V����d�Uq�ʞ�Wz�L���������GVH�P���1hՂ�PR�~l|�m׈]�/�ymp��Z��/ʱ/47L�D@hG�d����t��bool(true) string(0) ""

Using new : https://onlinetools.ups.com/ups.app/xml/Rate

bool(false) string(17) "SSL connect error"

Using test : https://wwwcie.ups.com/ups.app/xml/Rate

bool(false) string(17) "SSL connect error"

So looks like since the UPS force of 1.1 and 1.2 SSL, then is there somewhere I can change the code?
Or is it something else?

It's a server configuration problem. You need to ask your host if your server supports TLS 1.2 or 1.2 using PHP curl.

I just did a test and my server is running 1.0, 1.1 and 1.2 (from ssllabs.com)

TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes

I would force TLS 1.2 on the server, but it's a VPS and not sure if it's going to have any effect on any other website I have.

I was looking at the code in the ups.php and cURL and looks like there is a way to force it to use TLS 1.2?
curl_setopt($curl, CURLOPT_SSLVERSION, 6);

gives me this error:
curl_setopt() expects exactly 3 parameters, 4 give in

I was using this to get some info on how to force TLS 1.2
http://php.net/manual/en/function.curl-setopt.php

Does anyone know how to get this to work? I was hoping to try this first

I discovered the new TLS 1.2 UPS requirement also and ssllabs.com shows 'TLS 1.2 Yes' for my site also, however, I read that for TLS 1.2 to work with PHP the PHP version needs to be 5.5.19 or higher and the Curl version needs to be 7.34.0 or higher. My site's current PHP version is 5.2 and I am working with my host to upgrade it to 5.6. I will let you know how it goes after the PHP version upgrade.

humble1 -
I saw the same thing.
I found a link about forcing TLS 1.1 or 1.2 from this site:https://stackoverflow.com/questions/301 ... ng-in-curl
But it does require curl 7.34.0 to do so.

I have 2 different servers that have PHP 5.4.16 and 7.0.27, but both servers have different curl versions, one has 7.19.7 and other has 7.29.0
never updated curl before but I may need to learn.

I'm interested in knowing what you find.

I found that same resource a few days ago also and tried forcing TLS 1.2 using "curl_setopt ($setuploginurl, CURLOPT_SSLVERSION, 6);" in the ups.php file. Doing so did not help though. That is when I researched further and found out about the PHP and Curl version parameters for TLS 1.2.

The site I am having this problem with is on a shared hosting service where I can not change the PHP or Curl versions myself. I had a chat session with the site's web host and they said the PHP and Curl version could be updated, and a support ticket was started with that request.

Right now I am waiting for a reply to the support ticket hopefully saying the site has been updated to 5.6 and 7.34.0. Once I get this update done to the site I will share the results and hopefully, this will solve the sites UPS rates and functionality problem.

Well it sounds like we are both on the right track

I am on a VPS and I can pretty much change anything I want, although I'm a windows person so Linux is a little foreign to me
I have a new VPS that I got on Dec that is fresh so I can try updating curl if it's not that difficult

The other option is what 'ADD Creative' said above and that is removing TLS 1.0 and that should force only TLS 1.1 and 1.2
Which might not be a bad option since even PayPal is now requiring only 1.1 and 1.2 (I think)

If what you're doing works, then I'll upgrade my curl as well, if not then maybe the TLS option

What OS are you using and control panel?
I'm on Centos 7 and Plesk

I do not know what the OS is, however, I do know that the control panel is Hsphere.

I figured out how to upgrade to PHP 5.6 myself by going to the Hsphere control panel's "Web Services" page and turning off "PHP", and then turning on "PHP Advanced", and then clicking on the PHP Mode "Add" button, and then selecting PHP 5.6.32.

After that UPS now works on my site. Problem is 100% solved and fixed.

In the ups.php file I have the live rate URL changed to https://onlinetools.ups.com/ups.app/xml/Rate since that is what UPS now specifies.

I had curl_setopt ($ch, CURLOPT_SSLVERSION, 6); added to the ups.php file and everything worked with it in there. I then removed curl_setopt ($ch, CURLOPT_SSLVERSION, 6); from the ups.php file and checked again and everything works without it, so I left it out of the file since it is not needed.

I do not know what Curl version the server is running, however since everything now works I don't have to worry about that anymore.

Do you know what version of Curl you are running now?

The CURL version will be mentioned in the error handler of PHP, and added by the Industry standards as an error, when it is too extended between PHP and CURL. The .c module server library files are already handled whenever two different versions are too far away. In this case, using PHP v5.6.32 is the right way to go since Opencart already requires the minimum PHP version of v5.6 nowadays in anyhow.

humble1 - could you do me a favor and let me know what version of curl you have now after the upgrade?

I just put this code on a blank php page: (called it phpinfo.php) Sorry if you know how to do this already
<?php
phpinfo();
?>

straightlight - I'm not that familiar with linux and learning as I go.
I have tried several versions of PHP, 5+ and 7 and both have curl 7.19.7 on 1 server
which is odd as I thought that curl is tied to PHP versions, but I guess not.

I did update both servers, 1 is still stuck at 7.19.7 and the other is at 7.29 (close but not sure if this is enough)

Jimbo505 - Thanks for sharing how to pull up the phpinfo page. I had no idea how to find the curl version before that.

I just pulled up the phpinfo page and the Curl version is: 7.47.0

straightlight - I'm not that familiar with linux and learning as I go.
I have tried several versions of PHP, 5+ and 7 and both have curl 7.19.7 on 1 server
which is odd as I thought that curl is tied to PHP versions, but I guess not.

I did update both servers, 1 is still stuck at 7.19.7 and the other is at 7.29 (close but not sure if this is enough)

If you are not a 100% sure that the upgraded libraries you affected are enough, you'd be right. Followed is the complete instructions that also includes the OpenSSL upgrade along with CURL and PHP: https://stackoverflow.com/questions/351 ... sl-version . Granted, the top suggestion talks about PayPal. Although, the post below also suggest the steps to upgrade all-three all together including OpenSSL.

humble1 - you're welcome and thanks for helping out will all of this!!

straightlight - I know it's the duty of the website owners/hosting companies to handle all of this but was hoping that updating Plesk would take care of all of this. Although patching my windows servers was just as bad with registry edits and such.

I'm hoping I can update my 2nd server (new) as there is no one on it with the latest curl, crossing my fingers.

So in the end, should there be a sticky, post or update to Opencart to let people know the new URL for UPS and making sure Curl is a set version?

Updating Plesk would be insufficient in this case since OpenSSL is still a separate operation to complete in order to be properly adapted with PHP and CURL for PCI Compliance / RFC standards.

So in the end, should there be a sticky, post or update to Opencart to let people know the new URL for UPS and making sure Curl is a set version?

I would rather suggest to point this topic from the Pull Requests section of the Github Opencart website as your solution implies server modifications rather than Opencart modifications even though Opencart already provides the UPS extension solution to its users.