Add blog article for cert mgmt intro, begin acme server docs

Author: webprofusion-chrisc

blog/2025-07-01-certificate-automation-intro.md

@@ -0,0 +1,150 @@
+---
+title: Introduction to Certificate Management Automation
+description: Learn the fundamentals of automated SSL/TLS certificate management and why it's essential for modern infrastructure.
+slug: certificate-automation-intro
+authors: webprofusion-chrisc
+tags: [certify, certificates, automation, ssl, tls]
+image: https://certifytheweb.com/images/management/summary.png
+hide_table_of_contents: false
+---
+
+Your certificates are essential for securing web traffic, APIs, and internal communications. Manually managing certificates across multiple servers and applications can be time-consuming, error-prone, and increasingly impractical as certificate lifetimes continue to shrink. 
+
+This article introduces the fundamentals of certificates and certificate management automation and explains why it's becoming essential for modern infrastructure.
+
+<!-- truncate -->
+
+## Why Automate Certificate Management?
+
+Manual certificate management worked when certificates had longer lifetimes, but the landscape is rapidly changing:
+
+- **Shorter Certificate Lifetimes**: Let's Encrypt currently issues 90-day certificates, and there's industry movement toward even shorter lifetimes (potentially 47 days in the future)
+- **Scale Challenges**: Managing dozens or hundreds of certificates manually becomes unmanageable
+- **Reduced Downtime**: Automated renewal eliminates the risk of expired certificates causing service outages
+- **Security Benefits**: Fresh certificates with shorter lifetimes reduce the window of vulnerability if a private key is compromised
+
+Starting your automation journey now prepares you for the future of certificate management.
+
+## Understanding the Certificate Lifecycle
+
+Certificate management automation involves three main phases:
+
+### 1. Certificate Ordering and Validation
+
+A Certificate Authority (CA) is a public or internal entity which issues certificates. Public CAs issue trusted certificates. That trust happens because your OS/browser already knows and trusts their root issuing certificate via OS/software updates (and in turn any intermediate issuer they have signed using that root).
+
+Automated certificate management can use various technologies but the most commonly used is the Automatic Certificate Management Environment (ACME) standard: [RFC8555](https://datatracker.ietf.org/doc/html/rfc8555/)
+
+#### Wait, what is a certificate though?
+A certificate is an assurance by an issuer (the CA) that the entity that requested the cert (and held a specific private key, which is a secret chunk of data only your system knows) was verifiably in control of the identifiers included as subjects in the certificate details, at the time the cert was issued. 
+
+A cert typically contains a set (Subject Alternative Names or SAN) of identifiers which can be domains, IP addresses etc) and the public key that corresponds to your private key.
+
+When using a cert you need your private key and the cert in combination, this is then loaded by the service that uses the certificate to begin the TLS (transport layer security) conversation. The client (browser etc) on the other end of the conversation already trusts the root certificates of the CA via OS updates or other "trust store" certificate distribution.
+
+#### Domain Validation
+CAs like Let's Encrypt, Google Trust Services, and traditional commercial CAs require proof that you control the domains included in your certificate. This validation typically happens through:
+
+**HTTP Domain Validation**: The CA checks for a specific file or response at a well-known URL on your domain. Automation tools can handle this by temporarily serving the required response.
+
+**DNS Domain Validation**: The CA looks for a specific TXT record in your domain's DNS. Modern certificate management tools can automatically update DNS records through provider APIs, making this method ideal for internal services or when HTTP validation isn't feasible.
+
+Modern certificate management systems can support multiple CA accounts and the best ones even provide automatic fallback strategies if your preferred CA experiences issues.
+
+### 2. Certificate Storage and Distribution
+
+Once obtained, certificates need to be securely stored and made available to the applications that need them. This typically involves:
+
+- **Local Certificate Stores**: On Windows, this means the machine certificate store
+- **File-based Storage**: PFX archives or PEM files for cross-platform compatibility
+- **Secrets Management**: Integration with services like Azure Key Vault or HashiCorp Vault
+
+### 3. Deployment and Application Integration
+
+This is often the most complex phase, as every application has its own way of consuming certificates:
+
+- **IIS Integration**: Windows IIS can use certificate store bindings or Centralized Certificate Store
+- **File-based Applications**: Many applications read certificates from specific file paths
+- **API-based Updates**: Some services accept certificate updates through REST APIs
+- **Service Restarts**: Some applications require restart after certificate updates
+
+Additionally some applications or appliances require using their own private keys for certificate signing requests (CSRs), or require key re-use for Certificate Pinning (trusts a specific set of certificate public keys).
+
+## Deployment Strategies
+
+### Built-in Integration Tasks
+
+Modern certificate management tools can provide various levels of built-in support for common scenarios:
+- **Web Servers**: IIS, Apache, Nginx
+- **Mail Servers**: MS Exchange etc
+- **Secrets Vaults**: Store certificates as secrets for other apps and services to consume
+- **Cloud Services**: Integration with cloud provider certificate services
+
+### Custom Deployment Tasks
+
+For unique environments, mature automation tools typically offer:
+- **Export Tasks**: Convert certificates to various formats (PEM, PFX etc)
+- **File Copy Operations**: Deploy certificates over UNC shares or SSH
+- **Scripting Integration**: PowerShell, Bash, or other scripting languages for custom logic
+- **API Calls**: Update configuration or send notifications through REST APIs or other interfaces
+
+### Progressive Automation
+
+You don't need to automate everything at once. A typical progression might be:
+
+1. **Manual Export**: Start by automating certificate acquisition, then manually deploy during maintenance windows
+2. **Automated Export**: Set up automatic export to shared locations where applications can find updated certificates
+3. **Full Automation**: Implement automatic deployment and service updates. Consider monitoring deployment to ensure what you think is deployed is actually working.
+
+## Deployment Types
+
+Services that secure communication using TLS reference certificates in a variety of way. Deploying your cert to them requires knowing how the service loads/selects the certificate:
+
+- **Thumbprints**: On Windows a cert is commonly stored in the local machine certificate store and referenced by applications using the "Thumbprint" value, this is usually the SHA1 hash of the certificate details, which changes with each renewal even if the same private key is reused. 
+- **PFX**: This is an archive format also known as PKCS#12 or .p12, most popular on Windows. It contains your cert, intermediate issuers (but not the root), and the private key. The private key can optionally be password protected.
+- **PEM**: Certificates can be split into component files with the primary ("leaf" or "end-entity") certificate and the private key in PEM encoded (base64) text files. These are commonly used for apps that are not native to Windows, or on Linux services etc where PFX/.p12 is less frequently encountered.
+
+Deploying a cert can variously involve:
+- Updating a thumbprint value on a port binding, file or registry key (typical on Windows).
+- Copying cert files to a specific location, in specific formats.
+- Restarting/reloading services so they pick up the latest cert.
+
+## Planning Your Automation Strategy
+
+Before implementing certificate automation, consider:
+
+1. **Inventory Your Certificates**: Document all certificates currently in use and their renewal deployment methods
+2. **Assess Application Requirements**: Understand how each application consumes certificates
+3. **Network Access**: Ensure your automation tool can reach all target systems, or target systems can pull the latest cert regularly.
+4. **Security Boundaries**: Plan for deployment across different security zones or networks
+5. **Monitoring and Alerting**: Implement monitoring to detect renewal failures or deployment issues
+
+## Getting Started
+
+The complexity of certificate automation varies greatly depending on your environment, but the key is to start simple and gradually expand your automation coverage. Modern tools like Certify Certificate Manager make it easy to begin with basic scenarios and progressively add more sophisticated deployment tasks as your needs grow.
+
+The goal is to transform certificate management from a manual, error-prone task into a reliable, automated process that enhances both security and operational efficiency.
+
+### Our Products
+**Certify Certificate Manager (CCM)** is our Windows-based UI for certificate management and has been around for several years. 
+- Around 200K active installs globally
+- Optimized for Windows/IIS certificate management
+- Full UI for management and configuration
+
+**Certify Management Hub** (in beta) is our new self-hosted cross-platform web UI and API which can also talk to and configure many CCM instances (v7 onwards).
+- Start small and simple, grow with your requirements
+- Centralized role-based access, controlled API access
+- New agent for Linux and macOS which has the same core as CCM
+- Experimental support for monitoring external ACME clients and can report status of renewals for things like acme.sh, certbot etc.
+- Managed Challenges allow centralized DNS challenge config without distributing sensitive credentials
+- New experimental ACME API allows standard ACME clients to order certs as normal but have the hub respond to domain validation challenges automatically on their behalf.
+
+Features include:
+- Multi-CA support with optional automated fallback
+- Automated renewal and deployment tasks
+- Status reporting to our hosted Dashboard or to the self-hosted Management Hub
+- Automated zero-config recurring failure notification emails via our hosted API.
+
+## Next Steps
+
+Ready to start your certificate automation journey? Check out our [Getting Started Guide](/docs/intro) or explore our range of [certificate management tools](/) to find the solution that best fits your environment.

