Update app name references to distinguish CTW org from CCM product.

Author: webprofusion-chrisc

docs/backgroundservice.md

@@ -13,15 +13,15 @@ By default the background service runs a local http API server on port 9696 for
 
 ## Custom configuration and Troubleshooting "..service not started" error
 
-The certify background service operates a local API for the app on port `9696` by default. If this port is in use by another application/service (or for some other reason it cannot create a binding to `127.0.0.2:9696` (localhost), or a security product is preventing **local** port access) then you will see the message 'Service not started'.
+The background service operates a local API for the app on port `9696` by default. If this port is in use by another application/service (or for some other reason it cannot create a binding to `127.0.0.2:9696` (localhost), or a security product is preventing **local** port access) then you will see the message 'Service not started'.
 
 - `servers.json` : This is the connection information used by the UI to connect to the background service.
 - `serviceconfig.json` : These are the service settings and includes the host/ip and port the service will listen on, so it needs to match the details in `servers.json`.
 
 :::info
 If you are repeatedly seeing the "Service Not Started" error, first try deleting `serviceconfig.json` and `servers.json` from C:\ProgramData\Certify\ then restart the background service and the app and these config files will be recreated. This can help if automatic port negotiation has gotten out of sync.
 
-In some cases antivirus software products (such as *ClamWin*, *Watchguard Advanced EPDR*, *ESET*) have been known to prevent the Certify servicing installing properly or prevent some core features working like our temporary http challenge service listener.
+In some cases antivirus software products (such as *ClamWin*, *Watchguard Advanced EPDR*, *ESET*) have been known to prevent the Certify service installing properly or can prevent some core features working like our temporary http challenge service listener.
 :::
 
 If the default port 9696 is already in use however you can manually specify the settings required by editing/adding the file `c:\programdata\certify\serviceconfig.json` (and servers.json) with content as per the following (adjusted as required) then restarting both the service and UI:
@@ -120,7 +120,7 @@ net start http
 
 If the service remains at `STOPPING` or similar then a system reboot may be required.
 
-Once completed, restart the Certify background service from local services, then open the Certify The Web UI again to see if it can connect.
+Once completed, restart the Certify background service from local services, then open the Certify Certificate Manager UI again to see if it can connect.
 
 ## Managed Items Database
 

docs/certificate-process.md

@@ -3,19 +3,19 @@ id: certificate-process
 title: Requesting a Certificate
 ---
 
