[Plugin] CA Fix Common Problems


Recommended Posts

On 1/7/2022 at 8:47 PM, ljm42 said:

 

OK, so your servername (on Settings -> Identification) is "NASA" and your Local TLD (On Settings -> Management Access) is "fritz.box". Put those together and you are telling Unraid that its hostname is NASA.fritz.box.

 

This FCP warning is saying that when Unraid does a DNS lookup for NASA.fritz.box, it does not get an IP address back.

 

If your client computers are able to resolve NASA.fritz.box, then that means your client computers are using a different DNS resolver than the server, which is actually pretty common. We often tell people not to point their Unraid box at a pihole.

 

The point of this check is to help people who have completely wrong Local TLDs, but it inadvertently caught you because (presumably) the server is using a different DNS resolver than your clients. If your clients are able to resolve NASA.fritz.box fine then you are probably fine and can ignore this one. I need to think about a different way to word the warning.

 

 

@Mantene is this your situation too? the url works from the clients but not the server because the server is using a different DNS resolver than the clients?

 

Unraid uses the same DNS like all other clients in my network (which is pihole).

Within pihole client list, NASA.fritz.box is also listed with its IP addresses.

Other clients are not able to resolve or connect via NASA.fritz.box.

My Unraid server is also not listed within Windows Explorer Network tap.

I always have to connect via IP address.

 

 

Link to comment

I seem to have trouble with the new 'Invalid DNS entry for TLD' warning too… it says: "The DNS entry for 'noatun.lan.gru.earth' resolves to 192.168.178.2, you should ensure that it resolves to Array."

 

Not really sure what to do with this… that is the local IP address of the Unraid server. noatun is its name and lan.gru.earth is the local domain. Everything network related works perfectly and has always worked.

 

My local machine resolves this exactly as expected (.1 is my local OpenWRT, .2 is PiHole on the Unraid server, Unraid uses .1):

 

❯ dig +short @192.168.178.1 noatun.lan.gru.earth
192.168.178.2

❯ dig +short @192.168.178.2 noatun.lan.gru.earth
192.168.178.2

❯ host noatun.lan.gru.earth
noatun.lan.gru.earth has address 192.168.178.2
noatun.lan.gru.earth has IPv6 address fd3b:2815:be50:4::25
noatun.lan.gru.earth has IPv6 address <redacted>

 

Edit:

 

I also have an incorrect error with "Invalid Certificate 1": "Your noatun_unraid_bundle.pem certificate is for 'lan.gru.earth' but your system's hostname is 'noatun.lan.gru.earth'. 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 certificate I'm using is a wildcard certificate and definitely valid for the server:

 

root@noatun certs ❯ openssl x509 -in /boot/config/ssl/certs/noatun_unraid_bundle.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
[...]
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Nov 26 13:29:03 2021 GMT
            Not After : Feb 24 13:29:02 2022 GMT
        Subject: CN = lan.gru.earth
[...]

            X509v3 Subject Alternative Name:
                DNS:*.lan.gru.earth, DNS:lan.gru.earth
[...]

Edited by Strayer
Added certificate issue
Link to comment
7 hours ago, matty2k said:

Unraid uses the same DNS like all other clients in my network (which is pihole).

Within pihole client list, NASA.fritz.box is also listed with its IP addresses.

Other clients are not able to resolve or connect via NASA.fritz.box.

My Unraid server is also not listed within Windows Explorer Network tap.

I always have to connect via IP address.

 

The server's full hostname is made by concatenating the servername (NASA) and the Local TLD (fritz.box), with a period in between. The clients on your network need to be able to resolve this hostname.

 

If NASA.frtiz.box doesn't resolve for anybody, then you should not put "fritz.box" as the Local TLD.  Change it to "local". This will enable mdns on the server and you should be able to access the server via http://NASA.local

Link to comment
1 hour ago, Strayer said:

I seem to have trouble with the new 'Invalid DNS entry for TLD' warning too… it says: "The DNS entry for 'noatun.lan.gru.earth' resolves to 192.168.178.2, you should ensure that it resolves to Array."

 

No need to take action here, we'll fix the message

 

1 hour ago, Strayer said:

The certificate I'm using is a wildcard certificate and definitely valid for the server:

 

1 hour ago, Strayer said:

        Subject: CN = lan.gru.earth
[...]

            X509v3 Subject Alternative Name:
                DNS:*.lan.gru.earth, DNS:lan.gru.earth

 

If this works in your current version of Unraid, it is not intentional. It won't work in 6.10

 

Unraid only looks at the "Subject: CN" line.  Normally that line needs to match [servername].[LocalTLD] exactly, but we made an exception for wildcard certs. 

 

