-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nginx proxy path #218
Comments
I hope I'm understanding your situation and goal. Hopefully the answer below can get you on your way.
I think you have nginx receiving regular https traffic on port 443, and you are forwarding at least "/.well-known/acme-challenge/" to mox, that you want to let listen on port 443? Using a https reverse proxy (like nginx) will not work with acme's verification: That verification uses tls-alpn-01, which means the original TLS connection from the ACME provider (for example Let's Encrypt) must make it to mox. During the TLS handshake, the "application-layer next protocol" extension ("alpn") is used to perform the verification. A reverse proxy like nginx will not pass that information on to mox. So if you're using nginx in front of mox, you cannot use tls-alpn-01 verification with acme. But you should be able to use the http-01 verification. That works with requests over regular http on port 80. So you would have to enable one of the mox webservices (for example "WebserverHTTP") port 80 of your "public" listener. That automatically enables acme http-01 verification. You will have to reverse proxy requests to With mta-sts, you would also have to reverse proxy mta-sts.$yourdomain.example to mox. If you get a message that a domain is not on the allowlist, that would normally mean the domain is not configured in mox, and mox will not retrieve a certificate for it using acme. The allowlist is automatically created based on the hostname (for example mx.yourdomain.example) and the domain(s) (for example autoconfig.yourdomain.example, mta-sts.yourdomain.example).
I don't know why you would get those errors. But it's better to leave the acme port at 443 and only use plain http-01 acme verification. Hope this helps. If you're running into trouble with http-01 acme verification, it would be useful to see configuration file snippets and error logs. |
… not work for acme tls-alpn-01 verification related to #218 by mgkirs
Now mox make cert and can sent post But i can`t get post from google, i am could not connect whith Thunderburd autoconciguration port 143
port 993
https://post.neveru.me/webmail/
|
Thunderbird is connecting to port 25 to do authenticated submission. But port 25 is for email delivery, not submitting with authentication. Thunderbird should be connecting to port 465 with TLS, or to 587 as TCP+STARTTLS. I'm wondering if Thunderbird has really used autoconfig to setup the account. I think that too would require a TLS certificate, but getting a certificate doesn't appear to be working yet. You should manually change the port in Thunderbird to 465 or 587. But then you'll get the same error for now as with connecting with IMAP to port 993: mox cannot get a certificate. So we still need to get ACME working. There are two mechanism that could be used: tls-alpn-01 or http-01. I think both are problematic at the moment:
The "no viable challenge type" error means that tls-alpn-01 and http-01 (and any other mechanisms) did not succeed, which is understandable given the current configuration & mox behaviour.
I've seen this before. This is very likely due to nginx's behaviour of buffering reverse proxy requests by default. The webmail uses a server-sent-events (SSE) connection, that streams data to the browser. But nginx is holding it up in its buffer. You'll need Interestingly (to me least), your screenshot also reveals a bug in the mox webmail! The red box in the lower left indicates an unhandled JS error has occurred. I suspect the Signature field of the settings object is being read when you start composing a message. But that settings object isn't populated yet (the data is still in nginx's buffers). The error should go away with buffering disabled. I'll fix the webmail to not read the settings object when it's not loaded. I'm happy to finally see that error reporting code pay off. (: |
… http (non-tls) webservers (ports), not only to the one listening on port 80 because this mechanism is most needed behind a reverse proxy, where acme tls-alpn-01 won't work (because the reverse proxy won't pass on the alpn extensions). if that's the case, there is obviously a webserver on port 443. and it likely also running on port 80. so before this change, if tls-alpn-01 isn't available, http-01 also wasn't available, leaving no validation mechanisms. for issue #218 by mgkirs, thanks for reporting and details. hope this helps.
@mgkirs Could you try the latest commit? It should enable ACME validation with the "http-01" mechanism: plain http requests. Nginx needs to forward such requests for each domain that needs a TLS certificate. See https://www.xmox.nl/b/#0fbf24160c65f8dd8855533cfaa2b485ee6764d9 for compiling or downloading a binary. |
…the popup after showing an error that the settings aren't available yet missing returning/throwing error. based on screenshot with unhandled js error in issue #218 by mgkirs
|
Those lines are truncated (probably copy-pasted from terminal). Do they say something about http-01 failing? And have you seen an error message explaining the failure? It would be good to check that it isn't still the "too many failed attempts recently" error. And do you see HTTP requests coming in from Let's Encrypt? They should at least be in the nginx logs. |
i can give full log file, but i am was try to connect few different Thunderbird config. i am was wait few time, now
else i am was try to slow Check DNS. i am have few domains mox not configure mx.neveru.me @neveru.me mail.neverume.com:993 STARTTLS
Connection to server mail.neverume.com timed out. mail.neverume.com:993 SSL\TLS
Non-overridable TLS error occurred. Handshake error or probably the TLS version or certificate used by server mail.neverume.com is incompatible. |
I'm seeing entries on crt.sh for your domains (including autoconfig and mta-sts) from Let's Encrypt. Was that the result of successful ACME verification with mox? (: Btw, about timing out connections to 993: Make sure to use direct TLS, not TCP+STARTTLS, on that port. |
What`s you mean? Before patch this is didn't work
i have error
from google |
I looked at https://crt.sh/?q=mx.neveru.me (and similar for autoconfig, mta-sts), and noticed new certificates. Perhaps that's only an intent to hand out a certificate, not a fully granted certificate. By the way, are you seeing logging in mox for http requests for the /.well-known/acme-challenge/ verification? One of your error messages mentioned a "404" response. It would be good to know mox is sending that response, and not nginx.
OK, that indeed is a TLS-level "internal error", likely because there is no certificate. It's a matter of figuring out why the http-01 verification is still failing. |
@mgkirs Any progress? Did you get it working, and can we close this issue? |
i am look to nginx load balancer
but to day i am have some diffrent issues
|
Sending from php doesn't work? Is it this connection?
That seems to be an attempt to submit a message on port 25. Submission only works on ports 465 (TLS) and port 587 (STARTTLS). If messages from google aren't coming in, it is likely a problem with MX delivery. |
Hostname: mx.neveru.me Mox have only one Hostname filed for server on mox.conf mox dose not serve delivery, this config not configure mx servers
what about http certification, it is correct, i think nginx work whith http proxy correct, i am just try restart current mox server with old nginx config this is correct dose not look any errors, certificate cashed Thankee |
i am try to start with nginx, i am do not understand haw to work with ACME, MTA-STS
i am don`t find mta-sts.txt
That config server not for 127.0.0.1
i am try to listen whith nginx but i am do not haw to slow proxy
That give error 400 or 502
if i am connect to $server_addreess:10433 i am look ERR_CONNECTION_TIMED_OUT or SSL_ERROR
OS:
may be its ssl redirects cloudflsare...
some times i am look:
mox[39660]: l=debug m="autotls hostpolicy result" err="autotls: host not in allowlist: \"mx.host\"" pkg=autotls host=host
where is allow list configurations?
The text was updated successfully, but these errors were encountered: