How to Enable HTTPS on WordPress with a Custom SSL Certificate and Private Key

To enable SSL on WordPress with your own certificate, install the certificate, matching private key, and any required intermediate chain on the server, proxy, load balancer, or hosting panel that terminates TLS. WordPress itself does not upload or activate certificates. After the HTTPS endpoint works, change WordPress Address and Site Address to the canonical https:// URL, configure reverse-proxy headers if TLS ends elsewhere, and then force secure administration.

Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.

What enabling SSL on WordPress actually involves

“SSL” is commonly used as shorthand for modern TLS. The certificate proves the identity of your public hostname, while the private key lets the TLS terminator establish encrypted sessions. The web server or proxy presents that certificate before WordPress handles the request.

#	Preview	Product	Price
1		SSL/TLS Under Lock and Key: A Guide to Understanding SSL/TLS Cryptography	$15.39	Buy on Amazon
2		SSL Certificates HOWTO	$14.99	Buy on Amazon
3		The SSL/TLS Handbook: Encryption, Certificates, and Secure Protocols	$9.99	Buy on Amazon
4		Implementing SSL / TLS Using Cryptography and PKI	$22.83	Buy on Amazon
5		OPENSSL 3.0 MASTERY: PRACTICAL CRYPTOGRAPHY, PKI & TLS/SSL SECURITY: HANDS-ON CERTIFICATE...	$8.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

WordPress is HTTPS-compatible when a TLS certificate is installed and available to the web server. It does not provide a certificate-upload screen, store a private key in the Media Library, or terminate TLS from a plugin. The certificate and key belong on the component listening for HTTPS traffic on port 443: Apache, Nginx, a load balancer, a CDN or reverse proxy, or a managed hosting control panel.

There are therefore two separate jobs:

• Terminate TLS correctly: install the certificate, matching key, and chain on the public HTTPS endpoint.
• Tell WordPress its canonical origin is HTTPS: update both URL settings and, where appropriate, force administrator sessions over HTTPS.

Doing only the second job can create redirect loops when the backend still sees HTTP. Doing only the first can leave WordPress generating HTTP links, cookies, redirects, or administrator URLs.

#1 Best Overall

Sale

SSL/TLS Under Lock and Key: A Guide to Understanding SSL/TLS Cryptography

$15.39

Buy on Amazon

Identify where HTTPS terminates before touching WordPress

Start by tracing the request path for your public hostname. A browser may connect to a proxy or load balancer while PHP and WordPress run on a private HTTP-only server. Uploading the key to the wrong machine either has no effect or creates an unnecessary security exposure.

Deployment possibilities

Confirm the exact public hostname or hostnames covered by the certificate. Obtain the intermediate certificates supplied by the issuer; a server certificate without its required chain can appear valid to one browser and untrusted to another.

Prepare and protect the certificate, key, and chain

Confirm the certificate is appropriate

• The certificate’s subject or subject-alternative names must include the public hostname visitors use, such as example.com and, if needed, www.example.com.
• Check its validity dates and intended server-authentication use before installation.
• Keep the private key in the format accepted by your TLS terminator. Do not convert or edit it in a text editor unless you understand the format and preserve the PEM boundaries.
• Keep the intermediate chain available. Many servers expect a full-chain file rather than only the leaf certificate.

Verify that the key matches

The certificate and private key are a pair. A mismatch causes the TLS service to reject its configuration or serve a different certificate than expected. Your hosting provider may offer a match check. On a shell-managed server, an administrator can compare the public-key or modulus output from the certificate and key with an OpenSSL check appropriate to the certificate type. Run such checks on the server, never by uploading the private key to a web utility.

Store the private key as a secret

• Place certificate and key files outside the web document root so a misconfigured static-file handler cannot publish them.
• Allow only the TLS service account and authorized administrators to read the key. The exact owner and permission mode depend on the operating system and service setup.
• Do not paste the private key into a WordPress page, Media Library item, ticket, chat, theme file, or plugin setting.
• Keep an encrypted administrative backup if your renewal and disaster-recovery process requires one, and remove temporary copies after installation.

