You should see a list of domains that can be used to access Cockpit. Is the URL’s domain that you are using to access Cockpit part of this list?
Also would you please try to see if there are any errors showing up in the browser’s developer tools’ console? In the network tab, you could also check if an request is failing.
I have tried these and other variations with no success…
I bought the Freedom Box to relearn my Unix/Debian skills so I am not proficient at what you are asking. It had been my intent to use Cockpit to access the code. I do have a terminal program that provides access but I do not know how to use this code at this time.
I refer to this instruction: “ browser’s developer tools’ console? In the network tab, you could also check if an request is failing.”
19.23 add a new section to the Cockpit app that lists URLs that are currently configured. Could you check this “Access” section and list what is over there?
For developer tools, please open Firefox, then go to Menu -> Web Developer -> Network. Then reload the white page you get after launching Cockpit.
The IP address 192.168.1.37 will certainly not work. Could you check the browser network activity when you access using https://atomicboy.freedombox.rocks/_cockpit/ URL? Alternatively you can try the .onion address using the Tor browser.
It could not locate the server when using: https://atomicboy.freedombox.rocks/_cockpit/
The TOR Onion Web Browser gives a SEC_ERROR_UNKNOWN_USR:
It seems there is no fix forthcoming for the Cockpit white screen. Very disappointing.
@atomicboy after SEC_ERROR_UNKNOWN_USR you may hit Advanced... and add exception to “trust” your freedombox.
It would be great if Let’s Encrypt were set up to generate certificates with onion sites so the above situation does not happen. I understand that https with onion routing is not strictly necessary, but the error warning is potentially confusing to new users.
[See also: Manually verifying certificat for access over TOR and Let's encrypt]
I am unable to add an exception. I extracted these lines which might explain why:
"You can’t add an exception to visit this site.
The issue is most likely with the website, and there is nothing you can do to resolve it."
When I ran diagnostics in Let’s Encrypt I get:
In my newby mind … it would appear the domain name ( https://atomicboy.freedombox.rocks/_cockpit/) is not working. it substitutes the IP https://192.168.1.37/_cockpit/ which as we all know does not work.
I have port forwarding on my router setup for TCP 80 and TCP 443 as required by LetsEncrypt.
Here is a screen shot of Name Services:
The domain atomicboy.freedombox.rocks is not resolvable, so Lets encrypt is normal to not be able to give you a certificate. If you used dynamic DNS (I guess you did) something you have setup is wrong (check the steps at the manual page https://wiki.debian.org/FreedomBox/Manual#FreedomBox.2FManual.2FDynamicDNS.Dynamic_DNS_Client). When DNS is working - you can test it here https://mxtoolbox.com/SuperTool.aspx?action=a%3Aatomicboy.freedombox.rocks&run=toolpage for example - Lets encrypt will be able to provide correct certfificates.
When you have proper working domain name, you can revisit the cockpit issue if it persists.
1 Like
Thanks for this feedback. I am going to reload the Freedom Box fresh and see what I can do.
Thanks again.
I’m in the same “blank screen” boat. 1) I’m using oracleatbelfry dot com as the domain 2) the cockpit page from “sys” lists two addresses, an onion address as well as oracleatbelfry dot com 3) I can enter https colon slash slash oracleatbelfry dot com slash _cockpit into my linux desktop’s browser and it goes to the cockpit login screen as you’d expect 4) but I still get the blank screen.
Sorry to hear that. I gave up and mine is sitting on a shelf. If you find an answer, please share on here. Thanks
I installed FreedomBox about a week ago and I had the same problem. I worked on it until I was cussing. 
Figured I’d give it another go because this entire concept is just awesome to me. One question is… I’ve seen several articles that .local was actually sold by ICAN or whoever it is and that some bonafide corporations are actually using that domain now. Is it still ok to put .local in for a private domain name or should we use something else? I’ll probably register a domain at some point, but if this box is “for the people” and for beginners, most standard users don’t even know what a domain is and their eyes will glaze over if you try to explain it to them and they SURE aren’t going to register one. Anyway, I’m reinstalling and will give it another shot, I just wanted to chime in and let y’all know that mine wasn’t just a drop-in install. 
1 Like
.local should work ok. Is it listed on /plinth/sys/cockpit/ under “Access”?
I just got FreedomBox running on a VM on my home network. For me, this error seems to be related to access configuration. Like as soon as it hits the browser’s content sec pol for wss://meetingvite.com, nothing further processes.
My domain is meetingvite.com and I’ve got all of the necessary ports forwarding. Cockpit loads fine in Chrome and Firefox, but when I load Cockpit in Safari on my Mac, I get the following in the web console:
1. Failed to load resource: the server responded with a status of 404 (Not Found) (nav.css, line 0)
2. Refused to connect to **wss://meetingvite.com/_cockpit/cockpit/socket** because it does not appear in the connect-src directive of the Content Security Policy.
3. SecurityError: The operation is insecure.
(anonymous function) (cockpit.js:380)
t (cockpit.js:380)
je (cockpit.js:577)
(anonymous function) (index.js:72:52269)
n (index.js:1:115)
(anonymous function) (index.js:40:87529)
n (index.js:1:115)
(anonymous function) (index.js:1:904)
Global Code (index.js:1:914)