When the wildcard character exists in that line:

  Subject: CN = *.lan.gru.earth

 

Then we replace the * with the [servername] and the result needs to match [servername].[LocalTLD] exactly (case does not matter)

 

So for a wildcard cert to work in Unraid, the * needs to appear in the "Subject: CN" line not in the "Subject Alternative Name" area.

Link to comment
On 1/9/2022 at 1:34 AM, sonofdbn said:

Thanks. I had already done some Googling and couldn't find anything that explains enough down at my level. Bottom line is: will there be any problems with 6.10 if I just leave things as they are?

 

DNS rebinding only needs to be disabled if you want to use an unraid.net SSL certificate, it will not cause issues with self-signed certs. We'll be issuing an update to Fix Common Problems that addresses the shortcomings folks have found with the new tests, if that doesn't catch anything then you should be good to go as far as these settings are concerned.

Link to comment
2 hours ago, ljm42 said:

 

No need to take action here, we'll fix the message

 

Thank you!

 

2 hours ago, ljm42 said:

If this works in your current version of Unraid, it is not intentional. It won't work in 6.10

 

Unraid only looks at the "Subject: CN" line.  Normally that line needs to match [servername].[LocalTLD] exactly, but we made an exception for wildcard certs. 

 

When the wildcard character exists in that line:

  Subject: CN = *.lan.gru.earth

 

Then we replace the * with the [servername] and the result needs to match [servername].[LocalTLD] exactly (case does not matter)

 

So for a wildcard cert to work in Unraid, the * needs to appear in the "Subject: CN" line not in the "Subject Alternative Name" area.

 

Interesting, thanks for letting me know. I issued a new certificate with the wildcard as its common name and the warning is gone now. Any particular reason why this is unsupported?

Link to comment

"INVALID CERTIFICATE 1" warning??

 

'Your xxtower_unraid_bundle.pem certificate is for 'xxtower' but your system's hostname is 'xxtower.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: '

 

First time ever seeing this out of Fix Common Problems, can someone explain to me why and what's changed?

 

I presume FCP has been 'tightened' without a mention ...

 

I only ever use my machine on local network.

 

Thanks.

Edited by superloopy1
Link to comment
1 hour ago, superloopy1 said:

"INVALID CERTIFICATE 1" warning??

 

'Your xxtower_unraid_bundle.pem certificate is for 'xxtower' but your system's hostname is 'xxtower.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: '

 

First time ever seeing this out of Fix Common Problems, can someone explain to me why and what's changed?

 

I presume FCP has been 'tightened' without a mention ...

 

I only ever use my machine on local network.

 

Thanks.

Seems like this needs a bit more testing so i'm adopting a hands off approach and just ignoring the warning for now, i've no idea how to get, or why i need a new 'certificate that matches your settings' when nothinh has changed at my (local) end. Just the plugin tht's changed, why??

Link to comment
14 minutes ago, superloopy1 said:

Seems like this needs a bit more testing so i'm adopting a hands off approach and just ignoring the warning for now, i've no idea how to get, or why i need a new 'certificate that matches your settings' when nothinh has changed at my (local) end. Just the plugin tht's changed, why??

A new test to prepare for changes coming in unRAID 6.10.

 

There is some discussion of it in the past 10 or 12 posts if you scroll up/back.

  • Like 1
Link to comment
1 hour ago, wgstarks said:

A new test to prepare for changes coming in unRAID 6.10.

 

