Update TLS Sections of guides.md

[techjeffharris]

1. Added section for certificate requirements that links to Citrix TLS Certificate documentation
2. Added warning that as of this writing Citrix TLS Certificate document does not mention the SubjectAlternateName extension that is effectively required in modern environments
3. Added information regarding the SubjectAlternateName extension
4. Modified example for generating a CSR A. Added definition of a SubjectAlternateName extension b. Broke command into multiple lines using \ to improve readability
5. Added section detailing certificate requirements for hosts within resource pools
6. Added additional example for generating a CSR for a resource pool a. Added table outlining name-label, IP, and FQDN of 3 hosts in an example pool b. Included definitions of SubjectAlternateName extension for each IP/FQDN in example c. Broke command into multiple lines using \ to improve readability
7. Modified the instructions for installing the certificate to xcp-ng 8.2+ hosts a. Added (s) to Certificate to make it clear that a person may generate one or multiple certificates b. Added host= parameter which is required for resource pools (possibly for single-hosts as well?) c. Broke the command into multiple lines using \ because it was getting too long for a single line.

Signed-off-by: Jeff Harris [email protected]

Before submitting the pull request, you must agree with the following statements by checking both boxes with a 'x'.

• [x] "I accept that my contribution is placed under the CC BY-SA 2.0 license [1]."
• [x] "My contribution complies with the Developer Certificate of Origin [2]."

[1] https://creativecommons.org/licenses/by-sa/2.0/ [2] https://xcp-ng.org/docs/contributing.html#developer-certificate-of-origin-dco

[techjeffharris]

Hi @stormi. Sorry for disappearing! Other life priorities have taken precedent over following up on and test feedback from @psafont. I just noticed the other day that my host certificates have expired, and since I have a bit more time on my hands these days, it's time to start working on this again.

I have been working on a tool that I'm calling step-renewer that uses a systemd unit and timer along with a config file and a few bash scripts to automate the use of step cli to use the ACME protocol to get certificates from a step-ca server then run a user-defined post-update script to say, move the cert and key and/or restart nginx, etc. The main goals are to eliminate human error and increase repeatability which is helpful for for testing scenarios like this, but it's also very helpful for fully automatic, regular certificate renewal at a specific time with expiration at a specific time etc. Anyhoo.. enough tooting my own horn.

In retrospect, I believe that around this time last year step-renewer did not have the means for manually specifying SANs to request and validate, but it is capable of that now. Given that a year has passed and perhaps things have changed, I intend to test using step-cli on each host to request its own certificate with only it's own SANs and IPs. If that results in /rrd-updates tasks stalling, then instead I'll create a CSR on each host each containing all SANs and IPs for all hosts, then sign those CSRs, then install the certificates on each host.

My hope is that I made a mistake in the past when creating each host cert with only its own SANs and IPs which resulted in seeing the continuous /rrd-updates issue as that method seems like the most principled solution (each host only attests its own valid identities) and it is more feasible to automate using the ACME http-challenge for automated certificate renewal.

Also, it appears that this document has changed and I'll need to rebase my branch against upstream before moving forward as well.

[stormi]

Thanks @techjeffharris! Looking forward to your updated contribution!