Let's Encrypt Name Resolution Issue Preventing Access

[adnan29979]

Describe the issue
I've been successfully using MeshCentral for a couple of months without any issues, including as recently as yesterday. I have not made any changes to the server configuration. However, today when I attempted to access my MeshCentral instance, I encountered the following warning message and was unable to get to the website:

WARNING: Invalid Let's Encrypt names, unable to resolve: my.sub.domain.org

Temporary Workaround
I discovered that by adding "nochecks": true to the Let's Encrypt section of my config.json, I am able to bypass this issue and gain access. However, I believe this to be a workaround rather than a permanent solution.

Expected behavior
The server should normally resolve the Let's Encrypt names without requiring any temporary workarounds, allowing for regular access to the MeshCentral website.

Server Environment:

• MeshCentral version: 1.1.18 (This is a production server. I tend not to update a production application normally)
• Node.js version: v20.11.0
• Operating System: Windows 11
• Any recent changes made to your environment? No

Additional context
This issue appeared suddenly without any prior changes or updates to the server. The temporary fix does allow for access, but I'm concerned about the implications of bypassing security checks and would prefer a more stable solution.
Edit: I have a public DNS set in my network adapter from the very beginning. 8.8.8.8 and 1.1.1.1.

leevents output at server console tab:  

4/3/2024 11:04:23 AM - Getting certs from local store (Production)
4/3/2024 11:04:23 AM - Reading certificate files
4/3/2024 11:04:23 AM - Setting LE cert for default domain.
4/3/2024 11:04:29 AM - Certificate has 47 day(s) left.
4/3/2024 11:04:29 AM - Certificate is ok.

Screenshots

Your config.json file

	{
  "$schema": "https://raw.githubusercontent.com/Ylianst/MeshCentral/master/meshcentral-config-schema.json",
  "__comment1__": "This is a simple configuration file, all values and sections that start with underscore (_) are ignored. Edit a section and remove the _ in front of the name. Refer to the user's guide for details.",
  "__comment2__": "See node_modules/meshcentral/sample-config-advanced.json for a more advanced example.",
  "settings": {
    "cert": "my.sub.domain.org",
    "_TrustedCert": false,
    "_WANonly": true,
    "_LANonly": true,
    "_sessionKey": "MyReallySecretPassword1",
    "port": 8069,
    "_aliasPort": 443,
    "redirPort": 80,
    "_redirAliasPort": 80,
    "webrtc": true,
    "selfUpdate": false,
    "MongoDB": "mongodb://localhost:27017/?replicaSet=rs0",
    "MongoDbBulkOperations": true,
    "authlog": "C:\\myFolder\\meshcentral-data\\authlog.log",
    "maxInvalidLogin": {
      "time": 60,
      "count": 3,
      "coolofftime": 60
    },
    "maxInvalid2fa": {
      "time": 60,
      "count": 3,
      "coolofftime": 60
    },
    "_crowdsec": { "fallbackRemediation": "captcha" },
    "AutoBackup": {
      "mongoDumpPath": "C:\\Program Files\\MongoDB\\Tools\\100\\bin\\mongodump.exe",
      "backupIntervalHours": 24,
      "keepLastDaysBackup": 3,
      "zipPassword": "mypass",
      "_backupPath": "C:\\backups",
      "_googleDrive": {
        "folderName": "MeshCentral-Backups-GDrive",
        "maxFiles": 3
      }
     },
    "ipBlockedUserRedirect": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
    "_userAllowedIP": "127.0.0.1,192.168.1.0/24",
    "_userBlockedIP": "127.0.0.1,::1,192.168.0.100",
    "agentPing": 25,
    "_browserPing": 45
  },

  "domains": {
    "": {
      "title": "abcd",
      "title2": "abcd",
      "_minify": true,
      "_newAccounts": true,
      "_userNameIsEmail": true,
      "newAccountsCaptcha": true,
      "_titlePicture": "Logo2.jpg",
      "welcomePicture": "loginLogo.png",
      "_loginPicture": "Logo1.jpg",
      "_maxDeviceView": 100,
      "passwordRequirements": {
        "_min": 8,
        "_max": 128,
        "_upper": 1,
        "_lower": 1,
        "_numeric": 1,
        "_nonalpha": 1,
        "_reset": 90,
        "force2factor": true,
        "_oldPasswordBan": 5,
        "_banCommonPasswords": false,
        "twoFactorTimeout": 300
      },
      "twoFactorCookieDurationDays": 5,
      "_agentCustomization": {
        "displayName": "Company® Product™",
        "description": "Company® Product™ agent for remote monitoring, management and assistance.",
        "companyName": "Company®",
        "serviceName": "companyagent",
        "image": "agent-logo.png",
        "fileName": "compagnyagent"
      },
      "terminal": {
        "_linuxshell": "login",
        "launchCommand": {
          "linux": "clear\nsu pi\ncd\n",
          "_darwin": "clear\necho \"Hello MacOS\"\n",
          "_freebsd": "clear\necho \"Hello FreeBSD\"\n"
        }
      }
    }
  },
  "letsencrypt": {
    "__comment__": "Requires NodeJS 8.x or better, Go to https://letsdebug.net/ first before trying Let's Encrypt.",
    "_nochecks": true,
    "email": "my.email@gmail.com",
    "names": "my.sub.domain.org",
    "skipChallengeVerification": true,
    "production": true
  }
}

[adnan29979]

Update: I think that certain aspects of my national internet service are currently experiencing downtime. Which is probably why I am facing the above issue.

[si458]

Ur issue is very similar to #5988
Could be a letsencrypt outage?

[adnan29979]

Yes, it seems like this issue is similar to #5988. My national telecom provider has announced a maintenance period, and it looks like other web applications are experiencing similar problems. So, it seems the issue is related to a national downtime, not something on my end. For now, I'll run it with "nochecks": true and see if the situation resolves itself once the maintenance is completed. I'll keep you updated on any changes.

Edit: This issue is somewhat related to #920 as well

[si458]

@adnan29979 well i was going to reply saying the is no such value as nochecks?
but after checking the sourcecode, turns out the is!
it was just missing from the schema file, so have added it!
If nochecks is "true", MeshCentral won't verify if "email" is valid, has a valid MX record, AND if "names" doesn't contain a wildcard, can be resolved by DNS A/AAAA record

[adnan29979]

Yup. I saw it from #5988. It worked perfectly for me.
IDK how, since it's linked with email. But it worked for me.
Thanks for adding it to the schema.

[adnan29979]

I checked my domain at Let's Debug. These are the results.
The issue is with my domain provider, who is the national telecom provider whom I mentioned previously is having a downtime.

[adnan29979]

Good news! The problems with my national domain provider are fixed, and I can get into my MeshCentral server without using "nochecks": true now.
Looks like the trouble wasn’t with MeshCentral or my network after all. I'm closing this issue.

[adnan29979]

Update: I still see this result from Let's Debug. But somehow my Meshcentral is now running fine without nochecks. This might pose a problem when Let's Encrypt tries to get a new certificate after this one is over.

[adnan29979]

Update: Test results are now fine from Let's Debug. So it's safe to assume that all maintenance from my national domain provider is complete.