webprofusion · webprofusion-chrisc · Apr 29, 2026 · Apr 29, 2026
diff --git a/README.md b/README.md
@@ -17,7 +17,7 @@ $ npm install
 $ npm start
 ```
 
-This command starts a local development server and open up a browser window. Most changes are reflected live without having to restart the server.
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
 
 ### Build
 

diff --git a/blog/2024-12-08-acme-clients.md b/blog/2024-12-08-acme-clients.md
@@ -99,7 +99,7 @@ Certify The Web is a comprehensive ACME client designed for Windows. It provides
 
 #### Cons
 - Currently limited to Windows environments, but a new web based Certify Management Hub app will be available soon.
-- Command line options are more limited that other command line native apps
+- Command line options are more limited than other command line native apps
 
 ## Conclusion
 

diff --git a/blog/2025-01-17-acme-profiles.md b/blog/2025-01-17-acme-profiles.md
@@ -8,11 +8,11 @@ image: https://certifytheweb.com/images/management/summary.png
 hide_table_of_contents: false
 ---
 
-We have implement support for the ACME Profiles extension, a new feature designed to enhance the Automated Certificate Management Environment (ACME) protocol. This extension allows ACME Servers to offer a selection of different certificate profiles to ACME Clients, making it easier for clients to request the specific type of certificate they need.
+We have implemented support for the ACME Profiles extension, a new feature designed to enhance the Automated Certificate Management Environment (ACME) protocol. This extension allows ACME Servers to offer a selection of different certificate profiles to ACME Clients, making it easier for clients to request the specific type of certificate they need.
 
 <!-- truncate -->
 
-ACME Profiles are a new proposed extension to the ACME standard allows CAs to offer certificates with different features depending on user preferences.
+ACME Profiles are a new proposed extension to the ACME standard that allows CAs to offer certificates with different features depending on user preferences.
 
 https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/
 
@@ -38,7 +38,7 @@ ACME Servers that support profiles will include a new `profiles` field in their
 ### Client Requests
 When creating a new Order, clients can specify the desired profile in the `profile` field of the Order object. The server will then issue a certificate that matches the selected profile.
 
-In **Certify Certificate Manager** and **Certify Management Hub** this will be available as an option under under *Certificate > Advanced > Certificate Authority*.
+In **Certify Certificate Manager** and **Certify Management Hub** this will be available as an option under *Certificate > Advanced > Certificate Authority*.
 
 ## Current Implementations
 Let's Encrypt's Boulder ACME Server software fully implements the ACME Profiles extension. Although profiles are not yet configured in Let's Encrypt's Production and Staging environments, the Pebble ACME Server testbed also supports this extension.

diff --git a/docs/backgroundservice.md b/docs/backgroundservice.md
@@ -5,7 +5,7 @@ title: Background Service
 
 In order to perform certificate requests and automatic renewals we install a background service called "Certify.Service" or "Certify.Server.Core" (the full title is either `Certify Certificate Manager Service` or `Certify Management Agent` for v7 onwards). 
 
-This service is installed to run as Local System and requires that the Local System account has the necessary privileges to administer IIS (if required) and the computers certificate store, as well as writing to the C:\ProgramData\Certify folder for configuration information. For more information on security and required permissions see [security](guides/security.md)
+This service is installed to run as Local System and requires that the Local System account has the necessary privileges to administer IIS (if required) and the computers certificate store, as well as writing to the C:\ProgramData\Certify folder for configuration information. For more information on security and required permissions see [security](guides/security.md).
 
 To check the log for this service, review `C:\ProgramData\Certify\logs\service.exceptions.log`.
 
@@ -57,7 +57,7 @@ Invoke-RestMethod -Uri http://localhost:9696/api/system/appversion -UseDefaultCr
 
 ### Other Considerations for 'Service Not Started..'
 
-To operate properly the background service needs to be able to register an http listener for it's API server via http.sys, for that to work the IP address the service tries to use must be enabled as an http listen address and in some versions of windows the Http kernel service may not be enabled and you will need to enable it.
+To operate properly the background service needs to be able to register an http listener for its API server via http.sys, for that to work the IP address the service tries to use must be enabled as an http listen address and in some versions of windows the Http kernel service may not be enabled and you will need to enable it.
 
 
 #### Enable http listener IP address
@@ -121,7 +121,7 @@ SERVICE_NAME: http
 
 ```
 
