Server Warnings WARNING: Invalid Let's Encrypt email address, unable to resolve: domain.com

[johnczer]

I have the very latest version of meshcentral installed (.4.8-p) on Windows Server 2012R2 and I still get this error. I have followed the instructions for getting a Let'sEncrypt certificate to a "T" but not sure why this never generates a cert after waiting hours and I keep seeing this message in mesh portal: Server Warnings WARNING: Invalid Let's Encrypt email address, unable to resolve: domain.com Two things I noticed under "letsencrypt" section:

• "email": "email@user.com ", Notice the space after email address? This is apparent using new config. If I leave the space after email address the second part of the error "unable to resolve: domain.com" does not show in portal.
• If I remove the space "email": "email@user.com", I see both errors. I have been using this program for quite some time and I have had it working perfectly along with certificate.

[Ylianst]

Hi. First, no space needed. I just fixed the sample config.json, so new versions will no longer have that space. It s was just a typo.

Second, before trying to get a certificate, MeshCentral will try to resolve the domain name of the email address, so if you type "user@my.domain.com", MeshCentral will try to resolve "my.domain.com" for an MX (email) record. I can't skip this because Let's Encrypt will perform the same test and fail if the email is not resolvable.

Lastly, you can run "node node_modules/meshcentral --debug cert" or go in the "My Server"/"Trace" tab and enable the "cert" trace to see that is going on. This said, if the given email address is not resolvable, no attempt will be made to get a certificate.

Hope that helps, Ylian

[johnczer]

How is it that https://letsdebug.net/ reports back OK? Here are the results of the command you suggested: c:\meshcentral>node node_modules/meshcentral --debug cert MeshCentral HTTP redirection server running on port 80. WARNING: Invalid Let's Encrypt email address. MeshCentral v0.4.8-q, Hybrid (LAN + WAN) mode. MeshCentral Intel(R) AMT server running on support.domain.org:4433. MeshCentral HTTPS server running on support.domain.org:443.

[Ylianst]

Let's Debug does not check your email address, but Let's Encrypt will. You can't provide a bad email address in your Let's Encrypt certificate request, it will get rejected.

[johnczer]

One thing I am confused about is my domain is domain.org with support being the sub domain. If Letsencrypt is trying to resolve this and issue a certificate by using the email address user@subdomain.mydomain.com this does not sound right. My email address would not be user@support.domain.com but rather user@domain.com and certificate is issued to support.domain.com. I guess I could use my firewall which issues letsencrypt certs with no problem and based on the domain the cert is being issued to. Just baffled as to why previous configs worked but now they do not.

[johnczer]

The email address I am using is definitely a valid one and the same one I have used in previous configs.

[Ylianst]

Note that the email address can be anything, including GMail, Hotmail... it does not have to be one that is part of your own domain request. You can check the MX record of your DNS using nslookup, example here. In MeshCentral, the line of code that is failing is this:

require('dns').resolveMx(obj.config.letsencrypt.email.split('@')[1], ...)

Even if you where to remove this, GreenLock will do the same test. You need the portion after the @ of your email address to resolve with some valid MX record. You can use nslookup to see that is going on.

[johnczer]

I already have a valid MX in place.

[johnczer]

With the latest update this is back: Server Warnings

WARNING: Invalid Let's Encrypt email address, unable to resolve: rsa-systems.org Something seems amiss. I am assuming you are referring to the "letsencrypt" section where "email" user@domain.com and "names" support.domain.com are entered. These have always been entered as such using the same entries.

[johnczer]

If letsencrypt is validating that I own the domain domain.com based on email@domain.com using MX record it should work. If it was looking at whether email@domain.com owns support.domain.com based on MX record I don't see how this would work. My MX would resolve to mail.domain.com.

[MailYouLater]

What does Mail Tester say about your email address?

[johnczer]

Mail server found for domain: It says that my mailserver is correct and matches my static IP address.

[MailYouLater]

OK... If the issue is with your mail server / dns configuration, perhaps MXToolBox can point out the issue.

[johnczer]

It’s not on my end, I am certain of that. My previous post doesn’t imply that. I am merely pointing out that the test you suggested was NOT showing any errors. I ran this test to assure you of this. But I have already tested my network because I am an IT Engineer and do this everyday for 16 years. I can assign Letsencrypt certificates to other devices on my network with no issues whatsoever. Keep in mind MailYouLater I am using the NPM install method; I believe the last time you were trying to help you were using the installer and had not tested the NPM install method. Just want to make sure we are comparing like scenarios. Thanks

[MailYouLater]

