Scripted installation of Nextcloud 28 in iocage jail 2018-03-23

[danb35]

I've updated the scripts in the GitHub repo to remove the common_log line--this is a change with Caddy 2.5.0, which was just released.

 

[mapcevn]

Hi danb35,
I used your early script to install my nextcloud for quite a long time ago. It works well. Thank you again for creating an amazing script.

However, I'm getting a bit concerned about the man-in-middle attack risk within my LAN since my nextcloud is listening to the unencrypted port 80 behind pfsense/haproxy with a Let's Encrypt SSL cert.
To do this, I guess I need to enable SSL connection to the haproxy and set the nextcloud to listen to port 443.

How do I enable port 443 and SSL in the existing nextcloud jail?

My caddy file is look like the below:

cloud.mydomain.com:80, 172.16.100.100:80 {
root * /usr/local/www/nextcloud
file_server
log {
output file /var/log/cloud.mydomain.com.log
format single_field common_log
}

php_fastcgi 127.0.0.1:9000 {
env front_controller_active true
}

redir /.well-known/carddav /remote.php/dav 301
redir /.well-known/caldav /remote.php/dav 301

# .htaccess / data / config / ... shouldn't be accessible from outside
@forbidden {
path /.htaccess
path /data/*
path /config/*
path /db_structure
path /.xml
path /README
path /3rdparty/*
path /lib/*
path /templates/*
path /occ
path /console.php
}

respond @forbidden 404
}


Thanks

 

[danb35]

I'm getting a bit concerned about the man-in-middle attack risk within my LAN

That's a pretty serious threat you're concerned with--for a MITM to be viable, the attacker would need to either spoof your local DNS, or outright take over the IP belonging to your Nextcloud jail, depending on exactly how you've configured HAProxy (i.e., whether you're proxying to a hostname or the IP address). The more viable threat is that some malicious device/code on your LAN would be sniffing the unencrypted HTTP traffic.

You've got a few possibilities to mitigate either of these:

• Set up your Nextcloud jail to get a cert from Let's Encrypt
  • For this to work behind a reverse proxy, you're going to need to use DNS validation, which means you need to be using a DNS host with an API that Caddy supports
• Set up your Nextcloud jail to use Caddy's internal CA to issue a cert
• Create a self-signed cert for your Nextcloud jail, and configure Caddy to use that.

For both the second and third options, you'd need to configure HAProxy to either trust the cert for the jail, or to ignore certificate errors. The former may be difficult (I've never done it, so I can't say); the latter leaves you just as vulnerable to a MITM (though much less vulnerable to someone sniffing the connection) as before.

All of these will require edits to the Caddyfile, and the first will also require that you rebuild Caddy with support for the appropriate DNS plugin. For the necessary changes to the Caddyfile for the first and third, check out the relevant Caddyfile templates in the repo. For the second bullet, start with the template for a self-signed cert, but change the relevant line to tls internal.

To rebuild Caddy with support for your DNS host, you can find instructions here: https://github.com/danb35/freenas-iocage-heimdall

 

[mapcevn]

Perfect! It works now.
What I did is that I chose the third option as you recommended. I copied the LE cert and key from the pfsense/ACME to the TLS folders as per the caddy template file. The copying is manually with the use of scp command via secured ssh. I have to do it again every time the LE cert is renew. Not sure if there is anything still vulnerable, but I think it is much better than exposed everything unencrypted before.

You are a legend, danb35! I can't imagine that a lawyer could make such an amazing script like an IT professional.

Thank you so much.

 

[danb35]

The copying is manually with the use of scp command via secured ssh. I have to do it again every time the LE cert is renew.

You should be able to script this from the pfSense box; it supports running specific commands after cert renewal. And you can use ssh to run arbitrary commands on a remote host--the syntax would be something like ssh root@freenas iocage exec nextcloud service caddy reload.

 

[mapcevn]

You should be able to script this from the pfSense box; it supports running specific commands after cert renewal. And you can use ssh to run arbitrary commands on a remote host--the syntax would be something like ssh root@freenas iocage exec nextcloud service caddy reload.

I'll look at that approach. It might be a bit learning curve for me. Looks like I need to make another ssh key for this purpose as my current ssh key is a PGP-based one imported into a yubikey which requries PIN every time I ssh to a server. Thank you for this excellent suggestion!

 

[danb35]

current ssh key is a PGP-based one imported into a yubikey

Fancy. I use a Yubikey as a poor man's HSM for my local certificate authority:

Build a Tiny Certificate Authority For Your Homelab

Let's make a tiny, standalone CA! We'll use a Raspberry Pi 4, YubiKey 5 NFC, and Infinite Noise TRNG.

smallstep.com

...and use that CA to issue SSH user certs, authenticating via LemonLDAP::NG which I'm running locally. But for something like this, a plain keypair would be the way to go.

 

[mapcevn]

Wow, I'm so impressed with what you can do.
I'm building a small scale CA for my own family too which starts with pure OpenSSL commands atm. I have never thought that a normal yubikey can do the work of the expensive HSM. I'll look at that guide too.
I have a dream that governments all over the world will one day issue free or low-cost digital certificates (all functions enabled including email, documents/code signing etc) to their citizens. I believe that it would make people life a lot easier and it would contribute to make the world a better place to live. Commercial CAs like Digicert, GlobalSign etc. may hate me if my dream come true.

 

[danb35]

I'm building a small scale CA for my own family too which starts with pure OpenSSL commands atm.

I'd strongly recommend looking at Smallstep's offering, then. Whether you run it on PC or Pi, use the Yubikey or not, use the TRNG or not, it's a nicely-integrated solution that can handle both TLS and SSH certs. @rvassar posted a link to that blog post about a year ago, and I thought it sounded like a fun project. I've pretty much been banging rocks together, because most of what I've done has been documented elsewhere, just not how to put it all together--but thankfully SmallStep have some pretty good support, even for freeloaders like me.

I have never thought that a normal yubikey can do the work of the expensive HSM.

I doubt it has the security level, and it certainly doesn't have the certifications, but it does have the capability of storing the signing keys and doing the signing on the device itself, while "never" (unless it's compromised, the difficulty of which I don't know) exposing the keys themselves to anything else.

I have a dream that governments all over the world will one day issue free or low-cost digital certificates

I thought I'd heard that some European governments do this. Here in .us, there's considerable resistance to the concept of a national ID, so...

 

[mapcevn]

I'm wondering whether Smallstep supports OCSP? I've heard about other open source CA such as EJBCA which allows a PKI either at small scale (home) or at very large scale (organizations, countries).
Have you (or anyone here) tried EJBCA yet?
Nevertheless, I'll look at the Smallstep when I have time as it's name makes sense to me making a 'small step' first before trying to solve the problem of the world

I've learnt to know that Estonia is the pioneer to adopt a PKI at the nation scale. Admire them!

 

[danb35]

I'm wondering whether Smallstep supports OCSP?

No, their way of dealing with questions of cert validity is to use very short-lived certs--by default, a cert is only valid for 24 hours, which is much shorter than a typical OCSP response. Put differently, the existence of the cert itself is going to give a more up-to-date indication of its validity than a OCSP response. And really, not only do they not support OCSP, they don't support revocation at all (which makes the OCSP question moot).

 

[danb35]

Here's what the script does to that path:

Code:

chown -R 80:80 "${FILES_PATH}"

 

[victort]

When updating caddy to latest version, is the command

Code:

pkg update caddy

the correct one or does the version need to be included?

 

[victort]

When updating caddy to latest version, is the command

Code:

pkg update caddy

the correct one or does the version need to be included?

As of right now I am using the

Code:

caddy upgrade

command which is listed as experimental.

 

[danb35]

I'd recommend using caddy upgrade--my script doesn't install Caddy from the package.

 

[victort]

I'd recommend using caddy upgrade--my script doesn't install Caddy from the package.

It updates to 2.5.1 and now nextcloud stopped working.

How do I revert?

 

[danb35]

What's in /var/log/caddy/caddy.log?

 

[victort]

What's in /var/log/caddy/caddy.log?

{"level":"info","ts":1652401079.7092593,"msg":"using provided configuration","co
run: adapting config using caddyfile: parsing caddyfile tokens for 'log': /usr/l
start: caddy process exited with error: exit status 1
{"level":"info","ts":1652401157.7792335,"msg":"using

also
error during parsing module not registered.

 

[danb35]

The complete lines would have been nice. But it looks like the same problem as noted just up-thread--delete the line from your Caddyfile that calls for common_log format (around line 10) and restart Caddy, and you'll likely be fine.

 

[victort]

The complete lines would have been nice. But it looks like the same problem as noted just up-thread--delete the line from your Caddyfile that calls for common_log format (around line 10) and restart Caddy, and you'll likely be fine.

Just saw that. Yes i suspected as much.

That worked for me, thanks.