Appwrite 1.4.0 TLS hostname verification change for custom domains

Short answer

Appwrite 1.4.x is expected to enforce SAN-based hostname verification and no longer fall back to Common Name (CN) when a certificate lacks a matching Subject Alternative Name. This aligns with the deprecation of CN matching in RFC 6125 and RFC 2818 and with the strict verification behavior reported for the 1.4.0 release. If your custom-domain certificate is CN-only, TLS clients will likely reject it with a hostname mismatch error.

Likely explanation vs. confirmed facts

Likely explanation: The 1.4.x update tightened TLS validation by relying on the hostname verification logic in the underlying TLS library (OpenSSL or Go) used by the Appwrite Docker image. Current versions of these libraries ignore the CN field for hostname verification entirely.

Confirmed facts: CN-only certificates are legacy artifacts rejected by modern browsers and TLS libraries. The _APP_WRITE_ENABLE_SSL_VERIFICATION environment variable controls whether Appwrite verifies TLS certificates when making outbound requests to external or internal services. It does not govern how Appwrite terminates inbound TLS for custom domains.

Steps to maintain compatibility

1. Reissue the certificate with a SAN. Add the custom domain as a DNS: entry in the Subject Alternative Name extension. This is the only durable fix.
2. Verify the certificate before deployment: openssl x509 -in cert.pem -text -noout | grep -A1 "Subject Alternative Name"
3. Test the handshake: curl -v https://your-custom-domain 2>&1 | grep -i "SSL certificate problem"
4. Inspect Appwrite logs for certificate verification failures or hostname mismatch errors during startup or request handling.

Is _APP_WRITE_ENABLE_SSL_VERIFICATION the right control?

No. This variable is not the reliable way to control custom-domain TLS acceptance. Disabling it removes outbound certificate validation and exposes the deployment to man-in-the-middle attacks. It will not make Appwrite accept a CN-only certificate on an inbound custom-domain connection.

What remains uncertain

The exact 1.4.x behavior depends on whether TLS for your custom domain is terminated by Appwrite's internal server or by an upstream reverse proxy in your Docker Compose stack. If a proxy terminates TLS, the proxy—not Appwrite—decides whether to accept CN-only certificates. Because version-specific behavior can vary with the Docker image's TLS library, verify against your deployed 1.4.x image before relying on this in production.

One diagnostic that would change the recommendation

Does the failure occur when external clients connect to your custom domain, or when Appwrite services make outbound requests to that domain? If the former, focus on your TLS termination layer and certificate SANs. If the latter, _APP_WRITE_ENABLE_SSL_VERIFICATION is relevant, though reissuing with a SAN remains the safer fix.