Install a custom certificate on Apache

For a self-managed Apache server, place the files in a protected directory and reference them from the HTTPS virtual host. The essential directives are SSLCertificateFile and SSLCertificateKeyFile.

<VirtualHost *:443>
    ServerName example.com
    SSLEngine On
    SSLCertificateFile /etc/apache2/ssl/example.crt
    SSLCertificateKeyFile /etc/apache2/ssl/example.key
    DocumentRoot /var/www/example
</VirtualHost>

Use the chain directive or bundled-chain arrangement required by your Apache version and operating-system package. Some installations expect the intermediate certificate to be appended to the certificate file; others use a separate chain directive. Follow the layout supported by that installation rather than copying a directive from an unrelated distribution.

1. Save the certificate, key, and chain in the protected locations selected during your inventory.
2. Edit the port-443 virtual host for the exact public hostname. Make sure it points to the WordPress document root and does not accidentally select a default site.
3. Run Apache’s configuration-test command for your operating system, such as the command supplied by its service package. Treat any syntax, file-permission, or key-mismatch error as a deployment failure; do not reload a configuration that has not passed validation.
4. Reload Apache using your operating system’s service manager. A reload normally preserves existing connections while applying the new virtual-host configuration, but the exact command varies.
5. From an external connection, open the public HTTPS hostname and inspect the certificate, hostname, expiry, and chain. Confirm that the intended virtual host, not a default certificate, answers.

Install a custom certificate on Nginx

For Nginx, configure the certificate and key in the server block that listens on port 443. The equivalent directives are ssl_certificate and ssl_certificate_key.

Rank #2

SSL Certificates HOWTO

$14.99

Buy on Amazon

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/nginx/ssl/example-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/example.key;
    root /var/www/example;
    index index.php index.html;
}

Use a full-chain certificate file when your Nginx package expects the leaf certificate followed by the intermediate chain. Keep the key separate and protected. If another Nginx block claims the same hostname, remove the ambiguity or ensure the intended block is selected.

1. Install the files with ownership and permissions that let Nginx read the key without making it world-readable.
2. Place the directives in the correct 443 server block and verify that the hostname and WordPress root are correct.
3. Run the Nginx configuration test supplied by your installation before reloading. Resolve syntax errors, missing files, and key mismatches first.
4. Reload Nginx through the service manager, then test the public hostname from outside the server.

Use a managed host or proxy certificate interface

If a hosting panel, load balancer, or proxy terminates TLS, upload the custom certificate, private key, and intermediate certificate in that system’s SSL interface. Bind the certificate to the exact hostname that receives traffic. A successful upload is not proof that the correct endpoint is serving it: check the public hostname after activation.

Before committing to a managed option, verify these capabilities:

• Customer-supplied certificate and private-key uploads rather than provider-only certificates.
• Separate or bundled intermediate-chain support.
• Visibility into the hostname and protocol headers sent to the WordPress origin.
• A configuration-test or validation result before activation.
• Access to the previous certificate and a documented renewal and rollback process.

Change WordPress to its HTTPS URLs

Use the dashboard when it remains reachable

1. Sign in to Settings → General.
2. Change WordPress Address (URL) to the canonical HTTPS origin, for example https://example.com.
3. Change Site Address (URL) to the same canonical origin.
4. Use https://, match the hostname visitors should use, and omit the trailing slash.
5. Save the changes, sign in again if prompted, and test a front-end page and the login URL.

WP_SITEURL identifies where the WordPress core files are located. WP_HOME is the public address visitors use. They are often identical, but a deliberately separate core location can make them different.

Use wp-config.php when the dashboard is locked out

Make a backup of wp-config.php, then add the constants before the line that says WordPress has finished editing the file:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Both values must include the scheme and omit the final slash. While these constants remain in the file, they override the stored home and siteurl options. Removing them later exposes the old database values again, so update the database deliberately if you plan to remove the constants.

