I only have one internet address. The router is doing NAT - hence why there's only once chance to forward 80/443.
I've updated the diagram to hopefully be more clear:
I can't remember the random port I had for wordpress since I deleted it, so 6696 is a made up example.
In the original set up, the router fowards to nextcloud. The only way I could get a certificate on the wordpress vm, was to temporarily remove the forwarding for nextcloud, and point it to wordpress instead. Once wordpress had its certificate, delete the forwarding and recreate it to nextcloud.
This meant I could get to nextcloud easily, and could access wordpress only if I used the random port.
Now I inserted the reverse proxy. In theory it makes it simpler. And for port 80, it works. (I tested wordpress actually since nextcloud forces SSL) - I hit 192.168.0.z and received the wordpress page. The browser still says 192.168.0.z, even though the content is from 192.168.0.y. Perfect. (And I can hit 192.168.0.y directly of course). I can also hit the wordpress.x.y.com DNS entry, retrieve the wordpress page. Good - except it is http at the moment.
Nextcloud forces SSL and simply forwarding port 443 (ie, using "listen 443") in nginx doesn't work - you get an SSL_ERROR_RX_RECORD_TOO_LONG. You have to use "listen 443 ssl" and then supply the location of the certificate.
After letting certbot run on the reverse proxy, and subsequently adjusting it slightly, the relevent block looks like this:
server {
listen 80;
server_name cyberdysfunction.crabdance.com;
# Config http server 1
location / {
proxy_pass http://192.168.178.21:80;
}
}
server {
# Config nextcloud SSL
listen 443 ssl;
listen [::]:443 ssl;
server_name nextcloud.bundykids.crabdance.com;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass https://192.168.0.25:443;
}
ssl_certificate /etc/letsencrypt/live/nextcloud.bundykids.crabdance.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/nextcloud.bundykids.crabdance.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
If I try dry-run on the actual nextlcould VM, it looks like it will succeed:
ncadmin@nextcloud:~$ sudo certbot renew --dry-run
[sudo] password for ncadmin:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/nextcloud.bundykids.crabdance.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Running pre-hook command: service apache2 stop
Renewing an existing certificate
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/nextcloud.bundykids.crabdance.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/nextcloud.bundykids.crabdance.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Running post-hook command: service apache2 start
So both servers, nexctloud and reverse proxy, are able to get their own certificates for the nextcloud.bundykids.crabdance.com domain.
I assume that what is happening, is the nextcloud server is checking with let's encrypt, let's encrypt validates port 80, which succeeds because it hits the reverse proxy and proxies the connection.
I figure this is basically the 'copy the same certs to two servers' option. As I mentioned in the OP, I will need some help to achieve this as I'm not familiar with the guts of linux. Is this a valid path though? Would this be done in corporate land?
I guess I could try to revert the nextcloud VM to using self signed certs, but that seems like a step backwards. And if a use another name (local.nexcloud blah blah) I would still need to have an external DNS record for local.nextcloud blah blah pointing to my router in order for certbot to do it's thing...so we're back to a circle since how do I forward that....have to have certs on reverse proxy...
