sudo update-ca-trust -f
, give it a spin, assuming you’re in a RHEL/Rocky environment.
I’ve already rebuilt and moved on. Next time . . .
Yes, seems update-ca-trust is indeed the Rocky command. It’s a short script located in /usr/bin that appears to extract the certificates from a bundle file.
update-ca-certificates appears to be the Ubuntu flavor of the same process, and which
does not resolve it on Rocky.
To be tested for the next person that is unfortunate enough to run into this.
I’d like to live in a world where there is never a next person. Here’s hoping that is soon the case
For the TL;DR on how SSL works in this case, and why it matters.
TLS/SSL is at the heart of any communication with a server that has a https:// URL. These set themselves apart from the now largely deprecated http:// URLs which go back to the days of the Internet when there were mostly good guys, and you could generally trust everything.
TLS/SSL provides two functions - it encrypts the communication and it verifies the identity of the server, so you know you can trust it (it’s actually your bank, not a scammer).
This is accomplished by installing an SSL certificate (a digital signature) on the server, which becomes part of the handshake when the connection is established. Certificates always fall into the private/public key encryption category. Meaning the server keeps a private key on hand, that only the server knows, and a public key that it freely gives out. That ensures that only this server can generate a valid response that matches the public key. And the other party can validate that.
However software doesn’t know all the various servers around the world, and a trusted 3rd party needs to vouch for server’s identity. Those are the certificate authorities (or CA). There are some 2nd tier ones, but in the end they all roll up to a small number of well known ones that everyone will trust. Similar to root DNS servers, that translate domains into IP addresses.
When a SSL certificate is created and attached to a server, it must be signed by a certificate authority who has validated the server’s identity (yes, this was really Autodesk). Server administrators have to jump through various hoops to create these certificates and prove that they are authorized and represent the domain in question. The certificates generally expire and have to be renewed each year.
So when the license server calls home to check a license it uses an https:// connection to an ADSK owned domain. This is verified via these certificates and their respective certificate chains to the certificate authorities. In doing so the license server can be certain that the answers it gets are coming from a trusted ADSK server, and not an imposter that tries to cheat on a license.
So when this certificate chain breaks for some reason (expired certificate, trashed CA lists, etc), the license server cannot establish a secure connection and eventually will tell Flame that it is not licensed.
So while your Internet connection in total may be totally fine, it’s possible that the license server cannot call home in confidence. And so you end up with a big headache.
Follow Up:
I booted up from my old drive, mv’d the offending file and started flame. I was able log in and clean up my framestore before rebooting back to my new drive, so the fix seemed to work, although when I logged in on the old drive it said something about an rng? something, and when I exited it logged me out as well. Since I had accomplished what I set out to do, I didn’t think much of it. I’m not having any of those issues with my new build. Thanks to all who have looked into this and come up with solutions.
Jut want to say that I ran into this, again… today and that the instructions worked. Thanks so much.
Glad to hear that the workaround is still working around!
Someone else had the issue and I pointed them to this post. It saved their ass as well.
Yah this is gold. Thank you everyone for doing your thing. It’s a massive lifesaver.
This bit me yesterday. Very thankful for the Logik Forum and this amazing community!!
Amazing! Glad this is still holding up. One of my clients also got hit with this today on one of their internal rigs.
Thanks again to Beau @ Autodesk for all his help getting to this solution.