WordPress SSL certificate: what it is and how to install one

An SSL certificate is what turns http://yoursite.nl into https://yoursite.nl with the padlock in the address bar. The underlying technology is actually called TLS (the successor to SSL), but the industry keeps calling the certificates "SSL certificates" and so does this article. What the certificate does is two things at once: it encrypts every byte between the visitor's browser and your web server, and it proves to the browser that the server it is talking to genuinely controls the domain name you typed. WordPress does not issue the certificate. Your web server or your host does, and WordPress just follows what the server and the database tell it about which URL to use.

This is a concept article. If you are looking for the exact commands to force WordPress onto HTTPS after the certificate is installed, that is how to force WordPress to HTTPS. If your certificate is installed but your site still shows a broken padlock, that is mixed content in WordPress. If you want the bigger security picture, start with WordPress security hardening.

What an SSL certificate actually does

RFC 8446, the TLS 1.3 specification, describes three properties the protocol provides: authentication, confidentiality, and integrity. Authentication means the server can prove its identity to the client; confidentiality means only the two endpoints can read what they are saying; integrity means neither side can change a message in transit without the other noticing. The certificate is how authentication happens. Everything else follows from it.

Think of the certificate as a passport. Your web server holds a private key that only it knows. A trusted third party, the certificate authority (CA), has signed a document that says "the entity holding this private key controls the domain yoursite.nl". When a browser connects to your site, the server presents the signed document and proves it holds the matching private key. The browser checks the CA's signature against its built-in list of trusted authorities, and if everything lines up it trusts that it is really talking to the server for yoursite.nl and not to an attacker on the same coffee-shop wifi. After that, the two sides negotiate a fresh symmetric encryption key and the rest of the conversation is scrambled.

The encryption part is commodity. GlobalSign, a paid CA, notes bluntly that free and paid certificates both "provide 256-bit certificate encryption and 2048-bit key encryption". The cipher suite is negotiated between browser and server at the start of the connection, and it does not care whether the certificate cost you nothing or five hundred euros per year. The differences between certificate types are about identity, not crypto. That is the single most important thing to internalise about this topic.

DV, OV, and EV: the three identity tiers

SSL.com explains that "all X.509 certificates use similar methods to assure encryption, authentication, and integrity" but that they "vary significantly in the information they include about the identities that they secure". There are three tiers, and they differ only in how hard the CA checked before signing.

Domain Validation (DV). The CA only confirms that whoever requested the certificate controls the domain. The check is automated: the CA asks you to put a specific string in a DNS record or a file at http://yoursite.nl/.well-known/acme-challenge/..., waits a few seconds, and signs. Let's Encrypt is DV. Most hosting panels issue DV. A DV certificate says "someone with DNS or webroot access to this domain asked for this certificate". It does not say who that someone is.

Organization Validation (OV). The CA verifies a legal entity exists and operates the domain. This involves documents, a phone call, and a few business days. The organization's name ends up inside the certificate itself, visible if you click the padlock and inspect the certificate details. Browsers do not display it prominently any more, which is the main reason OV has lost market share.

Extended Validation (EV). The CA performs a deeper legal and operational check, then signs. Historically, EV certificates produced a green address bar in browsers with the company name next to the URL. That UI is gone. Chrome and Firefox both removed the EV indicator from the address bar in 2019 and 2020 after research showed users did not actually read it. Today, an EV certificate still costs significantly more and still requires a harder verification process, but the visible benefit to a visitor is almost nil.

For a WordPress site, DV is the right default. Every major browser trusts Let's Encrypt, Cloudflare, ZeroSSL and the other free DV issuers by default, and nothing about "this is DV" is visible to visitors. The cases where OV or EV are genuinely justified are narrow: a regulated business context where legal or compliance reviewers ask for the organization to be embedded in the certificate, or a brand-protection scenario where the EV identity is being checked by automated scanning tools. A blog, a portfolio site, a small e-commerce store, or a SaaS landing page belong on DV.

Let's Encrypt, the 90-day lifetime, and the trajectory you should know about

Let's Encrypt is the free, automated certificate authority that made HTTPS the default for the web. As of today it issues its default certificates with 90 days of validity. The Let's Encrypt FAQ is explicit about this: "Our default certificates are valid for 90 days" and "there is no way to adjust these lifetimes". They recommend renewing every 60 days to leave a safety margin.

