DietPi-Software | CertBot: Also Minio challenge needs to be patched, as we actively preferred 'tls-sni' here.

[MichaIng]

• Is fixed for new certificates, but forgot to add to patch_file: Fourdee@a6867fd

[Fourdee]

👍

[Fourdee]

@MichaIng

Legend, many thanks 👍

[MichaIng]

@Fourdee
Some questions about Minio CertBot implementation:

• Had the great idea while waiting to fall asleep last night to just create symlinks from minio cert folder to the actual certificates. But yeah found hint today, that this does not work, I guess mainly because they need to be owned by minio user.

• For me this is extremely bad practice, security wise (and unnecessary, as every user has read access to certs...) and also for practical reasons, as auto renewal get's a pain. However should work the way it is now on Jessie as well as Stretch, even that certificates get copied every time, CertBot checks for renewal (instead of just, if an actual renewal happened).

• Found the reason for current implementation: https://docs.minio.io/docs/generate-let-s-encypt-certificate-using-concert-for-minio

• I am wondering why --staple-ocsp is included, as it is, as far as I know, just a webserver configuration option (which doesn't make sense for standalone module, just if apache/nginx installer module is used), where --must-staple would be e.g. something, really included in the certificate: https://certbot.eff.org/docs/using.html
  But it wouldn't hurt as well, just be without effect...

• I just wanted to do Minio check as a separate one, independently from other webservers (just create certs, if not yet done due to other webservers), as they can run nicely beside each other, as long as Minio uses default port 9000. But yeah, the way it is intended by their documentation and implemented within dietpi-letsencrypt, the port is switched to 443 then, which would of course break other webservers. I am wondering why this should be necessary. Does Minio somehow by design just use SSL, if opened via port 443? Doesn't make too much sense to me, I guess would work also with e.g. 9443 or just stay with 9000, at least shouldn't the port be connected generally with use of SSL/non-SSL.

• Ah seems really just for easier access: Step 7: Visit https://myminio.com in the browser. Wonder why then not use port 80 for default 1st run (instead of 9000) and clearly mention that it is by default not compatible with other webservers... inconsistent to me.

• Yeah you see, I am really unhappy in how this is handled and intended by Minio documentation 😆. I can't really test this on my VMs, however I can do via self-signed certificates and see, if it is somehow possible to let Minio use them in a different way.

• https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-letsencrypt#L251-L259
  Why not just sed -i '/MINIO_OPTS="--address/c\MINIO_OPTS="--address :443"' /etc/default/minio? 😛

[MichaIng]

@Fourdee
🈯️ Tested with self-signed certificate and symlinks via default port 9000:

• Within /root: openssl req -new -x509 -sha256 -newkey rsa:4096 -nodes -keyout private.key -days 365 -out public.crt
• ln -sf /root/public.crt /home/minio-user/.minio/certs/public.crt
• ln -sf /root/private.key /home/minio-user/.minio/certs/private.key

root@DietPi:~# ll
total 8
-rw-r--r-- 1 root root 3272 Feb 17 15:22 private.key
-rw-r--r-- 1 root root 1923 Feb 17 15:22 public.crt
root@DietPi:~# ll /home/minio-user/.minio/certs/
total 4
drwx------ 2 minio-user minio-user 4096 Feb 17 13:37 CAs
lrwxrwxrwx 1 root       root         17 Feb 17 15:24 private.key -> /root/private.key
lrwxrwxrwx 1 root       root         16 Feb 17 15:24 public.crt -> /root/public.crt

• So also port does not need to be changed. I would prefer to either use port 80 by default and 443 on SSL, but then do check for other webservers on installation on block in case/mark as incompatible. Or leave it just on default port 9000, weather SSL is used or not... Users just need to take care to add port (as already for non-SSL access) and https:// to their URL.
• As said, letsencrypt generated keys/certs have 644 by default, at least on my RPi this is the case.

[Fourdee]

@MichaIng

Why not just sed -i '/MINIO_OPTS="--address/c\MINIO_OPTS="--address :443"' /etc/default/minio?

Yep, if entry exists initially in the file (cant remember), make the change 👍

For the rest of the questions:
Unfortunately, I have zero experience/understanding of Minio and its configuration. I didn't add this software title in: https://github.com/Fourdee/DietPi/issues/1160#issue-260691948

So apologies, i'am probably the wrong person to ask lol 😄

[MichaIng]

@Fourdee
No worries, I had the time today for further investigation:

• Minio (user) does NOT have access to private key, as even, if the file itself has 644 permissions, the parental folder does not have. Also on my test within /root/ I just forgot to restart service to finally find myself connected to Minio via non-HTTPS again 😉.
• The CertBot devs had already a discussion about that topic, and if symlinking is preferred over copy & chown key+cert for use with non-root daemons. Finally they agreed for several reasons, that the intended method should be copying instead of symlinking: archive/domain/privkeyN.pem is set to 0644 instead of 0600 (or 0440) certbot/certbot#1473 (comment)
• There is actually a certbot option --deploy-hook for certbot to implement a script (copy&chown cert) only on actual certificate generation/renewal, but yeah there was a name change: On Stretch version (0.10.2), it is still called --renew-hook. So would need check to use correctly and then we don't know if this might change, user might upgrade their distribution/install certbot from source (as of tls-sni issue e.g.)... So we better stay with out existing script. Should be not too big issue, to copy 2 tiny files two times a day (Stretch certbot renewal service).
• At least certbot offers a more secure copy/chmod method within their docs (see within --deploy-hook chapter: https://certbot.eff.org/docs/using.html):

                umask 077
...
                cp "$RENEWED_LINEAGE/fullchain.pem" "$daemon_cert_root/$domain.cert"
                cp "$RENEWED_LINEAGE/privkey.pem" "$daemon_cert_root/$domain.key"
...
                chown some-daemon "$daemon_cert_root/$domain.cert" \
                        "$daemon_cert_root/$domain.key"
                chmod 400 "$daemon_cert_root/$domain.cert" \
                        "$daemon_cert_root/$domain.key"

To guarantee global access to private key at no time! I will implement this into our existing script. Minio works fine with this.