-If the state is not `RUNNING` use the following command the enable the service on demand:
+If the state is not `RUNNING` use the following command to enable the service on demand:
 
 ```bat
 sc config http start= demand
@@ -139,7 +139,7 @@ Once completed, restart the Certify background service from local services, then
 
 ## Managed Items Database
 
-The data store for the managed certificates database is the C:\ProgramData\Certify\manageditems.db SQLite database. This stores your renewal configuration data (not certificates). This is an sqlite3 format database files.
+The data store for the managed certificates database is the C:\ProgramData\Certify\manageditems.db SQLite database. This stores your renewal configuration data (not certificates). This is an sqlite3 format database file.
 
 You should include C:\ProgramData\Certify\ in your normal backup procedures, otherwise if you lose this configuration or it is corrupted you may need to add all of your managed certificates again. **To guard against database corruption you should add an exclusion to your anti-virus software to avoid sharing conflicts.**
 

diff --git a/docs/certificate-process.md b/docs/certificate-process.md
@@ -9,7 +9,7 @@ Use this guide when you are creating a new managed certificate and want to under
 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.
+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**, select 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?
@@ -63,7 +63,7 @@ Note that for FTP site bindings you need to select "Single Site" instead.
 ##### Deployment Tasks and Advanced Usage
 In addition to the Auto Deployment options, you can also make use of a variety of pre-built [Deployment Tasks](deployment/tasks_intro.md) for local or remote deployment. You can also use scripting tasks to work with your certificate using your own custom scripting.
 
-Deployment Tasks can be used used for common certificate tasks such as deploying to Microsoft Exchange, updating a certificate in a secrets vault (such as Azure Key Vault), deploying to a [CCS share](deployment/tasks/ccs.md) or converting the certificate into different file types.
+Deployment Tasks can be used for common certificate tasks such as deploying to Microsoft Exchange, updating a certificate in a secrets vault (such as Azure Key Vault), deploying to a [CCS share](deployment/tasks/ccs.md) or converting the certificate into different file types.
 
 ### 4. Preview
 Using the *Preview* tab you can see a detailed summary of how your Managed Certificate is configured and what actions the app will plan to take next, including how the new certificate will be deployed.

diff --git a/docs/commandline.md b/docs/commandline.md
@@ -3,7 +3,7 @@ id: commandline
 title: Command Line (CLI)
 ---
 
-A set of command line are available using the tool _certify.exe_ which is found in the installation directory. The commands must be performed using an elevated administrators account.
+A set of command line tools are available using the tool _certify.exe_ which is found in the installation directory. The commands must be performed using an elevated administrators account.
 
 :::tip
 Most users do not need to use the command line options at all. By default all certificate renewals are taken care of automatically by the Certify background service.
@@ -47,7 +47,7 @@ You can use the `acmeaccount add` command to add/create a new ACME account regis
 
 - `certify deploy "<managed cert id>" "<task id>"` : perform a specific deployment task for the given managed certificate. See the Manual trigger mode for deployment tasks.
 
-### Adding or Remove Managed Certificates
+### Adding or Removing Managed Certificates
 
 - `certify importcsv` : import managed certificates from a CSV file. See [CSV Import](csv-import.md) for more details
 

diff --git a/docs/deployment/tasks/apache.md b/docs/deployment/tasks/apache.md
@@ -47,7 +47,7 @@ For older versions of Apache you may need to specify the **CA Chain** file separ
 - Point *SSLCertificateFile* at your **Leaf Certificate** file.
 
 ### Restarting Apache
-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.
+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. 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.
diff --git a/docs/deployment/tasks/exchange.md b/docs/deployment/tasks/exchange.md
@@ -39,7 +39,7 @@ In the app, running on the same server where Exchange is installed:
 
 Other topics to consider include selecting between different Certificate Authorities, Private Key types and PFX password protection. These options are all configured under *Advanced*.
 
-## Deploying Your Certificate to Exchanges Services
+## Deploying Your Certificate to Exchange Services
 Once you have your certificate you can automate deploying it to your Exchange services. 
 
 :::info
@@ -61,13 +61,13 @@ For complex or customised deployments you may wish to use a [custom deployment s
 It's possible to continue to apply the certificate manually using the standard Exchange Admin Center features, however this is not recommended because certificates typically renew frequently (e.g. within 90 days) and you would need to remember to repeat the process each time. You should instead use automation to ensure your certificates are always up to date.
 
 ## Renewal Failures
-Certificate can fail to renew for a number of reasons, including:
+Certificates can fail to renew for a number of reasons, including:
 - Changes to your infrastructure (e.g. firewall changes, DNS changes)
 - Temporary issues with your CA
 
 **The app will recover from temporary issues automatically**, however if you have made changes to your infrastructure you may need to update your managed certificate settings to reflect the new configuration. You can force a certificate renewal attempt by selecting *Request Certificate*.
 
-By default, **if your certificate renewal fails repeatedly, you will receive an email notification**. This email is trigger by the default status reporting to our API, which in turn sends an email via SendGrid if multiple failures have been detected. The email address used is the one you specified when you first setup your CA account in the application (under Settings > Certificate Authorities). You can also check the *Certify Certificate Manager* app or the https://certifytheweb.com dashboard (if enabled) for the status of your managed certificates.
+By default, **if your certificate renewal fails repeatedly, you will receive an email notification**. This email is triggered by the default status reporting to our API, which in turn sends an email via SendGrid if multiple failures have been detected. The email address used is the one you specified when you first setup your CA account in the application (under Settings > Certificate Authorities). You can also check the *Certify Certificate Manager* app or the https://certifytheweb.com dashboard (if enabled) for the status of your managed certificates.
 
 If you don't understand why a renewal has suddenly failed it's best not to start changing settings if you are unsure, instead please [contact us for support](../../support.md) if you are a licensed user, or post a question on our [community forum](https://community.certifytheweb.com), ideally including your managed certificate log file, at the least we need your real domain name(s) in order to diagnose common renewal failures. 
 
@@ -77,13 +77,13 @@ Typical troubleshoot steps include checking your firewall (if using http validat
 Things to consider when administering certificates for exchange and IIS:
 
 ### Things to avoid
-- Never delete a certificate from the certificate store while it is still in use by a service, this will break the service and you will need to re-assign a new certificate to the service. *Certify Certificate Manager* will maintain it's own certificates in the store and by default will remove them when they are definitely no longer required.
+- Never delete a certificate from the certificate store while it is still in use by a service, this will break the service and you will need to re-assign a new certificate to the service. *Certify Certificate Manager* will maintain its own certificates in the store and by default will remove them when they are definitely no longer required.
 - Never revoke a certificate unless the private key has been compromised. Revoking a certificate will break any services using that certificate and is almost never required.
 
 ### Only use valid fully qualified domain names (or valid wildcard names)
 Certificates need to be issued for valid fully qualified names or wildcards. A certificate can cover multiple hostnames or subdomains and can also be wildcards that cover all subdomains of a domain e.g. `*.contoso.com` would cover `mail.contoso.com` and `autodiscover.contoso.com` but not `mail.contoso.com.au` or `mail.contoso.local`.
 
-If your exchange services and connections are configured to use local or intranet names like `localhost` or `mail.contoso.local` then the service will not have a valid TLS connection to the server and will not be able to use the certificate, this is because the name is not included in the certificate your are trying to use. You will need to ensure that all services and connections use valid hostnames which match your certificate(s).
+If your exchange services and connections are configured to use local or intranet names like `localhost` or `mail.contoso.local` then the service will not have a valid TLS connection to the server and will not be able to use the certificate, this is because the name is not included in the certificate you are trying to use. You will need to ensure that all services and connections use valid hostnames which match your certificate(s).
 
 ### IP Address Bindings vs SNI Hostname Bindings
 If you manually create an https "binding" (the configuration of an IP address or hostname + socket + certificate) then you should enable SNI (Server Name Indication), set a hostname and avoid using specific IP addresses, instead use `All Unassigned` or `*` in IIS etc. This maps to the catch-all address `0.0.0.0` and matches the binding to all network interfaces.
@@ -97,7 +97,7 @@ Some other clients to consider for very specific tasks include [Posh-ACME (Power
 
 ## Other resources
 
-Details of the general processes begin importing and installing a certificate for Exchange can be found here:
+Details of the general processes for importing and installing a certificate for Exchange can be found here:
 
 https://learn.microsoft.com/en-us/exchange/architecture/client-access/import-certificates?view=exchserver-2019
 

diff --git a/docs/deployment/tasks/nginx.md b/docs/deployment/tasks/nginx.md
@@ -32,7 +32,7 @@ In a typical nginx config you would only need to specify the **Full Chain** and
 - Point *ssl_certificate* at your **Full Chain** file
 
 ### Restarting nginx
-For your changes to take effect you will need to restart Nginx. You can do this by adding a *Stop, Start or Restart a Service" task after your *Deploy to nginx* task.
+For your changes to take effect you will need to restart Nginx. You can do this by adding a "Stop, Start or Restart a Service" task after your *Deploy to nginx* 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 Certificate Manager* 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.