-
Notifications
You must be signed in to change notification settings - Fork 23
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
Self-hosting with reverse proxy #319
Comments
Hi Christoph, thank you for your interest in self-hosting Passwordless.dev. I will look into it. Feel free to send me an e-mail to schedule a call as you see fit to walk things through. At first glance, it does not look like your certificates are being overwritten by the |
Hi @pocki, I've published a bug fix. We're currently working on publishing the image. |
I tried the new image v1.0.56: I think there is a misunderstanding: I use the reverse proxy traefik for all the SSL/TLS stuff. Variant 1:
Log:
results in Bad Gateway which is clear, as NGINX don't allow https requests. Variant 2:
Log:
result in Bad Request: The plain HTTP request was sent to HTTPS port. Here is an example how it normally looks like with traefik when the system needs the calling Url (ex. Nextcloud):
PS: I have to switch to docker hub as it seems that the ghcr don't have the latest image pushed. |
I got it working, but logging looks strange:
Log:
Please have a look at the API public url. |
@pocki Have you tried setting:
Then paste the private key in the root of the mounted volume.
|
I don't want to share the SSL Key in the container - it is not needed. |
How to setup self-hosting passwordless server with a reverse proxy.
My entry in docker-compose.yml and getting "Bad Gateway" errors:
Log from container:
The scheme for public urls must be https but there should no certificates generated.
I am using Traefik as reverse proxy which handles everything about Certificates
When I am extracting the SSL Certificates from Traefik and assign in the docker container, still the same "Bad Gateway" errors. It seems that the startup/entrypoint still wants to override existing certificates.
Log from container:
The text was updated successfully, but these errors were encountered: