TLS Configuration Generator

Generate a modern or intermediate TLS configuration for Nginx, Apache, IIS, ASP.NET Core or Node, with the client compatibility each profile costs you stated up front.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Compatibility profile

Server

Domain

Redirect HTTP to HTTPS Include HSTS Enable OCSP stapling

Two profiles, and what each one excludes

The profiles follow Mozilla's Server Side TLS guidance, which is the closest thing the industry has to a reference. Every configuration choice costs you some clients, so the tool states which ones rather than leaving you to find out from a support ticket.

Intermediate - TLS 1.2 and 1.3. This is the right choice for almost every public website. It excludes Windows XP, Android 4.3 and earlier, Java 7 and IE 10 and below, which is essentially nothing that still browses the web.
Modern - TLS 1.3 only. Simplest and strongest, and it excludes considerably more: Windows 8.1, Android 9, Java 8, OpenSSL 1.0.x, and any client library not updated since about 2018. If you serve an API consumed by embedded devices or older server-side clients, this will break some of them.

There is no "old" profile here

Mozilla's guidance includes a third profile that enables TLS 1.0 and 1.1. This tool will not generate it. Both were formally deprecated by RFC 8996 in 2021, current browsers refuse them, and a configuration that turns them back on is not something to hand out with a copy button. If you genuinely need to support a client that old, that is a decision to make deliberately with the vendor's own documentation, not from a generator.

Choices the generated config makes, and why

Cipher order is left to the client

The output sets ssl_prefer_server_ciphers off. That looks like giving up control, and it is the better choice: modern clients pick better than a fixed server order does. A phone without AES hardware acceleration will choose ChaCha20-Poly1305, which is several times faster on that device; forcing server order would hand it AES-GCM instead and make it slower for no security gain.

Session tickets are disabled

Session tickets are encrypted with a key that most deployments never rotate. An unrotated ticket key is a long-lived secret capable of decrypting recorded sessions, which quietly undoes the forward secrecy the cipher suites were chosen for. Turning tickets off costs a small amount of handshake performance and removes that risk entirely.

HSTS is generated with a warning

HSTS is close to irreversible. Once a browser has seen the header it refuses plain HTTP for the full max-age, and you have no way to reach those browsers to tell them otherwise. Deploy a short max-age first - 300 seconds - confirm everything works over HTTPS, then raise it.

The generated config deliberately does not include includeSubDomains. That directive applies to every subdomain, including ones you have forgotten, and it is the part that turns an HSTS mistake into an outage on a service nobody was thinking about. Add it once you are certain.

OCSP stapling is increasingly a no-op

Stapling has the server fetch its own revocation status and attach it to the handshake, which saves the visitor a round trip and stops the certificate authority learning which sites they visit. It is worth enabling - but Let's Encrypt stopped running OCSP responders in 2025, so for certificates issued by them there is nothing to staple. The option remains because it still matters with CAs that run OCSP, and it is harmless either way.

IIS is different from the others

IIS does not configure TLS itself. It uses the Windows Schannel provider, so the changes are registry edits that affect every service on the machine, not just the site you have in mind, and they require a reboot. The generated output is PowerShell rather than a site configuration for that reason, and it says so. Test it on a non-production server first.

ASP.NET Core behind IIS or a reverse proxy is in the same position from the other direction: TLS is usually terminated at the proxy, so the Kestrel settings have no effect and the proxy is what you need to configure.

Serve the full chain

Every generated configuration points at a fullchain.pem, and this is the single most common deployment mistake worth repeating. The file must contain your certificate followed by every intermediate, in order, and not the root.

An incomplete chain is the failure that looks fine in a desktop browser and breaks everywhere else - browsers frequently repair a missing intermediate from cache, while mobile apps, API clients and older devices refuse the connection outright. Verify after deploying with SSL Certificate Chain Checker.

Verify what you deployed

A generated configuration is a starting point, not a result. After deploying, confirm the server actually negotiates what you intended with TLS Cipher Suite Analyzer, and check the wider picture with Website Security Audit. Everything on this page is generated in your browser - no domain name or configuration is sent anywhere.

Frequently asked questions

Which profile should I choose?

Intermediate, unless you have a specific reason not to. It supports everything that still browses the web and excludes only genuinely obsolete clients. Modern is better if you control every client, which usually means an internal application or a modern API.

Why does the config not force server cipher order?

Because clients choose better. The main case is ChaCha20-Poly1305 on devices without AES hardware, where it is substantially faster. Forcing server order would override that for no security benefit.

Why no includeSubDomains on the HSTS header?

Because it applies to every subdomain including forgotten ones, and it cannot be undone quickly. Add it deliberately once you are certain every subdomain serves HTTPS.

Is TLS 1.2 still safe?

Yes, when configured well - which means forward-secret, AEAD cipher suites, exactly what the intermediate profile specifies. TLS 1.3 is better because it removes the ability to configure it badly, not because 1.2 is broken.

Does this send my domain name anywhere?

No. The configuration is assembled in your browser from the options you pick. Nothing is transmitted.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.