blog/authors.yml

@@ -3,6 +3,4 @@ webprofusion-chrisc:
   title: Lead Developer of Certify The Web
   url: https://github.com/webprofusion-chrisc
   image_url: https://avatars.githubusercontent.com/u/2445502?v=4
-  socials:
-    x: webprofusion
-    github: webprofusion-chrisc
+  

docs/guides/tools.md

@@ -4,6 +4,7 @@ title: Useful Tools
 ---
 
 ## Useful ACME Related Tools
+The following tools can be useful for ACME related debugging, configuration and analysis.
 
 - **[Let's Debug](https://letsdebug.net):** Diagnose ACME challenge issues and validate domain configuration.
 - **[SSL Labs Server Test](https://www.ssllabs.com/ssltest/):** Comprehensive SSL/TLS configuration and certificate analysis.

docs/hub/guides/acme-server.md

@@ -0,0 +1,31 @@
+---
+title: Managed ACME Service
+---
+
+## Summary
+The Hub API can provide a simple ACME service which proxies certificate orders to real Certificate Authorities and takes care of the domain validation on behalf of the calling ACME client. 
+
+This means you can point any ACME client client at the Hub ACME directory URL, ask it to complete HTTP domain validation (or none at all) and the hub will transparently order the corresponding certificate and complete domain validation on the clients behalf using a matching pre-configured a Managed Challenge. 
+
+If your ACME client support External Account Binding (EAB) this can be used to identify and authorize the client, if EAB is not supported you can optionally enable a unique ACME URL for each client.
+
+### Example
+
+If you control a domain "projectbids.co.uk" and wanted to create a certificate "internal-app.projectbids.co.uk" from another device, that device has an ACME client but can't answer ACME http/dns challenges itself, you could instead use the hub to:
+- Configure a Managed Challenge which can update the target domain DNS.
+- Setup EAB credentials for your ACME client to use to identify itself to the hub and authorized it to use the required managed challenge.
+- Configure your ACME client to use the hub ACME API, providing the EAB credentials to identify itself to the hub during ACME account creation
+- Configure a new certificate in your ACME client with a domain/identifier matching the managed challenge.
+
+## Setup your Managed Challenge
+
+Configure a [managed challenge](./managedchallenges.md) in the hub to answer challenges for your target domain. 
+
+### Creating EAB Credentials
+- Under Settings > Users, create an application security principal to represent your ACME client e.g. *Example ACME Client on firewall-01*. Assign the role *Managed ACME Consumer*
+- Under API Access, select Add API Token. Provide a descriptive title e.g. *Example ACME EAB Credentials*, select the security principle you created, select/scope the token to the *Managed ACME Consumer* role. 
+- Select *View as EAB* against the credential, copy the displayed values for use in your ACME client during initial ACME account creation.
+
+### Setup your ACME client
+
+In your ACME client of choice (on any device that can communicate with the hub API), configure the client to use the `<your hub api url>/acme/directory` ACME service and provide the EAB credentials you have created. The ACME client will register a new account against the ACME service, you can then order a new certificate for identifiers matching your managed challenge that was configured in the hub.

docs/hub/managedchallenges.md docs/hub/guides/managedchallenges.mddocs/hub/managedchallenges.md renamed to docs/hub/guides/managedchallenges.md

@@ -117,7 +117,7 @@ export default {
           type: 'category',
           label: 'Managed Challenges',
           items: [
-            'hub/managedchallenges',
+            'hub/guides/managedchallenges',
           ]
         },
          {