When enabling Proxy Website in Server Configuration to point to another Website, the original letsencrypt certs will not autoupdate. This is an issue when the main domain of the server (dns, smtp, imap) points to another website (corporation) for instance.
When Website root (/) redirects of the virtual server are issued to always point to the https Root: (/ to https://thisvirtual.domain/) to prevent NON https access to the site.
When Wordpress is installed to point to https://virtual.domain it doesn´t work either.
Every Lets Encrypt Autoupdate was a failure and drama since the virtualmin server is running. It is simply not working-
Parsing account key... Parsing CSR... Registering account... Already registered! Verifying virtual.domain... Traceback (most recent call last): File "/usr/libexec/webmin/webmin/acme_tiny.py", line 203, in main(sys.argv[1:]) File "/usr/libexec/webmin/webmin/acme_tiny.py", line 199, in main signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca) File "/usr/libexec/webmin/webmin/acme_tiny.py", line 128, in get_crt wellknown_path, wellknown_url)) ValueError: Wrote file to /home/virtual.domain/public_html/.well-known/acme-challenge/SjxD9v92aCVRxvpP1owF4cdFkGvKyqONfa3Lzg7rmGE, but couldn't download http://virtual.domain/.well-known/acme-challenge/SjxD9v92aCVRxvpP1owF4cd...
Comments
Submitted by mike0810 on Sun, 07/31/2016 - 07:58 Comment #1
When there is for instance a thight .htaccess rule installed, like https://srd.wordpress.org/plugins/all-in-one-wp-security-and-firewall/ the autoupdate does not work either. So it is not possible to redirect http to https in general and to enable AIOWPS without bothering the autoupdate.
There should be a more generic way to issue and update the certificates for specific vhosts which does not interfere with hosting specific (or client specific) issues.
Submitted by mike0810 on Sun, 07/31/2016 - 08:09 Comment #2
https://wordpress.org/support/topic/lets-encrypt-not-supported?replies=1...
Submitted by JamieCameron on Sun, 07/31/2016 - 18:06 Comment #3
Unfortunately there isn't a good way around this - Let's Encrypt service needs to make a request to your website to validate ownership, and it does this by fetching a specific URL under /.well-known . So if this is blocked by proxying, htaccess rules or a change to the document root, that validation will fail.
Submitted by ChrisBlackwell on Tue, 08/09/2016 - 05:35 Comment #4
I've just run into the same letsecrypt/proxy issue. for now i've just added
<Location /.well-known>ProxyPass !
</Location>
Seems like in an attempt to make it simple for the most common use case, they (LE) have made it horrendously complex for every other use case
Submitted by JamieCameron on Wed, 08/10/2016 - 00:04 Comment #5
That works for proxying (and should be done automatically in Virtualmin 5.04), but I don't know of any equivalent for redirects.
Submitted by webinger on Fri, 08/31/2018 - 06:23 Comment #6
I also use a proxy pass function for certain php scripts which I use for multiple domains so I only have to maintain one installation/copy later. I also used ProxyPass !
on such domains. works fine and keeps letsencrypt running automatically.
some php scripts also got restrictive htaccess files that prevent access to /.well-known it would be fine to have some function that checks for such problems.
You may have some idea what to put into the apache config to prevent htacess files in general to block access to /.well-known?