Generate SSL configuration for Nginx, Apache, and HAProxy
Generated Configuration
Error
About Server Config Generator
Our free Server Config Generator creates optimized SSL/TLS configuration for Nginx, Apache, and HAProxy. Generate production-ready configs with modern cipher suites, protocol settings, OCSP stapling, and HSTS headers.
How to Use
1Select your web server (Nginx, Apache, or HAProxy).
2Choose the security level (Modern, Intermediate, or Old).
3Click "Generate Config" to get the optimized configuration.
Server configuration for TLS is the same handful of decisions expressed in different syntaxes. This page writes the current-practice version of those decisions.
1Pin the protocol range to 1.2 and 1.3, so older clients still work while nothing older is offered. That pair covers essentially all current traffic and removes whole categories of weakness without breaking anyone.
2Select ciphers by expression rather than enumeration — strong suites, no anonymous, no broken hashes — so the configuration stays sensible as library definitions change instead of needing editing each time a new suite appears.
3Point at the certificate paths and keep them stable, because live paths that survive renewal are what let you deploy once and forget. Copying certificate files elsewhere is what creates the stale-certificate class of outage.
The adjacent pages go deeper on individual decisions: which suite to prefer, whether to pin cipher order, and what each hardening header is for. This is the baseline to start from.
Tips & Best Practices
•Use Modern level unless you need to support older browsers
•Test your configuration with SSL Labs after deployment
•Regularly update cipher suites as new vulnerabilities are discovered
Frequently Asked Questions
Use modern unless you have a specific reason not to. Modern is TLS 1.3 only, which removes every cipher and extension that has a known weakness by construction rather than by configuration. Intermediate adds TLS 1.2 with a restricted suite list, which is the right choice when you serve clients that cannot do 1.3, such as older embedded devices or long-lived software. Old should be reserved for a measured, documented need, because it reintroduces protocols that carry known attacks.
The generated configuration includes the stapling directives. For it to work the server also needs the full certificate chain, including intermediates, and has to be able to reach the authority's OCSP responder, because stapling is the server fetching the response once and presenting it to every client. Without the chain the fetch fails and the response is never stapled. Stapling also requires TLS 1.2 or better, since older protocols have no extension to carry it.
Yes, the generated output is a starting point rather than a finished file, and the cipher directive is meant to be edited. Change it to match what your clients actually support, but keep two things in mind: test before deploying, and remove rather than add when in doubt, since an over-long list only creates opportunities for a client to negotiate something weaker. A list that works for a broad audience is short, because modern clients all support the same small set.
Protocols restricted to 1.2 and 1.3, a strong cipher list, a valid certificate covering the hostname, and HSTS sent over HTTPS. Everything else is refinement. That baseline is what the generated configurations here implement, and it satisfies essentially every compliance requirement while breaking no current client.
An expression is more maintainable. Selecting by strength and excluding the known-broken families means the configuration stays correct as library definitions change, whereas an explicit list needs editing whenever something is added or deprecated. Where a compliance profile mandates specific suites, layer that list on top — the two approaches coexist.
At stable paths that do not change on renewal, so your server configuration is written once. Conventions keep each domain in its own directory beneath a common root, which makes multiple sites separable and backups predictable. What matters is that the path does not move, because every renewal then replaces the contents and nothing else needs touching.
On TLS 1.2, yes — it removes the client's ability to steer selection toward something weaker by reordering its own list. On 1.3 it matters much less because clients cannot control suite selection the same way. It is a small change with no compatibility cost, so there is little reason not to set it.
Yes, and periodically. Configuration drifts — a directive removed during unrelated work, a header dropped by a deploy, a host left behind after a migration — and none of it breaks anything visibly. The snapshots and comparison pages on this site exist to make that drift visible, which is the only way it gets noticed.
