Agents using LE cert with ecdsa about meshcentral HOT 10 OPEN

@D4V3M0NK sadly im not 100% sure, my speciality is nodejs and web front end things,
i dont deal with C but i am trying to learn,
but from what im aware @Ylianst wrote everything with RSA 3072 in mind! so i cant see rsa 4096 effecting anything

from meshcentral.

@si458 I can confirm that LE RSA 4096 bit keys work without issue on the agent.

from meshcentral.

if you are using a reverse proxy (nginx) you shouldnt need to load any certificates into meshcentral

1. set cert to your dns name of choice meshcentral.mydomain.com
2. set trustedproxy to your reverse proxy ip address
3. set tlsoffload to your reverse proxy ip address
4. set certurl to the the website url you are using for your meshcentral https://meshcentral.mydomain.com
5. set nginx to forward to http://meshcentralipaddress:443 DONT SET IT TO USE HTTPS

edit: https://ylianst.github.io/MeshCentral/meshcentral/#nginx-reverse-proxy-setup

from meshcentral.

also note you already asked a similar question in the past and @Ylianst replied with basically the same as me above
you need to tell meshcentral to load the certificate from your reverse proxy rather than the file
#5296

from meshcentral.

Unfortunately due to the internal networking, we're unable to do that - which is why we're taking the same cert that's on the proxy server, and copying it into myexternal.crt

from meshcentral.

(and reverting the certificate back to the older one, agents run without issue)

from meshcentral.

@D4V3M0NK so you cant simply curl -v https://meshcentral.mydomain.com
on your meshcentral machine and get a reply? that seems a bit odd or very strict networking?
but yes ive checked the functions in meshcentral and the decode of the certs reads
// Decode a RSA certificate and hash the public key, if this is not RSA, skip this.
so indeed it doesnt work yet with ECDSA certificates,
but sadly all my lets encrypt certificates are RSA256, even the one i just issued today from my meshcentral dev machine,
so i need to get a ECDSA certificate to then do some testing,
as we do indeed use forge nodejs package so in theory it should work maybe?

from meshcentral.

@si458 - I sincerely appreciate your responses and you're correct, we have a requirement for incredibly secure networking. I really appreciate you taking the time to look into this and I'm glad that the issue has at least been identified.

LE will (by default) now produce EC certs as long as certbot 2.0 or later is being used. We use their docker container to re-generate the certs and, according to their documentation, ECDSA certs will be produced, unless prior certs were RSA. For some reason that didn't work in our case, we historically keep all prior certs for verification purposes, and found that between yesterday and 90 days prior, the key changed from RSA to EC.

We've been able to re-generate RSA certs, but it's still not working as we expected so there's likely something else going on that I am investigating (I suspect a DNS mismatch, but...)

Could I ask - is there any additional logging that could be enabled on the agent's side? Reason being is that we used URL-A to register the agents against a couple of years back. Due to processes that would take too long to get into, we recently (6 months?) use URL-B now - with the proxies routing between the two. With the exception of the MFA on the server side, this "dual DNS" works without any issues - up until these certs. Are you aware of any other areas (specifically on the agent side) where this DNS would run foul of processing the certs? All generated certs have both URL-A and URL-B as SubjectAltNames (along with a range of other hosts that we use to point to the proxy server: we then use AWS Application Load Balancing to route the traffic to Auto Scaling Groups based upon the hostname being called).

from meshcentral.

@D4V3M0NK oh wow you have a very complex setup! way too complex for me to even understand!

but from what im aware when i look at the meshcentral code,
all meshcentral does is verify that the ssl hash the remote agent sent it is the same as its ssl hash it got from the certurl,
if they dont match then bye bye disconnect.

as for having mutliple dns entries in the SSL, i dont think this should matter so long as whichever url you use for the meshagent to connect to, is the same as the certurl in meshcentral,
as meshcentral ONLY checks 1 SSL cert, and if its invalid for whatever reason, it then checks again just be to sure when a remote agent connects again.

i could be totally mistaken to everything ive said, im still learning all the things meshcentral has hidden/feature it has as i fix bugs and discover things by talking to people and there setups!

one other thing to note, from what ive read with other issues, meshcentral DOESNT support the SPLIT dns.
e.g. meshcentral.example.com on the internet which points to ur external ip
but using meshcentral.example.local for internal use to point to ur internal ip
this has something to do with the certurl and the cert values again if i remember

from meshcentral.

@si458 : can I ask - would an agent have issue with a 4096 bit size RSA key, rather than a 2048 bit key? I appreciate that the hash should still match, but that's the only other item (on the cert side of things) that I can see as changing. I would think that the keysize wouldn't matter, maybe take a few milliseconds more to compute, but as I said, I thought I'd ask...

from meshcentral.