You might have a rewrite rule happening somewhere that is stripping the request uri off the end.
Per @JuergenAuer's wisdom, that looks like something happening in your website's application. Please read the end of my next long response for further details:
Thanks for your patience with me @JuergenAuer. I know I still have much to learn.
Your evaluation explains a lot. I was wondering why it only seemed to be happening from the client side. It might explain why there's a 200 for absolutely every address I've tested too, including yours: http://cytconectar.com/.well-known/acme-challenge/1234
Will this "application redirect" really not affect the certification process?
Upon further inspection, it appears that the same page is returned regardless of what request uri is specified. This is some type of override on the server. There needs to be an exception to allow the real content of anything requested in the http://cytconectar.com/.well-known/acme-challenge/ directory to be returned without override.
This could very well be a rewrite rule WITHOUT a redirect on the server. Perhaps the server passes the request uri to the serverside application file, which then returns whatever content it deems appropriate from that point?
So Letsencrypt has the wrong content. But it's a problem of your - unknown - application.
PS: Your config shows a proxy. So create an exception of /.well-known/acme-challenge, so you can use that with webroot. And why do you use webroot? Is /var/www/letsencrypt defined? If not, your command can't work.
PPS: Disclaimer: It's not my job to check answers of other users. One other answer is wrong again.
What are the contents of cytconectar.com.conf? Perhaps the answer lies there. You may have already completely posted it above, but I just want to make sure. Let's take a look. Please put three backticks (`) on lines above and below the contents so they're easy to read here. How did the changes you make here differ from the other? This might help us understand. Your situation is different than what we typically encounter here, but I for one am willing to learn something from this.
Being empathic is the right thing to do in its own right, but it’s especially valuable in encrypting the web. One of the many reasons we don’t have more encryption on the web today is that the skills required are too arcane. If we can help people learn those skills, or if we can get feedback from people that helps us make things clearer, we further the mission of encrypting the web.
server{
listen 80 default_server;
# this could be your IP address, a subdomain or a full domain
server_name cytconectar.com;
access_log /var/log/nginx/app.dev.access.log;
error_log /var/log/nginx/app.dev.error.log;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header X-Forwarded-For $remote_addr;
}
}