Rank #3

The SSL/TLS Handbook: Encryption, Certificates, and Secure Protocols

$9.99

Buy on Amazon

Force secure administrator sessions only after HTTPS works

Once the HTTPS virtual host responds correctly, add this constant to wp-config.php:

define( 'FORCE_SSL_ADMIN', true );

This forces logins and administration sessions over HTTPS. It belongs in wp-config.php, not only in a plugin, and it assumes the server SSL configuration and secure virtual host already work. The older FORCE_SSL_LOGIN setting is deprecated and should not be used for a new configuration.

Enable this switch only after testing an administrator login through the public HTTPS hostname. If WordPress receives an HTTP request from an unaware backend while this switch is active, it can redirect repeatedly.

Configure WordPress behind a reverse proxy

A reverse proxy commonly terminates TLS and forwards ordinary HTTP to Apache or PHP. In that design, the browser used HTTPS but the backend connection did not. The proxy must preserve the original host and protocol, and WordPress must translate the trusted forwarded protocol into its HTTPS detection.

Forward the original request information

A representative Nginx proxy location is:

location / {
    proxy_pass http://wordpress_backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_redirect off;
}

Adapt the upstream name and header policy to your infrastructure. The important information is the public host and whether the client connection to the proxy used HTTPS.

Tell WordPress when the trusted proxy saw HTTPS

Place the documented pattern in wp-config.php before WordPress loads:

Rank #4

Sale

Implementing SSL / TLS Using Cryptography and PKI

$22.83

Buy on Amazon

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Trust this header only when it is added or sanitized by a proxy you control. If clients can send it directly to the origin, they can spoof the value and alter WordPress’s security decisions.

Correct the host when the proxy substitutes one

Some proxies send an internal backend hostname in the ordinary Host header. If that happens, use the validated HTTP_X_FORWARDED_HOST or the appropriate server-name value to restore the public host before WordPress builds URLs. The exact assignment depends on which proxy headers your infrastructure guarantees; never copy an unvalidated client header into HTTP_HOST.

Check URLs, redirects, and page assets

After the server and WordPress settings are changed, test an ordinary visitor journey instead of checking only the home page.

1. Open the HTTPS home page in a private browser window.
2. Open a representative post, a media attachment, a stylesheet-dependent page, the login page, and wp-admin.
3. Visit the old HTTP URL and verify that it redirects once to the canonical HTTPS URL, not through a chain of alternating hosts or schemes.
4. Inspect the certificate hostname, validity period, and chain in the browser’s security panel.
5. Check the page for mixed content: scripts, styles, images, fonts, AJAX endpoints, embeds, and API calls must not continue loading from http://.
6. Log out and back in to confirm that authentication cookies and administrator redirects remain on HTTPS.

Changing the two URL settings does not rewrite every absolute URL stored in posts, widgets, theme options, plugin settings, or serialized metadata. A page that loads over HTTPS can therefore still have a broken layout or blocked scripts.

Back up the database before replacing old URLs. Use a WordPress-aware serialized-data tool or a plugin designed to update serialized values. Do not run a blind SQL string replacement across every table: serialized lengths can become invalid and break settings or content.

Troubleshoot the failure that matches your symptom

The browser reports a certificate warning

• Hostname mismatch: the certificate does not include the exact public hostname, including a possible www variant.
• Untrusted chain: the intermediate certificate is missing or installed in the wrong order.
• Expired certificate: replace it and reload the TLS terminator before changing WordPress URLs.
• Wrong certificate: another virtual host, proxy binding, or default server is answering the request.

The site enters an HTTP-to-HTTPS redirect loop

First determine whether TLS ends at a proxy. If the proxy forwards HTTP and does not send a trustworthy X-Forwarded-Proto, WordPress may believe every HTTPS request is HTTP. Configure the proxy header and the guarded $_SERVER['HTTPS'] pattern, then test again. Also check that multiple layers are not each rewriting the scheme in opposite ways.

