Add multi-SAN support to LetsEncrypt - Azure

[peterbrooknz]

---

Background

The underlying ACME tooling used by this step template already supports certificates containing multiple Subject Alternative Names (SANs). However, the current template only exposes support for a single certificate name, with the existing exception that a wildcard certificate such as *.example.com may also include the corresponding root domain (example.com) as a SAN.

This limitation makes it difficult to request a single certificate covering multiple related domains and wildcard domains, despite the capability already being available.

For example, it is currently not possible to request a certificate containing:

*.api.example.com
api.example.com
*.internal.example.com

using a single step template invocation.

Results

This PR adds an optional parameter to expose ACME's existing multi-SAN functionality:

Property Value
Name LE_AzureDNS_AdditionalSANs
Label Additional SANs
Help Text Optional list of additional Subject Alternative Names to include in the certificate request. Enter one or more domain names (including wildcard domains if required) separated by commas, semicolons, or new lines.

Example values:

*.api.example.com
api.example.com
*.internal.example.com

When specified, the supplied domains are added to the certificate's SAN list alongside the primary certificate name.

Compatibility

This change is fully backwards compatible.

The new parameter is optional and ignored when not provided. Existing projects and deployments will continue to behave exactly as they do today, with no configuration changes required.

Benefits

Exposes functionality already supported by the underlying ACME tooling.
Allows a single certificate to cover multiple related domains and wildcard domains.
Reduces certificate management overhead where several hostnames are deployed together.
Introduces no behavioural changes for existing consumers of the step template.

After

New parameter:

Pre-requisites

• [ Y] Id should be a GUID that is not 00000000-0000-0000-0000-000000000000
  • NOTE If you are modifying an existing step template, please make sure that you do not modify the Id property (updating the Id will break the Library sync functionality in Octopus).
• [ Y] Version should be incremented, otherwise the integration with Octopus won't update the step template correctly
• [ Y] Parameter names should not start with $
• [ Y] Step template parameter names (the ones declared in the JSON, not the script body) should be prefixed with a namespace so that they are less likely to clash with other user-defined variables in Octopus (see this issue). For example, use an abbreviated name of the step template or the category of the step template).
• [ Y] LastModifiedBy field must be present, and (optionally) updated with the correct author
• [ Y] The best practices documented here have been applied
• [n/a] If a new Category has been created:
  • An image with the name {categoryname}.png must be present under the step-templates/logos folder
  • The switch in the humanize function in gulpfile.babel.js must have a case statement corresponding to it

Fixes # . If there is an open issue that this PR fixes add it here, otherwise just remove this line

[github-actions]

Review this PR in Hyponome for a side-by-side diff of the step-template JSON and any embedded scripts.