Begin 7.0.19 docs updates

Author: webprofusion-chrisc

docs/hub/guides/certificate-subscriptions.md

@@ -9,7 +9,7 @@ description: Subscribe a managed instance to a certificate sourced from the Hub,
 
 A certificate subscription allows a managed instance to use a certificate sourced from the Hub instead of renewing that certificate locally.
 
-In the certificate editor this appears as **Use External Subscription**.
+In the managed certificate editor this appears as **Use Certificate Subscription**.
 
 ## Subscription Model
 
@@ -28,16 +28,6 @@ This is useful when one system should own renewal while another should only cons
 - a remote instance should receive an updated certificate but should not hold CA accounts or DNS credentials
 - renewal logic should stay centralized while deployment stays local to the consuming machine
 
-## Editor Fields
-
-When **Use External Subscription** is enabled, the main fields are:
-
-- **Source Type**
-- **Retrieval Mode**
-- **Managed Hub Certificate**
-
-The editor shows **Managed Hub** as the source type and **Auto** as the retrieval mode.
-
 ## Access Control
 
 The list of available source certificates depends on the managed instance permissions defined in the Hub.
@@ -56,11 +46,11 @@ Without that permission, the instance cannot fetch source certificates from the
 2. Apply tags to that certificate if tag-scoped access will be used.
 3. In the Hub, assign **Cert Consumer** to the managed instance and filter by tag where required.
 4. On the consuming instance, create or edit the certificate definition.
-5. Enable **Use External Subscription**.
-6. Select the source type and source certificate.
-7. Save and validate the resulting deployment behavior on the consuming instance.
+5. Enable **Use Certificate Subscription**.
+6. Select the source certificate.
+7. Save and validate the resulting deployment behavior on the consuming instance by selecting *Request Certificate*.
 
-The source system owns renewal. The consuming instance owns local use of the retrieved certificate, including deployment paths, tasks, and permissions.
+The source system owns renewal of the actual certificate. The consuming instance owns local use of the retrieved certificate, including deployment paths, tasks, and permissions.
 
 Currently you should not apply a PFX password on the source certificate as the consumer will not be able to decrypt that.
 

docs/hub/guides/managedchallenges.md

@@ -7,12 +7,6 @@ title: Managed Challenges
 
 A managed challenge allows the Hub to perform ACME challenge responses on behalf of other ACME clients. This is most useful for DNS-based challenges, where you do not want to distribute privileged DNS credentials to every client.
 
-:::warning[feature under development]
-
-This feature is under development and documentation may refer to features and procedures that are not yet available.
-:::
-
-
 ## Flow
 
 During a certificate request, the CA asks the ACME client to prepare a challenge response, usually an `_acme-challenge` TXT record. The client calls the Management Hub API with the required record details, and the Hub creates the DNS record on its behalf.
@@ -22,7 +16,8 @@ During a certificate request, the CA asks the ACME client to prepare a challenge
 Managed challenges need two things:
 
 - a managed challenge definition, including DNS provider, credentials, and domain match rule
-- an API token scoped for managed challenge use
+- when using Certify Certificate Manager, join the instance to the hub and assign *Managed Challenge Consumer* role to that instance under Security. 
+- You can optionally scope instance role access by tag (e.g. *Production* etc) and also tag the managed challenge with the same tag.
 
 ## Managed Challenge Definition
 
@@ -31,8 +26,27 @@ Under *Services > Managed Challenges*, select `+ Add`:
 - Select the DNS provider specific to your domains DNS service. 
 - Add or select existing stored credentials for updating DNS via the selected API.
 - Populate the *Domain Match Rule* to specify the domains this configuration can update DNS for, then Save.
+- Optionally tag the Managed Challenge so consumer access can be scoped by tag.
+
+
+## Client Configuration
+
+Where an ACME client supports Certify Managed Challenges, configure that provider in the normal way, then supply the Client ID, Secret, and Hub API URL. The client uses the Hub API to perform the DNS updates.
+
+### Certify Certificate Manager
+
+In *Certify Certificate Manager*, under Authorization, select dns-01 as the Challenge Type, and *Certify Managed Challenge API* as the provider. 
+
+If the instance is joined to the hub you can leave the hub API url blank. If the instance has been assigned the Managed Challenge Consumer role in the hub then you do not need additional API credentials.
+
+### Hub Certificates
+
+For certificates configured directly on the Hub, use a local managed challenge under Authorization > dns-01 > **Use Managed Challenge**. This avoids repeating DNS authorization configuration where many certificates use the same zone.
 
-## API Access
+## Managed Challenge API (Advanced)
+If using a client that's not joined to the hub it's still possible to use the API to complete a managed challenge if the client supports that feature.
+
+### API Access
 
 Before a managed challenge can be used, assign an API token to a specific service principal.
 
@@ -50,7 +64,7 @@ Under *Settings > Security > API Access*, add an API token for that principal an
 5. Select the `Managed Challenge Consumer` role from Available Roles to assign it.
 6. Click **Save**
 
-## API Token
+### API Token
 
 1. Navigate to **Settings > Security > API Access**
 2. Click **Add API Token**