The 90 days is not arbitrary. Let's Encrypt explains the reasoning in two sentences worth reading: short-lived certificates "limit damage from key compromise and mis-issuance", because a stolen key or a mistakenly issued certificate expires on its own within a quarter, and they "encourage automation, which is absolutely essential for ease-of-use". Long-lived certificates let administrators put renewal in a calendar for next year and forget about it until an incident. Short-lived certificates force automation, which is the only model that scales to the entire web.

Important: 90 days is the today value, not a constant. In April 2025 the CA/Browser Forum passed ballot SC081v3, which mandates a phased reduction of maximum TLS certificate validity for every publicly trusted CA, dropping from today's limit down to 47 days by 2029. Let's Encrypt has published its own schedule that moves default certificates to 45 days by 2028: the tlsserver ACME profile switches to 45-day issuance on May 13, 2026; the default classic profile drops to 64 days on February 10, 2027; and the classic profile drops to 45 days on February 16, 2028. If you read this article after February 2027, the "90 days" number above is already out of date, and the practical implication is only this: renewal has to be automatic, because no human being should be renewing certificates every few weeks by hand.

There is also a short-lived option. As of January 2026, Let's Encrypt's six-day certificate profile is generally available, issuing certificates valid for 160 hours. This is opt-in, it requires an ACME client that supports the shortlived profile, and it is aimed at automation-heavy setups, not at a typical WordPress site. Mention it so you know it exists, then leave it alone.

How the certificate actually gets onto a WordPress site

There are three practical paths, and the one that applies to you is usually determined by the kind of hosting you are on. Each path ends with the same thing: a certificate and a private key installed on your web server, and WordPress itself configured to use https:// URLs.

Path 1: managed WordPress hosting. Your host owns the certificate. A button in the hosting panel, or nothing at all, switches it on, and renewal is handled silently. This is the normal flow on Kinsta, WP Engine, SiteGround, Cloudways, most cPanel hosts with AutoSSL, and every quality Dutch WordPress host. The host runs AutoSSL or an equivalent against Let's Encrypt, the certificate lives in the host's configuration, and nothing about the process is visible to you unless it fails. The honest version of this story is that "automatic" is usually automatic, until a DNS change or a .htaccess rewrite breaks the ACME HTTP-01 challenge and the renewal silently fails. More on that below.

Path 2: cPanel or Plesk with AutoSSL. Same story as managed hosting, but you can see the AutoSSL status page in the control panel. Enable the feature, add the domain, wait for the next AutoSSL run (usually within 24 hours), and watch the status flip to "installed". If AutoSSL refuses to issue a certificate, the panel will tell you why, and the two most common reasons are that the domain does not resolve to the server yet, or that WordPress's .htaccess is blocking /.well-known/acme-challenge/. The fix for the second one is a matching exclude rule in .htaccess, above the WordPress block.

Path 3: self-hosted with certbot. On a VPS or dedicated server that you configure yourself, certbot is the reference ACME client. The certbot instructions walk through the exact commands per OS and web server, and they are kept current. The typical nginx invocation on a Debian server is:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yoursite.nl -d www.yoursite.nl

certbot performs the HTTP-01 challenge (placing a file under /.well-known/acme-challenge/), validates with Let's Encrypt's servers, installs the certificate into nginx's configuration, and adds a redirect from http:// to https://. The renewal cron job (/etc/cron.d/certbot or a systemd timer, depending on the OS) runs twice a day and only renews when the certificate is within 30 days of expiry. You can dry-run the renewal without actually fetching a new certificate:

sudo certbot renew --dry-run

You will know it worked when the dry-run prints Congratulations, all simulated renewals succeeded and the certificate on disk shows a fresh Not After date:

sudo openssl x509 -in /etc/letsencrypt/live/yoursite.nl/fullchain.pem -noout -enddate

Whatever path you used, WordPress then needs to know it is being served over HTTPS. In wp-admin > Settings > General, both "WordPress Address (URL)" and "Site Address (URL)" must start with https://. Since WordPress 5.7, core runs a twice-daily cron job that probes whether HTTPS is actually reachable (wp_is_https_supported()) and, on a site with existing HTTP content, surfaces a one-click migration button in Site Health the moment HTTPS starts working. That button calls wp_update_urls_to_https(), which updates the two URL options, runs a verification check, and automatically reverts if the verification fails. The capability required is update_https, which by default is granted to any user with both manage_options and update_core. For existing sites with content, the full redirect story (including the Cloudflare Flexible trap and the reverse-proxy trap) is covered in how to force WordPress to HTTPS.

