keepcalculator

06 Numbers and Powers

Let’s Encrypt vs Commercial vs Self-Signed SSL

Card No. 06·38096 · Updated · Standard formula, shown below

Let’s Encrypt, commercial certificates, and self-signed certificates all serve the same basic purpose—encrypting traffic between a browser and a server—but they differ in trust, cost, and management effort. For most public websites, Let’s Encrypt is the best choice because it’s free, automated, and trusted by all major browsers; commercial certificates add little for typical sites but may offer extended validation or premium support; self-signed certificates should only be used for internal testing or private networks where clients can be configured to trust them.

Background: What an SSL/TLS Certificate Actually Does

An SSL/TLS certificate is a small data file that binds a cryptographic public key to a domain name. When a browser connects to a server, the server presents its certificate. The browser checks that the certificate is valid, that it matches the domain, and that it was issued by a Certificate Authority (CA) the browser trusts. If all checks pass, the browser and server establish an encrypted connection using the public key in the certificate.

The certificate itself does not encrypt data—it enables the encryption handshake. The actual encryption uses a symmetric session key generated during the handshake, but that key is exchanged securely using the certificate’s public/private key pair. Without a valid certificate, browsers show a warning that can drive visitors away.

How the Three Types Differ

Let’s Encrypt is a free, automated CA run by the Internet Security Research Group (ISRG). It issues domain-validated (DV) certificates that are valid for 90 days and must be renewed automatically via the ACME protocol. Because it’s free and automated, it has become the default for most websites.

Commercial certificates are sold by CAs like DigiCert, GlobalSign, or Sectigo. They come in three validation levels: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). DV certificates are similar to Let’s Encrypt but cost money; OV and EV require the CA to verify the organization’s legal existence, and EV shows the organization’s name in the browser address bar. Commercial certificates are typically valid for one or two years and often come with warranties and human support.

Self-signed certificates are generated by the server administrator using tools like OpenSSL. They are encrypted and function technically, but no CA vouches for them. Browsers do not trust them by default, so visitors see a “Your connection is not private” warning. They are useful for internal tools, development environments, or IoT devices where you control the clients.

Cost Comparison: Free vs. Paid vs. DIY

Let’s Encrypt is completely free—no cost for the certificate itself, and the automation tools (like Certbot) are also free. The only cost is your time to set up the initial configuration and renewal.

Commercial certificates range from roughly $10 to over $300 per year, depending on the validation level and the CA. DV certificates are the cheapest, OV costs more, and EV is the most expensive. You also pay for the CA’s infrastructure, support, and in some cases, a warranty that covers financial losses if the CA makes a mistake.

Self-signed certificates cost nothing to generate, but they have hidden costs: you must manually distribute the certificate to every client that needs to trust it, and you must manage expiration dates yourself. For a small internal team, this is manageable; for a large organization, it becomes a maintenance burden.

Trust and Browser Warnings: The Key Difference

The most significant practical difference is how browsers treat each type. Let’s Encrypt and commercial certificates are both trusted by default in all major browsers—Chrome, Firefox, Safari, Edge, and mobile browsers. The browser checks the certificate chain back to a root CA that is pre-installed in the browser or operating system.

Self-signed certificates are not in any browser’s trust store. When a user visits a site with a self-signed certificate, the browser displays a full-page warning that the connection is not private. The user must click through several screens to proceed, which is a poor experience and a security risk because users may ignore genuine warnings. In some cases, browsers like Chrome may block the site entirely if the certificate is for a public domain.

There is a common misconception that self-signed certificates are less secure than CA-issued ones. In terms of encryption strength, they are identical—both use the same cryptographic algorithms. The difference is authentication: a CA-issued certificate proves that someone with control of the domain obtained it, whereas a self-signed certificate proves nothing about who controls the domain. An attacker could create a self-signed certificate for any domain, so browsers cannot trust them.

Choosing the Right Type for Your Use Case

Here is a practical decision guide:

  • Public website or API: Use Let’s Encrypt. It’s free, trusted, and automated. No reason to pay for a DV certificate.
  • E-commerce or high-trust site: Consider an OV or EV commercial certificate if you want to display your organization’s name in the address bar (EV) or if you need a warranty. Some users feel more confident with EV, though browsers are gradually de-emphasizing it.
  • Internal corporate tools: Use an internal CA (like a Windows Server CA) or a self-signed certificate that you distribute via group policy. This avoids the cost of public certificates and gives you full control.
  • Development and testing: Self-signed certificates are fine for localhost or staging environments. Use a tool like mkcert to create locally trusted certificates that only your development machine trusts.
  • IoT devices or embedded systems: Self-signed certificates are common because devices often cannot easily renew certificates automatically. Just ensure the client software is configured to trust the device’s certificate.

Common Problems and How to Avoid Them

Let’s Encrypt certificates expire every 90 days. If your renewal automation fails (e.g., the web server is down, DNS changes, or the ACME client is misconfigured), your site will show an error. The solution is to set up robust automation with a tool like Certbot and monitor expiration dates. Many hosting providers now offer automatic Let’s Encrypt integration.

Commercial certificates last longer (1-2 years), but you must remember to renew manually. Set a calendar reminder 30 days before expiration. Some CAs offer auto-renewal, but it often requires a plugin or API integration.

Self-signed certificates are prone to two issues: clients not trusting them (because you forgot to install the root certificate) and expiration (because you forgot to regenerate them). Keep a central inventory of all certificates and their expiration dates.

Another common issue is certificate chain incompleteness. If you don’t install the intermediate certificate along with your server certificate, some clients will fail to validate the chain. Most CAs provide a bundle; Let’s Encrypt clients handle this automatically.

Security Considerations Beyond the Certificate

Choosing a certificate type is only one part of TLS security. You should also:

  • Use a strong key size (RSA 2048 or 4096 bits, or ECDSA).
  • Enable TLS 1.2 or 1.3; disable older protocols like TLS 1.0 and SSL 3.0.
  • Configure secure cipher suites (e.g., ECDHE with AES-GCM).
  • Use HSTS (HTTP Strict Transport Security) to force HTTPS.
  • Renew certificates before expiration; even a few hours of downtime can cause issues.

Self-signed certificates are often criticized for being insecure, but the encryption itself is strong. The risk is that users may be tricked into accepting a malicious certificate if they are not careful. Therefore, never use self-signed certificates on public-facing sites where users cannot easily verify the certificate fingerprint.

Frequently Asked Questions

Can I use Let’s Encrypt for a commercial website? Yes, Let’s Encrypt certificates are trusted by all major browsers and are suitable for any public website, including e-commerce. The only difference from a paid DV certificate is that you must renew every 90 days, which is automated.

What is the difference between DV, OV, and EV certificates? DV (Domain Validation) only verifies that you control the domain. OV (Organization Validation) verifies your organization’s legal existence and address. EV (Extended Validation) requires a more thorough vetting and displays your organization’s name in the address bar. Let’s Encrypt only issues DV certificates.

Is a self-signed certificate ever acceptable for a public website? No. It will cause browser warnings and erode user trust. It is only acceptable for internal use where you can configure clients to trust it.

How long does a Let’s Encrypt certificate last? 90 days. This short lifespan is intentional to encourage automation and limit damage if a private key is compromised.

Can I get a commercial certificate for free? Some CAs offer free trial certificates, but they are not suitable for production. Let’s Encrypt is the only widely trusted free CA.

What happens if my Let’s Encrypt renewal fails? Your certificate will expire, and browsers will show a security warning. You can manually renew by running the ACME client again, but it’s better to set up monitoring to catch failures early.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →