> For the complete documentation index, see [llms.txt](https://docs.certinext.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.certinext.io/documentation/automation-and-devops/webservers-and-load-balancers.md).

# Webservers and Load Balancers

Web servers and load balancers are primary endpoints for TLS termination and are among the most certificate-dependent components in enterprise infrastructure. CERTInext enables automated discovery, issuance, deployment, renewal, and monitoring of certificates used by web servers and load balancers across on-prem, cloud, and hybrid environments.

By integrating provisioning bots and CA connectors, CERTInext ensures uninterrupted HTTPS availability and policy-compliant cryptographic configuration.

#### Purpose

Managing certificates on web servers and load balancers allows organizations to:

* Prevent service outages caused by expired certificates
* Automate TLS certificate deployment
* Maintain standardized key sizes and algorithms
* Enforce approved CA usage
* Centralize visibility across distributed infrastructure
* Reduce manual configuration errors

#### Supported Platforms

CERTInext provisioning supports common server and load balancer platforms, including:

* Apache HTTP Server
* Nginx
* Microsoft IIS
* Tomcat and other Java-based servers
* F5 BIG-IP
* Palo Alto
* FortiGate
* Cloud-based load balancers

Additional platforms can be supported through SSH, WinRM, or API-based integrations.

#### Discovery

Using Discovery Bots, CERTInext can scan:

* Public-facing HTTPS endpoints
* Internal web services
* Custom ports (e.g., 443, 8443, 9443)
* IP ranges or FQDNs

Discovered certificates appear in the centralized inventory along with:

* Expiration date
* Issuer CA
* Key algorithm
* Protocol support
* Cipher strength

#### Automated Provisioning

Provisioning Bots can:

* Submit CSR to configured CA
* Retrieve issued certificate
* Install certificate into server keystore
* Update bindings (e.g., IIS site bindings)
* Restart or reload services where required

Deployment timing can be configured to occur:

* Immediately after issuance
* During scheduled maintenance windows

Rollback protection can revert to the previous certificate if deployment fails.

#### Renewal Automation

Renewal is triggered based on:

* Days before expiry (e.g., 30–45 days)
* Specific scheduled date

Once renewed, the certificate is automatically redeployed to the configured web server or load balancer.

#### Common Use Cases

**Public-Facing Websites**\
Automate issuance and renewal of publicly trusted certificates.

**Internal Applications**\
Use Private CA certificates for internal portals and services.

**Load Balancer TLS Termination**\
Manage certificates centrally for multi-node traffic distribution.

**Multi-Environment Deployment**\
Maintain separate certificates for Dev, QA, and Production environments.

#### Monitoring and Alerts

Certificates deployed to web servers and load balancers are monitored for:

* Expiry
* Policy violations
* Weak cryptographic parameters
* Deployment failures

Alerts are triggered based on configured thresholds.

#### Security Best Practices

* Use minimum RSA 2048 or stronger key sizes
* Prefer SHA-256 or stronger signature algorithms
* Enable automated renewal 30–45 days before expiry
* Restrict provisioning bot permissions to required scope
* Regularly validate load balancer bindings

#### Important Notes

* Ensure required ports are accessible for deployment (e.g., SSH, WinRM, API ports).
* Confirm keystore paths and permissions are correctly configured.
* Validate certificate chain installation to avoid trust errors.
* For clustered environments, ensure all nodes receive updated certificates.