I have only ever installed via npm, and I'm not trying to say that you have any issues in your network, email or domain configuration, I'm just trying to point out some tools that can help you verify whether or not there are any issues there because Ylianst suggested that that might be the cause of the problem you reported. If you use these tools appropriately and respond with the results, you can you can check for errors and fix any if they do exist, or you can have some extra weight behind your statement that the issues aren't with your network/email/domain configurations.

By the way, I too am an IT Engineer, and your statement that you 'do this everyday for 16 years' doesn't actually give you any credibility. I'm not saying this is the case with you, but I've known a number of people who did their jobs 'good enough' but weren't really doing a good job, so that point simply doesn't mean much. I'm also going to point out here that I've helped with a number of issues here, both with MeshCentral, and with user configurations. I hope you can find and fix your issue, but after your rudeness, I'm not feeling very motivated to bother offering my help here any more.

[Ylianst]

Just published MeshCentral v0.4.8-t with a new "nochecks": true in the LetsEncrypt section of the config.json, for example:

  "letsencrypt": {
    "nochecks": true,
    "email": "abc@hotmail.com",
    "names": "meshcentral.com,www.meshcentral.com",
    "production": false
  }

Normally I do a lot of checking and display nice errors because if something goes wrong, it's best to have the software figure it out and display a nice message. However, if you use "nochecks", I will setup and pass everything along to GreenLock as-is, good or bad. Give it a try and let me know what you see. If it works and my tests on the email address was incorrect, that would be interesting to know. Thanks in advance.

[johnczer]

Ylianst, Thank you for making these changes. I found a temporary workaround when doing some research about why Letsencrypt would have an issue verifying domain before issuing a certificate. I was lead to try the following on the meshserver:

• remove IPv6 from network adapter
• assign a public DNS server IP address to the network adapter The first suggestion did not appear to work. The second change did. After I received the certificate I put the DNS settings back to point to my internal DNS servers. I am not sure why all of a sudden Letsencrypt will not validate a domain when the server points to internal DNS servers that have public forwarders and with Google DNS servers added. I read something that letsencrypt is particular about what DNS serevers it validates against. I also have a split DNS scenario and again, I am able to install and update Letsencrypt certificates on other devices either at the firewall level on behind the firewall. This was not an issue prior to that particular meshcentral update. I really appreciate your hard work on this and hopefully this information is helpful.

[johnczer]

I apologize if my comments came across brash mailyoulater. I was merely pointing out that I would have already troubleshooted and looked at things from all angles before posting on this forum. I will spend hours and days looking at whether or not the issue could be on my end, using all of the resources available before posting here. I also understand that this useful tool is a work in progress and any future changes could sometimes result in negative results. I appreciate the help offered, thanks.

[MailYouLater]

@johnczer: Thank you for your apology, and I'm sorry if any of my comments provoked your earlier brashness.

Regarding the LE issue: I'm glad you were able to get your cert issued, but I'm wondering where the fault actually lies. If you feel like taking the time to test it, I would be curious to know if the workaround Ylianst added would allow you get the cert without making the DNS changes you mentioned, as that would indicate that the checks implemented in MeshCentral are different in some way from the checks LetsEncrypt performs. However, if it still fails when the DNS is set as it was, even with the "nochecks": true setting in place, then the issue is either in that configuration, or in LetsEncrypt, not MeshCentral.

Regarding the thoroughness of your testing prior to posting here: I'm glad to hear you perform such checks, but it's impossible for anyone to know how thorough you were unless you provide the relevant data in your post(s). Anyway, thank you again for coming back with a humble response, people who can look back on their own comments and apologize for them seem to be very rare these days.

[johnczer]

I will test this and get back with results.

[johnczer]

Here is what I have found so far:

• "nochecks": true, did not appear in 0.4.8-t or -u but I added it manually. I tried this multiple times with starting and stopping the meshcentral service and was just trying to give it a chance to generate a cert.
• I was not able to get a certificate until I added a public DNS (8.8.8.8) to the network adapter and it was almost instantaneous

I am 100% certain I did not have to add a public DNS address to the server's adapter for this to work before. It's not the end of the world and I know there are many other issues to be worked on. I have a workaround which may be better in the long run and that is issue the certificate at the firewall level, export and import into meshcentral folder after extracting the key and cert. The firewall automatically renews these with no issues; I just have to rinse and repeat.

[MailYouLater]

Huh, strange. I don't get why it should care if your network adapter is configured to use a public or private DNS, but at least you found a couple of functioning workarounds. IDK if it's worth it to you or not, but if you have some extra time and want to mess with this some more, perhaps you can try with some old versions to figure out which version was the last one to work without configuring a public DNS on your network adapter. If so, you can install the old versions via npm install meshcentral@<version> where \<version> is one of the versions listed on npm. (e.g. npm install meshcentral@0.0.1-a)

I wonder if this change occurred during one of the recent GreenLock updates (v2->v3 or v3->v4)...