xta101

Members
  • Posts

    7
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

xta101's Achievements

Noob

Noob (1/14)

0

Reputation

  1. Thanks for all your help! Truly appreciated. Shortly after my last post, under the help for "Use SSL/TLS", I noticed what lines up with your explanation... how it's checking for certs in order, starting with certificate_bundle.pem & only if that file doesn't exist, does it create the "<server-name>_unraid_bundle.pem" cert. Before deleting the SERVER_unraid_bundle.pem file, I made a backup. Should I drop it back into place, or is that a moot point... or worse, would it cause problems? Glad to hear it's a "non-issue", and I have no problem accessing the WebUI in this way. Also excited for 6.10! thanks for the tools and all your help!
  2. Getting Closer! After following the steps above, I no longer get the warning when running "fix common problems" scan. That's good! However, a new SERVER_unraid_bundle.pem file was not regenerated after turn "Use SSL/TLS" back to "auto". I even restarted the server, as I figured that would initiate the process (per the "renewcert" help under the "Use SSL/TLS" section), but there is only a "certificate_bundle.pem" file left in "/boot/config/ssl/certs/". Is there something else needed to regenerate the self-signed cert? or just patience? Without the cert, when I browse to "https://SERVER.DOMAINNAME.local:HTTPS_PORT", I'm getting a certificate warning again. If i look at the certificate warning, it's telling me the cert is issued to "xxxxxxx.unraid.net". Interestingly, the properties of the certificate, in the Windows title bar, it lists the certificate as "SERVER.DOMAINNAME.local".... the warning I'm getting now reads: URL: SERVER.DOMAINNAME.local Reason: Invalid name of certificate. Either the name is not on the allowed list, or was explicitly excluded. View certificate I'm guessing the problem is that the "SERVER_unraid_bundle.pem" file wasn't regenerated. thanks again!
  3. I also just realized if I enter the URL "https://SERVER.DOMAINNAME.local:HTTPS_PORT" into my browser, I land on the login page with no certificate issues. I'm not using 80 for HTTP or 443 for HTTPS. When I connect this route, the address listed in my address bar remains "https://SERVER.DOMAINNAME.local:HTTPS_PORT/Main" after login. If I view the certificate using this method, it lists a DNS Name entry for "SERVER.DOMAINNAME.local", in addition to the xxx.unraid.net entries. If I enter the URL "http://SERVER.DOMAINNAME.local:HTTP_PORT" into my browser, I redirect to the "https://xxxxxxxx.unraid.net:HTTPS_PORT/login" page (this feels correct). Again, no certificate issues this way. After login, the address bar remains in the "https://xxxxxxxx.unraid.net:HTTPS_PORT/Main" format. If I view the certificate using this method, it does not lists a DNS Name entry for "SERVER.DOMAINNAME.local", only the xxx.unraid.net entries. hopefully this adds useful info. thanks
  4. the SERVER_unraid_bundle.pem was autogenerated (I'm assuming - when I used the "provision" tool when enabling SSL??) SERVER.DOMAINNAME.local should be the correct url. In testing however, both "https://SERVER.DOMAINNAME.local" and "https://SERVER.local" are producing certificate errors, as they are trying to utilize my LetsEncrypt wildcard cert which is pulled via SWAG for a different domain I own (let's call it "OTHERDOMAIN.com"). What does work for me however is using the URL "https://xxxxxxxx.unraid.net:HTTPS_PORT". This is what I've been using, and assumed that things were "working as expected", which now seems less accurate. I can also use http://SERVER.DOMAINNAME.local:HTTP_PORT and it will redirect to the "https://xxxxxxxx.unraid.net:HTTPS_PORT" page with no certificate warning. If i use "https://SERVER.DOMAINNAME.local" and ignore the certificate warning, it does take me to the unraid login and lists the connection as secure. When i check the certificate, under the "Subject Alt Names", it's listing the correct internal IP address, the "SERVER.DOMAINNAME.local" DNS name, and the "xxxxxxxx.unraid.net" & "www.xxxxxxxx.unraid.net" DNS Names. In all my poking around, I have not seen "SERVER.local" listed anywhere on any of the certificates. Should I wipe out the .pem files in "\config\ssl\certs\" and let unraid re-provision a new cert for SSL? How do I guarantee i get the System Name and Local TLD matching correctly? thanks again!
  5. I'm seeing similar warning, but with a slightly different setup. My domain is setup as "DOMAINNAME.local" within my router. I currently have set: Settings > ManagementAccess > Local TLD: DOMAINNAME.local Settings > ManagementAccess > Use SSL/TLS: Auto For the Server's name, I have: Settings > Identification > Server name: SERVER During the last Fix Common Problems run, i got the warning that lists: Your SERVER_unraid_bundle.pem certificate is for 'SERVER.local' but your system's hostname is 'SERVER.DOMAINNAME.local'. Either adjust the system name and local TLD to match the certificate, or get a certificate that matches your settings. Even if things generally work now, this mismatch could cause issues in future versions of Unraid. The local TLD can be adjusted here As the message indicates, things are currently working, but I'd like to avoid any future issues. Trying to understand how this works and how to resolve. Should "Server name" and "Local TLD" be adjusted in unraid. Should i not be using "DOMAINNAME.local" on my router? Thanks in advance!
  6. While trying to find a good use for my second NIC port (suggestions welcome), I started testing moving docker containers & VMs to the second port. Purely for testing/learning at this point. I've been trying to get VMs to work for far to long and feel like I've exhausted my knowledge. What I have setup currently: my Unraid server has 2 NIC ports (eth0 and eth1) with bonding disabled for both, bridging enabled for both. eth0 has an IPv4 address assigned automatically by my DCHP server (a pfSense router). eth1 has no IPv4 assignment. Everything is networked through an unmanaged switch. I'm currently using the binhex-delugevpn docker container to act as my privoxy proxy server. The container is on a custom docker network, which I believe to be routed through eth0 (i don't know how to check/verify this). I have a few different Virtual Machines running on my Unraid box. Until this testing, all have previosuly been connected to the network bridge br0, but when switching them to br1, I'm running into proxy issues. What I'm trying to do: From any of the VMs, if I disable the proxy, i can reach the internet. As soon as I enable the proxy connection by specifying my Unraid server's IP address and the Privoxy port, web browsers no longer load pages. With the proxy settings turned on, I can ping my Unraid server fine. I can also ping Google.com fine as well, but the page won't load in a web browser. I can't access any other docker's WebUIs as well with the proxy turned on in windows. From other computers on my network, i don't have this issue using the proxy. If I switch the VM's network bridge to br0, I don't have any of the described issues when connected via the proxy. My guess is communication between eth0/br0 and eth1/br1, but I'm not sure where or how to test/verify/address that. At the moment this exercise is just me learning how this all works. I can put everything back on eth0/br0 and run just fine, but I'd like to understand why this doesn't work and what I'm overlooking. Not sure yet if there is any value even in moving a VM over to eth1. Any help/documentation would be greatly appreciated to help scratch this itch!