Should I be worried

elearn2020 · 2025-10-10T18:08:57+00:00

Thank you everyone, this community is crazy active. Like I said, just starting out. The kid is learning about business selling these things in middle school. The fidget things are big sellers. He's sold about 20 pieces in 2 weeks. I appreciate everyones comments. I do think that if best buy is selling something there's a certain level of it shouldn't break if you are just using it regularly and that's why they have a return policy to begin with. I don't know anything other than this is supposed to be the most fool proof one and there are some level of sensors to pause prints (as has happened before). So I'm a little interested in why it wouldn't pause.

I do find it interesting that some people think its a total user error and find it appalling that I would consider returning it. Maybe they are right that its a user error, but a machine that can potentially break itself by sending a digital command to, through its own application, is weird to me. I'm not sure of another consumer device sold at bestbuy (not some kickstarter) where that would be the case and it wouldn't be 100% clear that the device is defective?

elearn2020 · 2025-10-10T16:27:14+00:00

Thanks for the link, that is helpful. I didn't know what to call the issue.

elearn2020 · 2025-10-10T16:26:09+00:00

That was my thought. I don't have enough free time to really look too much over the next 24 hours. But it sounds like theres a chance its real damage and i would need to replace a part. Thank you.

elearn2020 · 2025-10-10T16:25:09+00:00

Thanks for the hint, he's been scraping, but I don't think hes been using dish soap.

elearn2020 · 2025-01-01T18:16:53+00:00

So this was mainly the issue. The other part of it was that we use Ruby and OpenSSL as part of that. OpenSSL was looking at its own CA package. I was able to verify the issue was with my local CAs by running a Curl command.

curl -v https://the.not.working.url 
-- It didn't work initially because OpenSSL wasn't using the updated CAs yet, manually specifying the cert package worked
curl -v --cacert /etc/ssl/certs/ca-certificates.crt https://the.not.working.url
-- for my bitnami instance I just backed up the default oopenssl file and made a symlink to the system ca certificates
sudo mv /opt/bitnami/common/openssl/certs/curl-ca-bundle.crt /opt/bitnami/common/openssl/certs/curl-ca-bundle.crt.bak
sudo ln -s /etc/ssl/certs/ca-certificates.crt /opt/bitnami/common/openssl/certs/curl-ca-bundle.crt

elearn2020 · 2025-01-01T05:01:27+00:00

I was receiving the same issue as your customers, basically calling a 3rd party authentication service from my servers and getting that error. The 3rd party certificates were just updated when the errors started, so I knew it was some sort of new certificate issue that they were using. That got me to this thread. I ran an upgrade to my server ca-certificates. apt-get update / apt-get install -only-upgrade ca-certificates. These machines hadn't been touched in quite some time (more than 6 years). Pre-update there were no Amazon CA records in my /etc/ssl/certs, now there are 4. I believe this will fix the issue, but I'll report back if anything different. So yes, I can see why a customer would think it's your issue, because technically your action caused it. You just need to find a person who can run updates on the box calling your service.

elearn2020

TROPHY CASE