How to verify your certificate is actually active

Four quick checks. Run them all after any certificate change, and run the first two at least once a month as a habit.

1. Check WordPress's own Site Health panel. Visit wp-admin > Tools > Site Health. Since WordPress 5.7 the panel explicitly reports whether the site is served over HTTPS and whether WordPress was able to verify it with its own cron probe. If Site Health says "Your website does not use HTTPS" while the browser is clearly on https://, WordPress's probe is failing (usually because the server is returning a 403 or a redirect loop on the probe path) and you should fix that before doing anything else.

2. Use the SSL Labs test for a full third-party view. The Qualys SSL Labs test fetches your site, negotiates TLS, reports the cipher suites, flags weak configurations, and gives you an A-F grade. Anything below A- is worth investigating. The report is cached for a couple of hours, so you cannot use it for rapid iteration, but it is the definitive outside view. No software to install, no terminal needed.

If you have SSH access, the next two checks give you more detail than the browser-based tools above.

3. Curl the home page and read the headers. Run curl -I https://yoursite.nl/ from any terminal. A healthy response is HTTP/2 200 with a Strict-Transport-Security header if you have configured HSTS. If curl prints an SSL error, the certificate is wrong (expired, hostname mismatch, wrong chain), and you can ask curl for details with curl -vI https://yoursite.nl/ 2>&1 | grep -E 'SSL|issuer|subject'.

4. Inspect the certificate directly with openssl. This shows you the issuer, the dates, and the subject alternative names (the list of hostnames the certificate covers):

echo | openssl s_client -servername yoursite.nl -connect yoursite.nl:443 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates -ext subjectAltName

Expected output is an issuer that includes Let's Encrypt (or your CA), a subject with your domain, a notBefore/notAfter range that covers today, and a SAN list that includes every hostname your visitors actually use (yoursite.nl, www.yoursite.nl, and any subdomain you are serving over HTTPS).

Common certificate problems and what they mean

The issues below are the ones that actually reach a support inbox. None of them are about the encryption being broken. All of them are about identity, configuration, or automation.

"NET::ERR_CERT_DATE_INVALID" / certificate expired. The certificate's Not After date is in the past. On a self-hosted server this almost always means certbot's renewal cron is not running, or the last renewal failed silently and nobody read the email from Let's Encrypt. Run sudo certbot renew --dry-run; if that fails, run sudo certbot renew without the dry-run flag and read the actual error. The most common cause on a WordPress host is a .htaccess rewrite that catches /.well-known/acme-challenge/ before the challenge file can be served. On managed hosting, file a ticket. On cPanel with AutoSSL, check the AutoSSL logs in the panel; the reason is usually one click deep.

"NET::ERR_CERT_COMMON_NAME_INVALID" / wrong domain on the certificate. The browser reached the server, the certificate is valid, but the hostnames in the certificate's SAN list do not include the hostname in the URL bar. The two common causes are (a) the certificate was issued for yoursite.nl only, but the visitor typed www.yoursite.nl, or (b) somebody reissued the certificate and forgot to include one of the hostnames. Reissue the certificate with certbot --nginx -d yoursite.nl -d www.yoursite.nl (or the equivalent for your host) so that both names are covered.

"NET::ERR_CERT_AUTHORITY_INVALID" / unknown or untrusted CA. The certificate chain is broken. This happens when the web server is configured to serve only the leaf certificate and not the intermediate, or when a self-signed certificate slipped onto a production host by accident. Run openssl s_client -servername yoursite.nl -connect yoursite.nl:443 -showcerts and look at the chain. If you see only one certificate, the intermediate is missing. For certbot-managed certificates, use fullchain.pem, not cert.pem, in the web server configuration. For anything else, consult your host's documentation; the fix is specific to the web server.

