Apologies @scientes I’ve referenced an option that is part of the next release.
What you can do here is set LETSENCRYPT_HOST variable (any kind of value). This tells corteza server that some software in front of it will handle SSL and it needs to use HTTPS URL schema.
Why this name? Because we are (usually) relying on Docker Hub to manage SSL certificates and we can control that with LETSENCRYPT_HOST.
We recognised this approach as a bit too narrow-minded and prepared HTTP_SSL_TERMINATED to be supported (in Septembers release - 2021.9).
Starting Corteza and registering a new (admin) user works perfectly well via the reverse proxy via https. The log files show no errors. But when I try to access https://corteza.domain.tld I only get a blank white screen. The JavaScript console shows the following errors in index.es.js in line 1027:
If you changed your HTTP/HTTPS setup AFTER you installed Corteza please check auth, redirection and other URLs in your settings. There might be some pointing to invalid schema.
Thank you for your quick response. I’ve reinstalled Corteza several times; every time I changed settings in .env I’ve reinstalled the entire system. Just to be sure!
After several restarts and some hours leaving the system alone the configuration posted above ist running well. Maybe some wired caching problems led to the problem.
I have this similar problem with mixed content (don’t know if I should open up a new thread). I unfortunately can’t get to the admin panel
My setup is the following: NGINX Proxy Manager (GUI) + Cloudflare Flexible SSL + Corteza with Percona (Docker containers).
I have successfully created the containers and the Corteza instance is available through my domain (with SSL). I have sucessfully registered my first account, however, after confirming the email, I get this error message for mixed content:
Mixed Content: The page at 'https://corteza.my_domain.tld/admin/auth/callback?code=<some code>' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://corteza.my_domain.tld/auth/oauth2/default-client'. This request has been blocked; the content must be served over HTTPS.
The part: corteza.my_domain.tld is replaced with my real domain. I could DM you the real domain if needed.
docker-compose.yaml (ommited the part for the percona DB container):
version: '3.5'
services:
server:
image: cortezaproject/corteza:${VERSION}
restart: always
env_file: [ .env ]
depends_on: [ db ]
networks: [ nginxproxymanager_default, internal ]
ports: [ "10015:80", "10415:443" ]
# Uncomment to use local fs for data persistence
volumes: [ "./data/server:/data" ]
environment:
# This two are needed only if you are using NginX Lets-Encrypt companion
# (see docs.cortezaproject.org for details)
# VIRTUAL_HOST helps NginX proxy route traffic for specific virtual host to this container
VIRTUAL_HOST: ${DOMAIN}
# LETSENCRYPT_HOST helps NginX LE companion pull and configure SSL certificates for your domain
LETSENCRYPT_HOST: ${DOMAIN}
.env file (I ommited the SMTP info)
########################################################################################################################
# General settings
DOMAIN=corteza.my_domain.tld
VERSION=2022.9
########################################################################################################################
# Database connection
DB_DSN=some_user:some_pass@tcp(db:3306)/some_db?collation=utf8mb4_general_ci
########################################################################################################################
# Server settings
# Serve Corteza webapps alongside API
HTTP_WEBAPP_ENABLED=true
HTTP_SSL_TERMINATED=true
# Send action log to container logs as well
# ACTIONLOG_DEBUG=true
# Uncomment for extra debug info if something goes wrong
LOG_LEVEL=debug
# Use nicer and colorful log instead of JSON
LOG_DEBUG=true
########################################################################################################################
# Authentication
# Secret to use for JWT token
# Make sure you change it (>30 random characters) if
# you expose your deployment to outside traffic
AUTH_JWT_SECRET=some_secret_key
AUTH_BASE_URL='https://corteza.my_domain.tld/auth'
I have read and googled almost everything I could find. I have reinstalled Corteza several times (just in case something didn’t propagate when I changed the container variables), and this is my only hope for help - so any suggestions are much appreciated
Additional info: the SSL is forced through Cloudflare.
I had the exact same issue and could solve it by changing the SSL certificate. At first I requested a LetsEncrypt certificate where I also opted for HSTS Enabled. HSTS is a mechanism to prevent MIM attacks.
After getting a new certificate without HSTS enabled it worked.
I hope this can help you (even after more that a year)
do you have any more info on that one? Nginx logs, letsencrypt logs?
Certificate is definitely valid?
Most of the time letsencrypt does not generate the certificate is when the domain is not resolvable to a host, so checking the DNS settings on the domain should help.
when trying to log into a known good Corteza-internal user account account. Worth noting: end-users’ browsers communicate through a reverse proxy.
The fix was defining the LETSENCRYPT_HOST environment variable inside the service container and ensuring the DOMAIN environment variable was precisely equivalent.