More than that actually.  This series of tests (and yes we're finding some corner cases regarding it) actually began due to changes on Windows 11 which prevented me from mounting any SMB share hosted on Win11 to any of my servers.

  • Like 1
Link to comment

My system is well and truly screwed up with no gui access after calling 'rm /boot/config/ssl/certs/*.pem' as previosuly referenced in an attempt to tidy up this invalid certificate error, and then setting management access ssl/tls to 'yes', i stupidly misread the help. It was previously set to auto which i now need to reinstate cos i'm apparently not using SSl and each login attempt comes up as https//: not http:// as before. Server is only local to me so this is a real pain of a problem. how can i reinstate http: only access??

Edited by superloopy1
Link to comment
14 minutes ago, superloopy1 said:

My system is well and truly screwed up with no gui access after calling 'rm /boot/config/ssl/certs/*.pem' as previosuly referenced in an attempt to tidy up this invalid certificate error, and then setting management access ssl/tls to 'yes', i stupidly misread the help. It was previously set to auto which i now need to reinstate cos i'm apparently not using SSl and each login attempt comes up as https//: not http:// as before. Server is only local to me so this is a real pain of a problem. how can i reinstate http: only access??

 

<Edit> Fixed!

Link to comment
13 hours ago, superloopy1 said:

"INVALID CERTIFICATE 1" warning??

 

'Your xxtower_unraid_bundle.pem certificate is for 'xxtower' but your system's hostname is 'xxtower.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: '

 

First time ever seeing this out of Fix Common Problems, can someone explain to me why and what's changed?

 

I presume FCP has been 'tightened' without a mention ...

 

I only ever use my machine on local network.

 

Thanks.

 

11 hours ago, superloopy1 said:

Seems like this needs a bit more testing so i'm adopting a hands off approach and just ignoring the warning for now, i've no idea how to get, or why i need a new 'certificate that matches your settings' when nothinh has changed at my (local) end. Just the plugin tht's changed, why??

 

Please test again when the next version of Fix Common Problems is available, thanks!

Link to comment

Hi folks, if you think you were hitting some false positives with the recent certificate and LocalTLD tests, please update to the latest Fix Common Problems and run the tests again.  If it is still flagging issues I'd recommend cleaning them up before moving to 6.10.

 

If you have a custom certificate this tests that the "Subject: CN" of that certificate matches the [servername].[LocalTLD] settings of your server.  If you use a custom wildcard cert, it verifies that the "Subject: CN" is *.[LocalTLD] . Unraid does not use the "Subject Alternative Name" fields.

 

See Settings -> Identification to set the [servername] and Settings -> Management Access to set the [LocalTLD]

 

If there are warnings about a "Missing or Wrong DNS Entry for host" that means the server is not able to lookup an IP address for [servername].[LocalTLD] . In other words, if your servername is "Tower" and you specify the LocalTLD as "mydomain.com" then this tests that Unraid is able to do a DNS lookup for "Tower.mydomain.com". The point of this is to catch errors where people have provided an invalid LocalTLD. (i.e. don't add your ISP's domain name to the LocalTLD, unless Tower.myispsdomain.com actually resolves to the server's IP)

 

(There is a corner case where you might have Unraid setup to use a different DNS server than the rest of your network. In this case, as long as the rest of the network is able to resolve the server's IP, it should be ok to ignore the test.)

 

If you get warnings about having a blank LocalTLD, you should either set that to "local" or an actual domain name. This will help with any SMB connections that rely on MDNS (including Windows 11) regardless of the version of Unraid that you are running.

 

Need clarification on something? Feel free to ask if the above does not cover it

  • Thanks 2
Link to comment
On 1/10/2022 at 4:17 PM, Strayer said:

I seem to have trouble with the new 'Invalid DNS entry for TLD' warning too… it says: "The DNS entry for 'noatun.lan.gru.earth' resolves to 192.168.178.2, you should ensure that it resolves to Array."


Warning is gone now, thanks for looking into this!

  • Like 1
Link to comment

Non persistent share excludes in Fix Common Problems Solved (not a problem except me being stupid)

 

I wanted to use Docker Safe New Perms and want to exclude some shares from the process. This led me to Fix Common Problems.

I can select the shares I want and when clicking [EXCLUDE SELECTED] the selected shares ends up on the top line.

But, when I go back to DSNP the only share that is listed as excluded is the default appdata. And if I refresh Fix Common Problems the selections are gone.

 

I'm running 6.9.2 and FCP is updated to latest. Discussed it on the Discord server and one other person tested with 6.10RC2 with the same problem. Same person also checked editing the FCP settings.json file to add the excluded share(s), and then saw the share listed together with appdata on the Docker Safe New Perms page.

 

Edited by tetrapod
Link to comment

Upgraded to the latest FCP (2022.01.16), and got an error message "Docker application Docker application binhex-rtorrentvpn has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option".

 

So I went to the settings for binhex-rtorrentvpn and fixed that, but after running Rescan under FCP I get the same message. Not sure what I should be doing. Also, haven't changed the docker app settings for a while, so not sure why this error is being picked up now - perhaps it's a new check?

 

[Edit: My bad. Forgot that I had two volumes mounted, and had only fixed one of them. After fixing the other one it all looks good now.]

Edited by sonofdbn
Update
Link to comment

Greetings!

I'm trying to find the cause of the changes of permissions in my appdata folder.  I noticed appdata is not listed in the "Permission Test/Fix Excluded ON" list, it does however say "Docker Appdata Folders and CA backup Destination is automatically excluded".   I haven't touched this setting for a long time and have not made changes I could think of that would reset permissions for everything in the appdata folder, except for the fact the plugin was updated recently.

I'm not making accusations, just trying to rule out all the possibilities and trying to figure the cause of it.  Thanks.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.