Auto-renewal silently fails on shared hosting. This is the one that burns people. A host advertises "automatic SSL renewal", the first renewal works, and eighteen months later the certificate expires because AutoSSL has been failing silently for months and the notification email went to an admin account nobody reads. The root causes are almost always the same: DNS changed and the domain no longer resolves to the host that runs AutoSSL; a .htaccess rewrite in WordPress blocks /.well-known/acme-challenge/; an older certificate is still sitting in the panel and AutoSSL refuses to overwrite it. The only defense is a monthly calendar reminder to curl -I https://yoursite.nl/ and visually read the Not After from openssl s_client, or an external uptime monitor like Better Stack or UptimeRobot with a certificate-expiry alert set to 30 days out.

"SSL is installed but the site is still not secure". If the browser shows a broken padlock or "Not Secure" even though the certificate is valid and dated correctly, you are looking at mixed content: an HTTPS page that loads an HTTP subresource (an image, a script, a stylesheet). The certificate is fine; some of the URLs inside your pages still point to http://. The full fix is in mixed content in WordPress.

Three SSL misconceptions worth burning

"Free SSL is less secure than paid SSL." False at the cryptographic level, and the source is a paid CA. GlobalSign concedes outright that both tiers provide identical encryption. What you buy with a paid certificate is a deeper identity check, a warranty in the five-to-seven-figure range, technical support, and historically a longer validity period (a gap that is closing as CA/B Forum mandates shorten certificate lifetimes for every CA). Encryption strength is not on that list. For the vast majority of WordPress sites, a free Let's Encrypt DV certificate and a paid DV certificate provide the same protection for visitors, and the free one is easier to keep renewed.

"The padlock means the site is safe." The padlock means the transport is encrypted and the server on the other end proved it controls the domain. It says nothing about whether the site is run by someone trustworthy, whether the application on the server is secure, or whether your data will be handled responsibly after it arrives. Phishing sites routinely use free DV certificates. The padlock is not a trust signal; it is a privacy signal. A WordPress site with SSL and an outdated plugin is still compromised in the first week of its next CVE. For the full control set, see WordPress security hardening.

"SSL auto-renews automatically." It renews automatically when the renewal infrastructure is healthy, and it fails silently when the infrastructure breaks. On a self-hosted VPS with certbot and a working cron, auto-renewal is genuinely reliable. On shared hosting with AutoSSL, it is a best-effort process that depends on DNS, .htaccess, and the host actively looking at its logs. The only thing that makes auto-renewal truly automatic is a monitor that tells you, out-of-band, when it stops working.

One consequence of a missing or misconfigured SSL certificate that surprises store owners: WooCommerce payment gateways silently hide themselves from the checkout page when SSL is not active. If a payment gateway has disappeared after a certificate change or expiry, see the WooCommerce payment gateway not showing guide.

When to escalate

Call your host or a specialist when any of the following is true. Collect the list below first; every minute they save on context is a minute closer to the site being back.

• The browser shows a certificate error and a self-test with openssl s_client confirms the certificate is expired, wrong-domain, or untrusted, and a renewal attempt either fails or does not fix the error.
• The certificate is valid but browsers still display "Not Secure" after you have already fixed mixed content.
• You depend on AutoSSL on shared hosting and the panel reports a renewal failure you cannot resolve in one pass.
• You see a certificate mismatch between yoursite.nl and www.yoursite.nl and cannot fix it yourself.

Collect before you ask:

• The exact browser error string (screenshot is fine).
• Your WordPress version and whether the two URLs in wp-admin > Settings > General start with https://.
• The Site Health status from wp-admin > Tools > Site Health (screenshot the HTTPS-related items).
• The host and the control panel (cPanel, Plesk, custom), and whether you have SSH access.
• The last time the certificate is known to have renewed successfully, if you have that date.
• Whether Cloudflare or another reverse proxy sits in front of the site, and in which SSL mode (Flexible, Full, Full Strict).
• If you have SSH access: the output of curl -vI https://yoursite.nl/ 2>&1 | head -60 and echo | openssl s_client -servername yoursite.nl -connect yoursite.nl:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates -ext subjectAltName.

If your certificate situation is fine but your WordPress URLs still refuse to flip to HTTPS, the next stop is how to force WordPress to HTTPS. If the padlock is broken and the certificate itself is healthy, the next stop is mixed content in WordPress. And if you are thinking about SSL as one layer in a broader defense, the pillar is WordPress security hardening.