That is for that line, also I’ve uncommented this like you said:

location /.well-known/acme-challenge/ {
root /var/www/certbot;

did you reload nginx after uncommenting that?

docker-compose exec nginx nginx -s reload

1 Like

That helped:

but when I do docker-compose up again same error:


1 Like

reload nginx again. you have the new cert but nginx doesn’t know yet.

1 Like

I stopped and removed all containers and then run them again and still same error persists.

let me see partials/ssl.conf

I don’t see your new certificate:

What’s certbot congratulating you about?

Here is ssl.conf

#ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ecdh_curve              secp384r1:secp256k1;
#ssl_prefer_server_ciphers   on;
ssl_dhparam                 /etc/letsencrypt/ssl-dhparams.pem;
include                     /etc/letsencrypt/options-ssl-nginx.conf;
ssl_certificate             /etc/letsencrypt/fullchain.pem;
ssl_certificate_key         /etc/letsencrypt/privkey.pem;
#ssl_session_timeout         10m;
#ssl_session_cache           shared:SSL:10m;
#ssl_session_tickets         off;
ssl_stapling                on;
ssl_stapling_verify         on;

#ssl_session_cache shared:le_nginx_SSL:10m;
#ssl_session_timeout 1440m;

#ssl_protocols TLSv1.2 TLSv1.3;
#ssl_prefer_server_ciphers off;

ssl_certificate             /etc/letsencrypt/fullchain.pem;
ssl_certificate_key         /etc/letsencrypt/privkey.pem;

replace with

ssl_certificate             /etc/letsencrypt/live/;
ssl_certificate_key         /etc/letsencrypt/live/;


it’s a 404, you should check your server service


Yes, you are right.

Can you maybe explain to me why I had to uncomment those lines now, and comment them before?

#    location /.well-known/acme-challenge/ {
#        root /var/www/certbot;
#    }

those lines are telling nginx “when somebody asks for files from /.well-known/acme-challenge/ go look in /var/www/certbot and send them those files.”

certbot will write something there, and the validation service expects to find it. without those lines, all the validation service will get is a 404 or other 4xx error.

I don’t know/remember why you commented them.

1 Like

Thank you very much, you have helped a lot.

I’ve find the issue for 404 error but I’m gettings this error now and I think it’s connected with SSL:


1 Like

I still haven’t been able to solve this error…


You are allowing access via both: and
Maybe if you choose to use only one…
As a test, you could try redirecting one to the other (and force all connections via one single FQDN).

1 Like

Well I’ve done certificates on both domains on advice of @9peppe here in the thread, I don’t understand why is that a problem for sending an email? @rg305

I’ve read the suggested article but still no luck.

Sending emails out?

My suggestion was for merely testing purposes.
I would try setting all to one name, test, then the other name, retest.
And compare that to when both names were in use.
If any is better, or worse, it may provide a “clue”.

CORS prevents one domain from accessing resources on another, unless authorized. Read that page about it, it will give solutions.

I’ve did this in my server.js app, but error persists…

I tried this too but it still doesn’t work… @9peppe

app.use(cors({credentials: true, origin: true}));

What is interesting, I downloaded this tool: and when I open chrome that is monitored by it, everything works:

But then I open normal google chrome browser and I get this in network tab and mail isn’t sent…