I used the following configuration to enable letsencrypt:
VIRTUAL_HOST=example.com,www.example.com,sub.example.com
LETSENCRYPT_HOST=example.com,www.example.com,sub.example.com
[email protected]
Due to some technical difficulties with some applications accessing sub.example.com I wanted to revert back to HTTP for sub.example.com, but can't seem to get it working. I first tried to remove the sub.example.com from just the LETSENCRYPT_HOST configuration, but the the Encryption config for the nginx with 301 for http requests is still present, even after redeploys of both the nginx-proxy and the companion container. I next tried to run the sub.example.com domain through a completely different container without ever specifying any letsencrypt environment variables, but the encryption config is still generated. Any clues?
Yes you must first remove the sub.example.com domain from the LETSENCRYPT_HOSTenv variable.
You must also remove the links in the certs directory so the docker-gen container (or nginx-proxy) will not create a configuration to redirect http to https for the sub.example.com.
By links in the certs directory you mean the crt, key and dhparam?
Yes all the files that correspond to the sub.example.com domain
I deleted the files, can i somehow trigger a regeneration of the nginx config manually?
The best is to restart your web container
Ok i tried a few things and only could get it working if i removed the encryption for all three domains. Seems like if the domain is present in any certificate (as it is a SAN certificate), the proxy automatically rewrites it to https. The thing is I can't create a certificate only containing example.com and www.example.com right now since I hit the Letsencrypt API limit.
Is this expected behaviour or could it be changed so the domain is only rewritten to https if a explicit crt and key file is present?
Okay i dug around some more and found the real issue. Since I have an example.com certificate present, the nginx-proxy uses it as a wildcard-certificate and automatically assigns it to the sub.example.com domain. A workaround for this is setting the CERT_NAME environment variable to an empty value, although it requires the sub.example.com domain to be configured on an own container, as it would otherwise also remove the HTTPS from example.com and www.example.com. The issue is also described here: https://github.com/jwilder/nginx-proxy/issues/182 Thanks for the support though!
@flqw YOUR THE MAN! been searching this for hours, great workaround.
Most helpful comment
Okay i dug around some more and found the real issue. Since I have an example.com certificate present, the nginx-proxy uses it as a wildcard-certificate and automatically assigns it to the sub.example.com domain. A workaround for this is setting the
CERT_NAMEenvironment variable to an empty value, although it requires the sub.example.com domain to be configured on an own container, as it would otherwise also remove the HTTPS from example.com and www.example.com. The issue is also described here: https://github.com/jwilder/nginx-proxy/issues/182 Thanks for the support though!