Don't bind to 443

[belst]

Hi,

I have already nginx running on that machine and just wanted to try mox, but I tries to bind to 443. I'd happily reverse proxy it but I need to be able to change the port mox binds to.

Is this configurable? Also what would I need to proxy or disable for it to not bind to 443?

[belst]

I just saw that there is an explanation in the PS of quickstart. I will try providing my own certificates

[mjl-]

You will also need the latest code from git. In v0.0.1 you'll get an error. See issue #2. I'll add to the quickstart PS that you also need to remove the ACME config from the TLS section in the listener.

[idnovic]

I think this is alright. You need to bind a different external port for your usecase.

But does mox accept not encrypted communication on 443? In a reverse proxy setup. Can you clarify why does mox create the certificate in the first place and would it work with an external certificate at the reverse proxy if mox does not have access to it?

www--->443:Reverse_tls_proxy:8443--->443:mox but http only on 443

[belst]

I am currently trying to proxy the interface but it tries to do xhr to localhost:configuredport instead of proxydomain:443. can I somehow configure the base domainname/port or would it be possible to just have those as relative requests?

when using HTTPS with custom port and no proxy I do get the correct domain but it tries to use http for all the api requests which CSP blocks

[mjl-]

@belst

I am currently trying to proxy the interface but it tries to do xhr to localhost:configuredport instead of proxydomain:443. can I somehow configure the base domainname/port or would it be possible to just have those as relative requests?

Good idea, I made that change in the latest commits.

when using HTTPS with custom port and no proxy I do get the correct domain but it tries to use http for all the api requests which CSP blocks

Not sure what you mean here. It tries to do plain http for those https calls? I think it should be solved with the change to use a relative path for the API endpoints. Let me know if there is still an issue.

@idnovic

But does mox accept not encrypted communication on 443? In a reverse proxy setup. Can you clarify why does mox create the certificate in the first place and would it work with an external certificate at the reverse proxy if mox does not have access to it?

I added an option "NonTLS" to the AutoconfigHTTPS and MTASTSHTTPS sections, to do plain HTTP instead of HTTPS, for the case of reverse proxying. Could you check if that works for you?

I'm curious: do you already have a TLS cert-refresh script for the reverse proxy that you'll be using for mox as well? I figured folks would also want automatic TLS with ACME for their mail server. But I also foresaw folks wanting to install mox on an existing VPS that already has a webserver. But I feel it takes away from the simplicity of setting up mox.

[belst]

do you already have a TLS cert-refresh script for the reverse proxy that you'll be using for mox as well? I am just using dehydrated (with dns challenge) in a systemd timer to manage my certificates

gonna try out the new version now

edit: the relative url stuff seemed to have fixed it

[idnovic]

I'm curious: do you already have a TLS cert-refresh script for the reverse proxy that you'll be using for mox as well?

Yes I am currently using SWAG. It handles the let's encrypt stuff.

I do concur with your assessment though. On dedicated machines I would prefer if mox handled the cert requests.

I still need to do a proper test. I should have time in between until tomorrow evening. You will then get a report but with podman plus reverse proxy instead of docker.

[tk512]

Found this thread. My setup is nginx with Lets Encrypt, then I would like to run mox on the same server. How would I do this? I saw a note about using mox config describe-static but it wasn't completely clear to me.

[mjl-]

I would like to run mox on the same server. How would I do this?

You would at least disable the use of ACME by removing "ACME: letsencrypt" in the TLS section of the "public" listener. And replace it with something like the following (under the same TLS section):

KeyCerts:
        -       
                # Certificate including intermediate CA certificates, in PEM format. 
                CertFile: mail.yourdomain.crt.pem

                # Private key for certificate, in PEM format. PKCS8 is recommended, but PKCS1 and
                # EC private keys are recognized as well.
                KeyFile: mail.yourdomain.key.pem

(This is also where mox config describe-static may help, it contains all config keys including comments, the file written by the quickstart does not include config keys with default (zero) values.)

