I tried too hard to get a USB serial adapter working so I could serial into the CLI, and fried my grub bootloader beyond my ability to repair. I reinstalled the OS and uploaded my config, but now I don’t have the private key for the built-in TrueNAS certificate that makes TLS/SSL work for HTTPs based logins.
So, I admit up front that I didn’t have the key saved in my config download. That’s not a mistake that I’ll make again. At least I had the config from 3 days ago. Oof.
Is there a step-by-step guide to actually fixing this?
I know I can create a CA on TrueNAS Scale itself, and then use that to sign a certificate, but that is extremely complex and confusing, and I can’t find a step-by-step guide to doing it that gaurantees I won’t lock myself out of my NAS again.
Is there either a way to reinstall the default TrueNAS cert so that it includes the associated private key, or at least a good tutorial on how to make TrueNAS its own self-signed CA with self-signed TLS certificate?
Any help would be greatly appreciated.
Not sure I understand.Can you simply accept the warning in your browser to get to the login page? You could install the certificate on your PC also to trust the certificate so you no longer get that warning.
The server isn’t even reachable by HTTPS anymore. I managed to mess it up good. -_-
I’m getting an actual error in TrueNAS SCALE itself.
It’s relying on this default certificate:
Bonus: I can’t actually change the GUI settings in TrueNAS anymore, because the default certificate’s private key is missing, so trying to save any changes fails:
@xMAXIMUSx , thanks again for your help with this. I had to stop worrying about this few a few months, as life got a bit intense, but I’m looking back into it now and it sounds like in the end I’ll have to provide my own certificate.
I did open a bug report here, as it felt like it should be possible to repair the default certificate: Jira The short answer is no, as this isn’t a bug; when the secret is not imported, the information in the database that expects the secret leads to this expected breakage, and the only way to fix it is to replace the damaged certificate with a new one.
Thanks for the ticket. Unfortunately there isn’t much for us to do here because this isn’t a bug.
In your situation, you would need to create a new SSL certificate and then attach that to the UI. However, we have opened up a related ticket to add a new feature to the UI that allows the user to wipe all encrypted fields in the database without wiping the entire config. Unfortunately, that would be a non-trivial change and will require careful design and consideration before we move forward. The ticket is linked to here if you’d like to follow progress of it. Otherwise, we’re closing this one for now.
I really appreciate that they’re looking into adding a feature in the UI to troubleshoot this. It’s not a mistake I’d make twice, but it’s really annoying having done it once. 
Here’s the new issue exploring this feature request: Jira