-When you install Certify you will be prompted to register with the [Certificate Authority](guides/certificate-authorities.md) who will validate and issue your [certificates](guides/certificates.md) (e.g. Let's Encrypt). You should provide a real email address, otherwise they can't contact you if there is a problem with your certificate. 
+When you install Certify you will be prompted to register with the [Certificate Authority](guides/certificate-authorities.md) who will validate your domains and issue your [certificates](guides/certificates.md) (e.g. Let's Encrypt). You should provide a real email address, otherwise they can't contact you if there is a problem with your certificate.
 
 :::tip Quick Start
 If you are requesting a certificate for an IIS website with existing http/https domain hostname bindings it's possible to just install the app on the web server, click **New Certificate**, selected your IIS Website and confirm your domains, then click **Request Certificate** to automatically validate your domain(s), fetch the certificate and auto-apply it. You can then access your website via https. Your certificate will automatically renew using the same process.
 :::
 
 ## What is an ACME client?
-An ACME client is any software tool which can talk to an ACME (Automatic Certificate Management Environment) enabled Certificate Authority (such as Let's Encrypt). Certify The Web is the most fully featured ACME certificate management UI available on Windows. You can see other available ACME clients here: https://acmeclients.com/
+An ACME client is any software tool which can talk to an ACME (Automatic Certificate Management Environment) enabled Certificate Authority (such as Let's Encrypt). *Certify Certificate Manager* is the most fully featured ACME certificate management UI available on Windows. You can see other available ACME clients here: https://acmeclients.com/
 
 ## Requesting a Certificate
-The basic process of requesting a certificate for your domain involves either proving you control the server for that domain or proving you control DNS for that domain, then the Certificate Authority can issue you a certificate once it's satisfied that you have met the requirements. 
+The basic process of requesting a certificate for your domain involves either proving you control the server for that domain or proving you control DNS for that domain, then the Certificate Authority can issue you a certificate once it's satisfied that you have met the requirements.
 
-This process can be handled automatically by Certify The Web, either by running the app on the web server for your domain, or by talking to your DNS service provider's API. Once a certificate has been issued it can be deployed automatically in a number of ways, the most common being to apply it to your web server *https bindings*
+This process can be handled automatically, either by running the app on the web server for your domain, or by talking to your DNS service provider's API. Once a certificate has been issued it can be deployed automatically in a number of ways, the most common being to apply it to your web server *https bindings*
 
 ### 1. Choose the domains (identifiers) to include
 The first step of requesting a certificate is to decide which domain (and subdomains) need to be included in your certificate. You can manually specify these or you can load the configured hostname bindings from an existing IIS site on your server. 
@@ -47,11 +47,11 @@ You can validate using [HTTP validation (http-01)](http-validation.md) or [DNS V
 ### 3. Decide how to deploy
 By default Certify will auto update/add https bindings on all sites with hostname bindings which match the certificate (if using IIS). You can also choose to customise how deployment occurs. The *Preview* feature (below) is especially important as this will show you which bindings will be created and updated.
 
-You can customise this behaviour or even opt to have no deployment at all, however if you do customise binding behaviour (on a Windows Server) you should have a clear understanding of the limitations of [SSL binding on Windows](guides/ssl-windows.md)
+You can customise this behaviour or even opt to have no deployment at all, however if you do customise binding behaviour (on a Windows Server) you should have a clear understanding of the limitations of [SSL binding on Windows](guides/ssl-windows.md) and in particular you should avoid binding to specific IP addresses unless you are fully aware of the implications. Use SNI with hostname bindings and IP set to *All Unassigned* instead and this is the default setting the app will auto create from existing http bindings.
 
 ![Deployment](/assets/screens/Deployment_Auto.png)
 
-The default Auto deployment mode will (if applicable) match your certificate to all IIS http(s) sites with matching hostname bindings, to work with blank hostname bindings etc., change the deployment mode and configure the available options. 
+The default Auto deployment mode will (if applicable) match your certificate to all IIS http(s) sites with matching hostname bindings, to work with blank hostname bindings etc., change the deployment mode and configure the available options.
 
 Note that for FTP site bindings you need to select "Single Site" instead.
 
@@ -77,5 +77,5 @@ Finally, you can request your certificate which will automatically:
 
 By default, [automatic renewal](renewals.md) will take place 30 days after your most recent successful request (per managed certificate). The frequency of renewals (in Days) is set under Settings and once you are comfortable that renewals are happening automatically as expected you should raise to 60 days (for example) to reduce traffic against the certificate authority. The *Certify* background service performs renewal maintenance tasks every 60 minutes and also performs daily tasks such as certificate store maintenance.
 
-By default, if a certificate fails to renew (because of a configuration change or a problem with the certificate authority etc) then the renewal will be attempted again later. If the certificate renewal continues to fail then a status report will be sent to the Certify The Web API and you will then receive an email notification alerting you to the failure. The app uses the email address specified under Settings > Certificate Authorities > Accounts for this.
+By default, if a certificate fails to renew (because of a configuration change or a problem with the certificate authority etc) then the renewal will be attempted again later. If the certificate renewal continues to fail then a status report will be sent to the certifytheweb.com API and you will then receive an email notification alerting you to the failure. The app uses the email address specified under Settings > Certificate Authorities > Accounts for this.
 

docs/commandline.md

@@ -88,6 +88,6 @@ The user agent returned should be `Certify/HttpChallengeServer`
 
 ### Managing license activation
 
-- `certify activate <email> <key>` : activate the license for this instance of Certify The Web. Useful for larger scale automated deployments.
+- `certify activate <email> <key>` : activate the license for this instance of *Certify Certificate Manager*. Useful for larger scale automated deployments.
 
-- `certify deactivate <email>` : deactivates the license for this instance of Certify The Web.
+- `certify deactivate <email>` : deactivates the license for this instance of *Certify Certificate Manager*.

docs/deployment/tasks/apache.md

@@ -5,7 +5,7 @@ title: Deployment Task - Deploy to Apache
 
 The *Deploy to Apache* task will export your certificate and the components you choose as a set of PEM format files.
 
-To use a certificate with your web server, the service you are targeting needs to know the certificate for your domain (**Leaf or End-Entity Certificate**), intermediate certificates from your CA (if any) and the **Private Key** that corresponds to the public key in the certificate. Certify The Web can produce the files you need but currently it does not automatically configure Apache to use them.
+To use a certificate with your web server, the service you are targeting needs to know the certificate for your domain (**Leaf or End-Entity Certificate**), intermediate certificates from your CA (if any) and the **Private Key** that corresponds to the public key in the certificate. The app can produce the files you need but currently it does not automatically configure Apache to use them.
 
 ## Task Parameters
 ### Authentication
@@ -50,4 +50,4 @@ For older versions of Apache you may need to specify the **CA Chain** file separ
 For your changes to take effect you will need to restart Apache. You can do this by adding a *Stop, Start or Restart a Service" task after your *Deploy to Apache* task.
 
 ### CA Preferred Chain
-Some CAs offer alternative certificate chains for compatibility. Let's Encrypt offers both a *DST Root CA X3* chain (expired) and a newer *ISRG Root X1* chain. Certify The Web v6.x onwards defaults to the newer chain. If you need to use the older chain (e.g. for old Android compatibility) you can do so by setting the *Preferred Chain* option under *Certificate > Advanced > Certificate Authority - Preferred Chain* to *DST Root CA X3* and re-requesting your certificate.
+Some CAs offer alternative certificate chains for compatibility. Let's Encrypt offers both a *DST Root CA X3* chain (expired) and a newer *ISRG Root X1* chain. v6.x onwards of the app defaults to the newer chain for LE. If you need to use the older chain (e.g. for old Android compatibility) you can do so by setting the *Preferred Chain* option under *Certificate > Advanced > Certificate Authority - Preferred Chain* to *DST Root CA X3* and re-requesting your certificate.