Certificate Deployment Tool

Generate deployment configurations

About Certificate Deployment Tool

The Certificate Deployment Tool generates ready-to-use deployment configurations for popular web servers including Nginx, Apache, and HAProxy. After issuing or importing a certificate, use this tool to get the correct file paths, directory permissions, and SSL configuration snippets for your server type.

How to Use

1Enter the domain name for which you have a certificate.
2Click Run to generate deployment configurations for your web server.
3Copy the generated config and deploy your certificate with correct file paths and permissions.

Use Cases

•Quickly deploy newly issued certificates to Nginx or Apache servers
•Generate HAProxy SSL frontend configurations for load-balanced environments
•Standardize certificate deployment across multiple servers with consistent configs

Frequently Asked Questions

The deployment tool supports Nginx, Apache, and HAProxy configurations. Each configuration includes the correct SSL directives, file paths for certificate and key files, and recommended security settings.

The tool generates the server configuration snippets, but you need to ensure the certificate PEM and private key files are in the paths specified in the configuration. Use our Download tools to get the certificate files.

Yes, generated configurations follow security best practices including strong cipher suites, proper file permissions, and modern TLS protocol versions. You should always review configurations before applying them to production.

Three: nginx, Apache and HAProxy, selected before generating. Nginx gets a server block listening on 443 with ssl_certificate and ssl_certificate_key; Apache gets a virtual host with SSLEngine on and the equivalent directives; HAProxy gets a frontend binding 443 with a combined PEM. Anything else — Caddy, IIS, Traefik — will need the same values transcribed into its own syntax, which the output makes easy to copy across.

Under a per-domain directory matching the paths in the output, conventionally beneath /etc/ssl with the server's user able to read them. The nginx and Apache outputs expect a fullchain file and a separate private key file; the HAProxy output expects one combined file holding the chain followed by the key. Keep the key readable only by root and the server process, since its permissions matter as much as its location.

Because everything older is a finding waiting to happen. TLS 1.0 and 1.1 are deprecated and flagged by every scanner, and SSL versions older still are actively exploitable. TLS 1.2 remains for compatibility with older clients while 1.3 handles everything modern. If an audit still demands 1.2-only, that is a client-compatibility decision to make deliberately, not a default to inherit.

It is a cipher selection expression, not a fixed list. HIGH selects strong ciphers, !aNULL removes anything without authentication, and !MD5 removes suites built on a broken hash. Writing it as an expression rather than enumerating suites means it stays sensible as libraries update their definitions. Servers with compliance requirements beyond this — PCI or FIPS profiles — should layer their mandated suite list on top.

Work through the three usual causes in order. First the file paths: the certificate and key must exist exactly where the output points, including the domain directory. Second the syntax check: nginx -t or apachectl configtest will name the offending line. Third the key match: the key must correspond to the certificate, which the key-checksum page on this site can confirm by comparing the two files you deployed.

What the Generator Produces

Give it a domain and a server type and it writes the TLS portion of that server's configuration with your domain already filled in. The output is a starting point shaped by current practice, not a dump of every possible directive.

1Pick the server block for your software — an nginx server stanza, an Apache virtual host, or an HAProxy frontend. Each one points at certificate files under a per-domain directory so multiple sites stay separated.
2Get protocols pinned to TLS 1.2 and 1.3 with a cipher selection that excludes anonymous and MD5-based suites. Older protocol versions are the most common configuration finding on real servers, so the generated defaults simply do not offer them.
3Mind the HAProxy difference: its stanza references a single combined PEM rather than separate certificate and key files, because that is how HAProxy consumes them. Concatenate the full chain and the key into that file before reloading.

The generator writes configuration; it does not install anything. Copy the output into your server's configuration, place the certificate files at the referenced paths, test the syntax with your server's config check, and reload. Then verify the result with the scanner pages on this site.

Tips & Best Practices

•Test certificate deployment in staging before production
•Verify certificate installation with SSL checker after deployment
•Document deployment procedures for disaster recovery
•Monitor certificate deployment status across all servers

Technical Details

Deployment: Certificate deployment to web servers
Servers: Nginx, Apache, HAProxy, IIS deployment guides
Verification: Post-deployment certificate validation
Output: Deployment instructions with server-specific steps