meli
meli copied to clipboard
getmeli
SSL fails on branches
In my deployment, I've found SSL certificate generation works perfectly for the primary subdomain for a site hosted in a Meli instance, but consistently seems to fail for branch subdomains.
I see the following error in the log output:
{"level":"debug","ts":1628840270.8583307,"logger":"http.stdlib","msg":"http: TLS handshake error from 69.28.90.113:58350: no server TLS configuration available for ClientHello: &{CipherSuites:[4866 4867 4865 49196 49200 159 52393 52392 52394 49195 49199 158 49188 49192 107 49187 49191 103 49162 49172 57 49161 49171 51 157 156 61 60 53 47 255] ServerName:main.demo.pages.qa SupportedCurves:[X25519 CurveP256 CurveID(30) CurveP521 CurveP384] SupportedPoints:[0 1 2] SignatureSchemes:[ECDSAWithP256AndSHA256 ECDSAWithP384AndSHA384 ECDSAWithP521AndSHA512 Ed25519 SignatureScheme(2056) SignatureScheme(2057) SignatureScheme(2058) SignatureScheme(2059) PSSWithSHA256 PSSWithSHA384 PSSWithSHA512 PKCS1WithSHA256 PKCS1WithSHA384 PKCS1WithSHA512 SignatureScheme(771) SignatureScheme(769) SignatureScheme(770) SignatureScheme(1026) SignatureScheme(1282) SignatureScheme(1538)] SupportedProtos:[h2 http/1.1] SupportedVersions:[772 771] Conn:0xc000d0c030 config:0xc000001380}"}
and in browsers loading the branch subdomain just fails with an SSL protocol error.
Testing both using the default CA (which, following Caddy's change, seems to now be ZeroSSL) and with manually setting the ACME server to Let's Encrypt via MELI_ACME_SERVER: https://acme-v02.api.letsencrypt.org/directory, the error seems to consistently happen.
Using Meli image: getmeli/meli:beta, 1.0.0-beta.20 per package.json.
Ah, I saw that but assumed that was only the situation when running behind a reverse proxy. Perhaps it would make sense to copy that warning over to https://docs.meli.sh/configuration/ssl ?
I think implementing #233 will make the situation easier, without having to mess around with sudomains of subdomains. Follows what Netlify does with having a subdomain like f78gh0f7wgff4fwdsa--sitename.netlify.app
@alyx as @MrLemur rightly raised, this is an issue we still need to fix. This change is making it to the top of our todo list and we will implement it just like Netlify. We'll be using -- as a separator and prevent users from using this separator in their site name.