Best Value

Sale

OPENSSL 3.0 MASTERY: PRACTICAL CRYPTOGRAPHY, PKI & TLS/SSL SECURITY: HANDS-ON CERTIFICATE MANAGEMENT, NETWORK ENCRYPTION, COMMAND-LINE RECIPES & DEVOPS AUTOMATION

$8.99

Buy on Amazon

Only the administrator area loops

Review FORCE_SSL_ADMIN and the reverse-proxy protocol detection. Temporarily remove the constant through a controlled server-side edit if it prevents access, fix the proxy or virtual-host configuration, and re-enable it only after a direct HTTPS login succeeds.

The page is unstyled or scripts are blocked

This is usually mixed content: stored absolute HTTP URLs remain in content or configuration. Identify the specific resource in browser developer tools, back up the database, and update serialized data with a WordPress-aware method. Also inspect theme and plugin fields that construct URLs dynamically.

The key will not load

Check that the key path is correct, the TLS service account can read it, the file is intact, and it matches the certificate. A password-protected key may require an installation-specific secret-handling method. Do not weaken file permissions or place the key in the document root to make the error disappear.

WordPress uses an internal hostname

Inspect the proxy’s Host and X-Forwarded-Host behavior. Set the public host from a value guaranteed by your own proxy, then retest generated links, canonical redirects, password-reset URLs, and administrator navigation.

Renewal, monitoring, and rollback

Plan renewal before expiry

Record where the certificate, key, and chain are installed, who can replace them, which hostname binding is required, and which configuration-test and reload steps apply. During renewal, install the replacement alongside the current files when possible, validate it, reload the terminator, and check the public certificate from an external connection.

Keep a safe rollback point

• Back up the prior TLS configuration and the current certificate metadata, but protect private-key backups as secrets.
• Keep a copy of the original wp-config.php and database backup before URL changes.
• Know how to reach the server or hosting panel without relying on the WordPress dashboard.
• If a URL change locks out the dashboard, use the server-side constants or restore the previous values while fixing the underlying TLS or proxy issue.

Monitor the complete path

Certificate expiry monitoring should check the public hostname and chain, not merely the presence of a file on an origin server. A proxy can expire or replace the public certificate while the backend files remain unchanged. Periodically test redirects, login, representative content, and renewal notifications.

Quick Recap

SaleBestseller No. 1

SSL/TLS Under Lock and Key: A Guide to Understanding SSL/TLS Cryptography

$15.39

Bestseller No. 2

SSL Certificates HOWTO

$14.99

Bestseller No. 3

The SSL/TLS Handbook: Encryption, Certificates, and Secure Protocols

$9.99

SaleBestseller No. 4

Implementing SSL / TLS Using Cryptography and PKI

$22.83

SaleBestseller No. 5

OPENSSL 3.0 MASTERY: PRACTICAL CRYPTOGRAPHY, PKI & TLS/SSL SECURITY: HANDS-ON CERTIFICATE MANAGEMENT, NETWORK ENCRYPTION, COMMAND-LINE RECIPES & DEVOPS AUTOMATION

$8.99

Choose an implementation using these decision points

Completion checklist

• The certificate includes every public hostname users will access.
• The private key matches the certificate and remains outside the public document root.
• The intermediate chain is installed in the format expected by the TLS terminator.
• The intended Apache, Nginx, proxy, load balancer, or panel endpoint serves the certificate on HTTPS.
• The TLS service configuration passes its validation test before reload.
• WordPress Address and Site Address use the same canonical HTTPS origin without a trailing slash, unless a deliberate core-location design requires otherwise.
• FORCE_SSL_ADMIN is enabled only after HTTPS and proxy detection work.
• Trusted proxy headers preserve the original host and protocol, and untrusted client values are rejected.
• HTTP redirects once to HTTPS, login and administration stay secure, and representative pages have no mixed content.
• Database, configuration, renewal, and rollback procedures are documented.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.