You would also have to set Enabled: false for AutoconfigHTTPS and MTASTSHTTPS (and remove the DNS records for autoconfig and mta-sts), or keep those enabled but at a different Port and probably with NonTLS true and your nginx configured as reverse proxy (https) for the autoconfig and mta-sts domains.

Hope this helps. Let me know if you run into issues and/or if we should clarify the docs.

[mjl-]

I plan to add a FAQ about not giving mox port 443 and bringing your own certs. And replace the rather large "PS" at the end of the quickstart with a link to the question.

[mjl-]

On second thought, it probably makes more sense to add a flag to the quickstart command for using an existing https server/reverse proxy, and generate a config file in which you only have to add your own certs/keys. I'll aim for that.

[tk512]

@mjl- Agreed, I think this is a fairly common use case. Especially for the crowd looking at mox for a simpler or more contained way of gaining e-mail independence.

[idnovic]

I tested a reverse proxy setup with SWAG and podman.

Look at these 2 comments for more info https://github.com/mjl-/mox/issues/3#issuecomment-1451402688

I will retry with a newer mox build after it becomes available. It did not work for me, yet. I provided the podman commands I used. But removed to local port binding for the reverse proxy.

[mjl-]

the commit just added is to add an option to the quickstart: -existing-webserver, see the commit message for details.

i've used it earlier tonight to set up a test server where caddy was the reverse proxy and got me the tls certs/keys.

i had to make a few more fixes to make it work smoothly. hopefully this makes it work for you.

on the other hand, i also added webserver functionality to mox a few commits before. reverse proxy, static files. has been enough for me to switch over to webserving using mox. the idea was to take away most of the reason to want to use another reverse proxy. so you could consider that too.

[gedw99]

thanks @mjl- Using it with Caddy is exactly my use case. Wil try it also.

[morki]

@mjl- @gedw99 can you please help with some instructions making it work with caddy reverse proxy?

[mjl-]

@morki good question, i tried running with -existing-webserver just now, but it is broken, with an error message checking generated config: tls config for "listener public": parsing x509 key pair: reading tls certificate: no file descriptor for file config/path/to/host.mox.example-chain.crt.pem. i'm guessing you ran into that error. i pushed a commit just now that should let "mox quickstart -existing-webserver ..." generate a working mox config. the caddy config to reverse proxy probably won't be an issue, but let me know if it is.

the latest commit is close to being released as v0.0.6 (hopefully within a few days, but it always takes longer when i say planned releases out loud), so it should be safe to start with the latest commit (it's what i'm running).

if you have another issue that isn't solved with this commit, i'm interested in any error messages or info on where you are stuck.

[gedw99]

@morki

Here is a generic example to try that does reverse proxy aspects.

1. deps

get caddy https://github.com/caddyserver/caddy/releases/tag/v2.6.4

get mkcert https://github.com/FiloSottile/mkcert/releases/tag/v1.4.4

• mkcert ( golang tool ) makes your local laptop trust the certs in the browsers.

3. .env file:

export CADDY_SRC_DOMAIN=app1.example.com

4. Create Caddyfile ( MUST be named this way )

# from: https://caddyserver.com/docs/caddyfile/directives/forward_auth#authelia

# Serve the authentication gateway itself
auth.example.com {
	reverse_proxy authelia:9091
}

# Serve your app
app1.example.com {
	forward_auth authelia:9091 {
		uri /api/verify?rd=https://auth.example.com
		copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
	}

	reverse_proxy app1:8080
}

5. run

# make the certs
mkcert -install
mkcert $(CADDY_SRC_DOMAIN)

# fit the Caddyfile
caddy fmt --overwrite 

caddy run 

[mjl-]

I think the issue was solved. Feel free reopen if there is still something to do for this issue.

[gedw99]

Using mkcert with Caddy is no longer needed btw.

Caddy has its own code that replaced mkcert.

I still use hostctl golang lib as binary to help with configuring the etc file though so it maps to the Caddy config. These two binaries makes provisioning easy and works on Window, Mac and Linux and openBSD

Feels like Max needs a deployment examples folder in the code, with a Makefile, so devs / users can see how to deploy it