Hello, I've got a situation where I don't get the subdomain LE cert next to the domain one and I assume it's because of the webserver directive to redirect to /roundcube. System is Ubuntu 18.04 LTS, nginx. Website configuration for domain.com is as follows: Domain tab Auto-Subdomain: www. SSL: check LE SSL: checked Active: checked Redirect tab Redirect Type: No redirect SEO Redirect: domain.tld => www.domain.tld Rewrite HTTP to HTTPS: checked Options tab Nginx directives: Code: location /roundcube { root /usr/share/; index index.php index.html index.htm; location ~ ^/roundcube/(.+\.php)$ { try_files $uri =404; root /usr/share/; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; fastcgi_param HTTPS on; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include /etc/nginx/fastcgi_params; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_buffer_size 128k; fastcgi_buffers 256 4k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; } location ~* ^/roundcube/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /usr/share/; } } location /webmail { rewrite ^/* /roundcube last; } Subdomain for website: webmail.domain.com Host: webmail Redirect Type: last Redirect Path: /roundcube/ Don't add to LE cert: unchecked Active: checked Now the main website gets the LE cert and is accessible under www.domain.com with the redirect as it should. I can access webmail.domain.com and get redirected to https://webmail.domain.com/roundcube fine, but the webmail.domain.com isn't being added to the LE cert. I assume that my nginx directives might has something to do with it, since the code for the subdomain gets added fine by the GUI changes above and it includes an exception for .well-known (at least it seems so?). The vhost autoconfiguration is : Code: *snip* server_name domain.com www.domain.com webmail.domain.com; root /var/www/domain.com/web/; if ($http_host = "webmail.domain.com") { rewrite ^(?!/(roundcube|stats|error|\.well-known/acme-challenge))/(.*)$ /roundcube/$2 last; } if ($scheme != "https") { rewrite ^ https://$http_host$request_uri? permanent; } *snip* Any insights how to get the webmail.domain.com cert with the roundcube redirect?
Eh? It says "Don't add", which means if it would be checked it wouldn't add the subdomain to the given LE cert, which is the opposite of my desired end result. I've also tested that if that's checked, the webmail.domain.com isn't added to the LE cert. If I uncheck it, the webmail.domain.com isn't added to the LE cert + the "LE SSL: checked" under the Domain tab gets unchecked which means that something is wrong with assigning the LE cert.
Sorry, my mistake. I have the flu, so double negative was too much for me. Try this: https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/
Yeah, I know that the LE is failing because the .well-known folder is not reachable. My question is how the nginx directive for accessing /roundcube should look like instead. The directive above is in all the ISPconfig installation tutorials, so maybe an updated one wouldn't be that unhelpful. If I actually knew regex, I wouldn't be asking this question.
The directive that is part of the tutorials is not redirecting to a webmail subdomain, it is meant to be added into a normal website. The directive is basically an alias for /roundcube of the website to /usr/share/roundcube directory plus a redirect from /webmail to /roundcube. Let's encrypt is neither using /roundcube nor /webmail path to authenticate the cert, so the nginx directives are fine as they are. Try to disable the redirect that you configured for the webmail subdomain, then disable LE in the website, click save, and then enable LE in the website again to see if the cert can be created then.
Problem is that the LE certificates aren't recreated with that simple change, if I do what you said I get: Code: 2020-02-12 10:03:04,246:INFO:certbot.renewal:Cert not yet due for renewal 2020-02-12 10:03:04,246:INFO:certbot.main:Keeping the existing certificate If I try the configuration above with redirect to /roundcube/, it fails with 404 on a site where the webmail.* isn't included yet and I'm implementing it fresh. Here's from the letsencrypt.log (redacted): Code: 2020-02-12 09:56:12,782:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server: Domain: webmail.domain.com Type: unauthorized Detail: Invalid response from http://webmail.domain.com/.well-known/acme-challenge/kY6beG4nKGAqxlEp4VR85NX3ihSV8zQFCVNKvmcLP70 [19x.x.x.x]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>" I mean I could probably change the .vhost manually to go over this, but that would break managing the file from the GUI.
I'm using Apache, added "webmail.example.com" as website, and as Apache Directive Code: DocumentRoot "/var/lib/roundcube" I think the correct directive for NGINX would be Code: root /var/lib/roundcube;
If you mean like this: Code: location /roundcube { root /var/lib/roundcube; index index.php index.html index.htm; location ~ ^/roundcube/(.+\.php)$ { try_files $uri =404; root /var/lib/roundcube; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; fastcgi_param HTTPS on; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include /etc/nginx/fastcgi_params; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_buffer_size 128k; fastcgi_buffers 256 4k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; } location ~* ^/roundcube/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /var/lib/roundcube; } } location /webmail { rewrite ^/* /roundcube last; } It opens roundcube from www.domain.com/webmail, but not on subdomain webmail.domain.com with redirect "last" to /roundcube (404 error).