@@ -59,22 +73,4 @@ Under *Settings > Security > API Access*, add an API token for that principal an
 5. Select **Managed Challenge Consumer** as the scoped role
     - **Important:** Click **Add/Remove Role Scope** to add it to the scope list
 7. Click **Add** to create the new API token
-8. Copy the **Client ID** and **Secret** values.
-
-### Combined Join and Challenge Token
-
-It is possible to create one token that supports both Hub joining and managed challenges. Some clients, such as *Certify Certificate Manager*, can use this for convenience if they already know the join key.
-
-To do this, add **Managed Challenge Consumer** to the managed instance service principal, then create a join token scoped to both **Hub Managed Instance** and **Managed Challenge Consumer**.
-
-## Client Configuration
-
-Where an ACME client supports Certify Managed Challenges, configure that provider in the normal way, then supply the Client ID, Secret, and Hub API URL. The client uses the Hub API to perform the DNS updates.
-
-### Certify Certificate Manager
-
-In *Certify Certificate Manager*, under Authorization, select dns-01 as the Challenge Type, and *Certify Managed Challenge API* as the provider, then add/select the required managed challenge consumer credentials. If the instance is joined to the hub you can leave the hub API url blank.
-
-### Hub Certificates
-
-For certificates configured directly on the Hub, use a local managed challenge under Authorization > dns-01 > **Use Managed Challenge**. This avoids repeating DNS authorization configuration where many certificates use the same zone.
+8. Copy the **Client ID** and **Secret** values.

docs/hub/installation/index.md

@@ -30,7 +30,7 @@ The product runs in Community Edition mode by default. *Certify Management Hub*
 **The default admin login is `admin:changeme!` and you should change the password immediately before configuring any other parts of the system.** 
 
 :::danger
-Due to the nature of the work the management hub performs we do not recommend hosting on a public facing web server. While logins are required for most actions, the app and API are not considered to be security hardened for public exposure unless we explicitly state that they are. Default admin credentials should be changed immediately after setup.
+Due to the nature of the work the management hub performs we do not recommend hosting on a public facing web server with open access. If you must host on the public internet you must restrict access using methods such via firewall IP ranges or VPN access. Default admin credentials should be changed immediately after setup.
 :::
 
 ## Upgrading

docs/hub/installation/linux.md

@@ -7,6 +7,8 @@ title: Install for Linux
 
 If you just want to try out the Management Hub, an easy way to do that is to use [docker or other container tool](containers.md). However if you want to install the Management Hub (or Management Agent) directly you can do that as well.
 
+Note: If you plan to use Windows-centric tasks directly on the hub you should use a Windows host for your hub instead. Various functionality such as Windows networking, windows user impersonation, system powershell/modules etc are not available on Linux.
+
 #### Scripted Install
 The following commands:
 - Download the latest version, ensuring any old download and old install files are removed if present

docs/hub/installation/windows.md

@@ -9,9 +9,7 @@ Use this guide when you want to deploy *Certify Management Hub* as a Windows ser
 ## Install Certify Management Hub
 The management hub is installed as a single service which serves the Management Hub API, a backend certify-agent instance, and the web UI. Internally this is using the Kestrel web server which is part of Microsoft ASP.Net.
 
-[Download the latest Windows preview build](https://downloads.certifytheweb.com/beta/latest/certify-mgmthub-windows-x64-latest.exe)
-
-The Windows installer is distributed through the preview channel. It is suitable for staged evaluation and careful production testing, but you should expect updates while the release candidate phase continues.
+[Download the latest Windows version](https://downloads.certifytheweb.com/beta/latest/certify-mgmthub-windows-x64-latest.exe)
 
 ### Upgrading
 To upgrade download and install the latest version as normal. On Windows your settings are preserved in `%PROGRAMDATA%\certify`. For most users, this is `C:\ProgramData\certify`. Uninstalling the app or installing a new version does not remove the files stored here. We recommend including this location in your regular backup procedure.
@@ -22,7 +20,7 @@ The default configuration will make the service and UI available at `http://loca
 
 To use the service with https you can either [configure the service to use https](service.md) or reverse proxy the service from a webserver of your choice (Caddy, IIS, nginx, Apache etc and administer https on those as normal).
 
-Do not install the Hub service where you also want to use Certify Certificate Manager as they will share the same settings/databases via different services which could create confusion or conflicts and is not a supported configuration. You can however upgrade a Certify Certificate Manager install to be a hub: uninstall Certify Certificate Manager (the desktop app) first, install Certify Management Hub, then use the hub to administer your certificates as normal.
+Do not install the Hub service where you also want to use *Certify Certificate Manager* as they will share the same settings/databases via different services which could create confusion or conflicts and is not a supported configuration. You can however upgrade a Certify Certificate Manager install to be a hub: uninstall Certify Certificate Manager (the desktop app) first, install Certify Management Hub, then use the hub to administer your certificates as normal.
 
 Suggested Configuration for multi-user access:
 - Create an internal DNS hostname for the service e.g. certify-hub.yourowndomain.com and point it at the internal IP of your server hosting the hub.