This tutorial walks you through copying your Web Linguist SSL certificate into your WP Engine site's Custom SSL configuration. The process takes about two minutes. You'll need to repeat it every ~60 days when your certificate renews — we'll email you each time.

Not sure why you're doing this or what it actually changes? Read our explanation of how SSL works with managed hosting providers first — this tutorial assumes you've decided to upload the certificate and just want the steps.

Before you start

Make sure your DNS records are fully verified in your Web Linguist dashboard — every record should show a green check mark. If any row is still red or pending, the certificate hasn't been issued yet and the next step won't work.

Step 1 — Find your certificate in the Web Linguist dashboard

  1. Log in to your Web Linguist dashboard.
  2. Open the website whose certificate you want to upload.
  3. Go to the Installation tab.
  4. Scroll down past the DNS records section. You'll see a collapsible section labelled SSL Certificate with an Action needed badge.
  5. Click Show on the right side of that section to expand it.

You'll now see two boxes: Certificate (full chain) and Private Key, along with the certificate's issue date and expiration date.

Step 2 — Copy the certificate

  1. Next to the Certificate (full chain) box, click the Copy button. You should see a brief "Copied!" confirmation.
  2. Keep the dashboard tab open — you'll come back to it.

Step 3 — Paste the certificate into WP Engine

  1. In a new browser tab, log in to the WP Engine User Portal.
  2. Click the environment for the site you want to update.
  3. Click Manage.
  4. Click SSL in the left sidebar.
  5. Click Add Certificate.
  6. Choose Import Certificate.
  7. Paste the certificate you just copied into the Certificate field.
  8. Don't submit yet — you still need the private key.

Step 4 — Copy and paste the private key

  1. Switch back to your Web Linguist dashboard tab.
  2. In the Private Key box, click Show to reveal it (hidden by default so it doesn't appear on-screen unnecessarily).
  3. Click the Copy button next to the private key.
  4. Switch back to the WP Engine tab and paste it into the Private Key field.
  5. Submit the form.

WP Engine will validate that the certificate and private key match, then activate the custom SSL on your site. This usually takes a few seconds.

Step 5 — Mark it as uploaded in your dashboard

  1. Return to your Web Linguist dashboard.
  2. In the SSL Certificate section, tick the checkbox labelled I have uploaded these to my hosting provider.

The badge in the section header will change from Action needed to Uploaded. This is just a confirmation for your own tracking — we use it to know whether to remind you the next time your certificate renews.

That's it — what to expect from here

WP Engine is now serving your certificate. Their renewal-failure emails will stop within a day or two, and their internal monitoring will show your SSL as valid.

About every 60 days we'll automatically issue a fresh certificate (Let's Encrypt certificates are valid for 90 days, so we renew with about a month to spare). When that happens:

  • We'll send you an email letting you know the certificate has been renewed.
  • Your dashboard's SSL section will show Action needed again.
  • You'll repeat Steps 1–5 above with the new certificate values.

The new certificate will be valid the moment we issue it (your visitors are unaffected), so there's no urgency on the upload — you have the full ~90-day window to get to it.

Something went wrong?

If WP Engine rejects the certificate or key with an error like "Key is not in PEM format" or "Certificate and key do not match," double-check that you copied the entire contents of each box (including the -----BEGIN…----- and -----END…----- lines). If you're still stuck, reach out to our support team with a copy of WP Engine's exact error message and we'll help you sort it out.

If you're on a managed hosting provider like WPEngine, Kinsta, Flywheel, or Pagely and you've installed Web Linguist using the DNS method, you may have received an email from your host saying it "couldn't renew your SSL certificate." This article explains what's actually happening behind the scenes, why we recommend uploading our certificate to your hosting provider, and — importantly — what does and doesn't break if you choose not to.

This is the informational version. If you just want to know how to upload the certificate, see our step-by-step tutorial.

How a visitor's request actually reaches your site

When someone visits your translated site, their request travels through more places than you might expect. Each hop in the chain establishes its own secure (HTTPS) connection.

  Visitor  →  Cloudflare  →  Web Linguist Reverse Proxy 
   →  Your Hosting Provider

That means there are actually three SSL certificates involved end-to-end, each managed by a different party:

Connection hop Who manages the SSL certificate
Visitor → Cloudflare Cloudflare (their automatic edge certificate)
Cloudflare → Web Linguist Reverse Proxy Web Linguist (us)
Web Linguist Reverse Proxy → Your hosting provider Your hosting provider (WPEngine, Kinsta, etc.)

The certificate that your visitors actually see and trust is the middle one — between Cloudflare and our reverse proxy. That's the one browsers verify when deciding whether to show the green lock icon on your site. We issue and renew that certificate for you automatically every 60 days. You don't need to do anything for that to work; it happens in the background.

So what is the "upload your cert" recommendation about?

It's about the third hop — between our reverse proxy and your hosting provider.

Your hosting provider also serves its own SSL certificate on the connection coming into its servers (including the one from our reverse proxy). This certificate isn't seen by your visitors, but your hosting provider's internal systems still care about it being valid. Before you started using Web Linguist, your host was almost certainly auto-renewing its own certificate using a system called Let's Encrypt.

That renewal automation typically pre-checks DNS to confirm your domain still points at the host's servers. But once you switched to Web Linguist's DNS mode, your domain stopped pointing directly at your host — it points at us. So your host's renewal pre-check fails, and they send you the "we couldn't renew your SSL certificate" email.

Here's the important part: your host can't renew its own certificate anymore, but the certificate your visitors see is the one we manage. Your site continues to be fully secure for visitors regardless.

To stop those notifications and give your host a valid certificate of its own to serve internally, you can upload our SSL certificate into your host's "Custom SSL Certificate" admin panel. Once you do that, the host happily uses our certificate for its internal connection too, and its renewal-failure alerts go quiet.

What happens if you don't upload the certificate?

This is the most common question we get, so let's be specific.

What will keep working

  • ✓ Your site stays online. Your hosting provider will continue to serve your website normally. No downtime.
  • ✓ Your visitors still see the green lock icon. Browsers see our Let's Encrypt certificate — fresh, valid, and trusted by every modern browser — when they visit your site. There is no "Not Secure" warning, and your site will not show as "HTTP" or unencrypted. The public-facing certificate remains secure.
  • ✓ HTTPS continues to work end-to-end. Every hop in the connection chain is encrypted. Your visitors' experience does not change.
  • ✓ We continue to auto-renew our own certificate. The certificate your visitors actually depend on never expires — we handle that every 60 days automatically.

What might be annoying

  • ⚠ Your hosting provider may keep emailing you "SSL renewal failed." Their internal monitoring sees their own certificate expiring and warns you. The warnings are technically accurate (their certificate is expiring) but no longer meaningful — your visitors don't see that certificate anyway.
  • ⚠ Your host's internal dashboard may show your SSL as "expired." Same reason — the host is looking at its own certificate, not the one we serve.
  • ⚠ Some host-side features that depend on a valid local SSL certificate may behave unexpectedly — for example, in-host SSL scanners or certain caching layers that validate certificates before forwarding traffic.

What will not happen

  • ✗ Your host will not stop serving your site.
  • ✗ Your visitors will not see security warnings.
  • ✗ Your site will not show as "HTTP" or "insecure" — the public-facing certificate is from us, and it's always valid.

A note about provider differences

Behavior varies somewhat between managed hosting providers. The vast majority — including WPEngine, Kinsta, Flywheel, and Pagely — will simply send periodic renewal-failure emails but continue serving your site exactly as before. A few less common hosts may be more aggressive about flagging expired certificates or may eventually disable certain optional features that depend on local SSL validation.

If you're on a less common provider, it's worth checking their documentation (or asking their support team) what their behavior is when a custom SSL certificate is uploaded versus when their auto-renewed certificate fails. In all cases we've encountered, uploading our certificate is the cleanest solution: it silences the alarms and lets your host operate normally, while your visitors' experience continues unchanged.

Next step

If you'd like to upload our certificate to your hosting provider, see our step-by-step tutorial here. The process takes about two minutes and only needs to be repeated once every ~60 days when your certificate renews.

Whether you need to switch payment methods, upgrade your plan, or cancel a subscription, Web Linguist makes it straightforward from your account dashboard. This guide walks you through everything, step by step.



Log In and Open Your Subscriptions

  1. Log in to your Web Linguist account at weblinguist.com.
  2. Click your avatar icon in the top-right corner of the navigation bar (the small circle with your initial).
  3. Select “Subscriptions” from the dropdown menu. This takes you to your main Subscriptions page.

 

Your “All Subscriptions” Overview

Once you’re on the Subscriptions page, you’ll get an overview of everything tied to your account.


The All Subscriptions page in Web Linguist, showing the default payment method and upcoming invoices.


Default Payment Method

At the top of the page you’ll find a Default Payment Method section. This is the card that gets used when you first purchase a new subscription through checkout.

Important: Changing your default payment method here does not update the card on any existing subscriptions. Each subscription keeps the payment method it was originally purchased with. To update the card on a specific subscription, you’ll need to open that subscription individually — covered in the next step.

Upcoming Invoices

Further down the page you’ll see a summary of upcoming invoices across all your websites, including the billing date and amount due — a handy snapshot of what’s coming up.



Manage an Individual Subscription


To make changes to a specific website’s subscription — such as updating the payment method, changing your plan, or cancelling — click that website’s name in the tab bar near the top of the Subscriptions page.


The individual subscription page showing the current plan, payment method dropdown, and options to upgrade, downgrade, or cancel.


Changing the Payment Method

On the individual subscription page, you’ll see a Payment Method dropdown on the right side. Use this to choose which card should be charged for that subscription’s future renewals.


Upgrading or Downgrading Your Plan

Click Upgrade Plan or Downgrade Plan and follow the prompts to switch to a different tier. Changes take effect on your next billing cycle.



Step 4 — Cancelling a Subscription

Click the Cancel button on the individual subscription page. You’ll then be asked to choose how you’d like to cancel:

  • Cancel Immediately — Your subscription ends right away and you lose access to that website’s translations immediately.
  • Cancel at End of Billing Period — Your subscription stays active until the current billing period runs out. You won’t be charged again, but you keep full access until then.

 

Quick Recap

  • Log in → click your avatar → select Subscriptions
  • The All Subscriptions page shows your default payment method and upcoming invoices across all sites
  • Changing the default payment method only affects new purchases — not existing subscriptions
  • Click a website name in the top tab bar to manage that specific subscription
  • From there you can update the payment method, change your plan, or cancel
  • When cancelling, choose between immediate access loss or cancelling at the end of your billing period

Still have questions? Reach out to the Web Linguist support team and we’ll be happy to help.

Using WebLinguist with WP Engine: Required Configuration & Why It Matters

If your website is hosted on WP Engine and you’ve chosen the Full Domain (Subdirectory) DNS setup, there are a few additional configuration steps required to make everything work correctly. This guide explains what those steps are, why each one is necessary, and exactly how to get them done.

This is not a limitation of WebLinguist — it’s a consequence of how WP Engine’s infrastructure is architected, and it affects all reverse proxy services that sit in front of WP Engine sites, not just ours.

Why WP Engine Requires Special Handling


WP Engine is not a standard web host. Their platform runs on top of Cloudflare’s enterprise network, which continuously monitors and validates that your domain’s DNS is pointing to WP Engine’s own infrastructure. When you point your domain to WebLinguist’s proxy instead, WP Engine’s Cloudflare layer detects the DNS change and can deactivate hosting for your domain — producing a Cloudflare Error 1001 and taking your site offline.

The solution is to configure WebLinguist’s proxy to fetch your site content directly from WP Engine’s backend install URL (yoursite.wpengine.com) rather than routing back through WP Engine’s public Cloudflare edge. This bypasses the validation layer entirely and goes straight to your WordPress installation on WP Engine’s servers.

There are then two additional nginx-level rules that need to be added to your WP Engine environment to ensure visitor IP addresses are handled correctly and that WordPress generates correct URLs when content passes through our proxy. Both are standard, documented configurations that WP Engine’s support team handles routinely.

Let’s go through each one.

Step 1: Enter Your WP Engine Install URL as Your Origin During Setup


What it is


During WebLinguist’s DNS setup wizard, you are asked to provide your origin URL — the address our proxy uses to fetch your original site content on the backend. This value is stored in your WebLinguist account and never exposed publicly.

For most standard hosting environments (plain VPS, shared hosting), this is simply your current server IP address or hosting domain. For WP Engine, this value must be your WP Engine install URL — the direct backend address of your WordPress installation.


Why it’s needed


Your domain’s DNS record points to WP Engine’s public Cloudflare IPs (141.193.213.10 / 141.193.213.11 for Advanced Network, or their CNAME wp.wpenginepowered.com). If WebLinguist’s proxy fetches content from those addresses, it hits WP Engine’s Cloudflare edge network — which expects your domain to be registered as a custom hostname in their system. Since you’ve moved DNS away from their infrastructure, your domain is no longer registered there, and the request fails.

By entering your WP Engine install URL as the origin, our proxy connects directly to your WordPress installation on WP Engine’s servers — completely bypassing the Cloudflare validation layer.


How to find your WP Engine install URL


Your install URL follows this format:

yourinstallname.wpengine.com

You can find your exact install name in the WP Engine User Portal:

  1. Log in to your WP Engine dashboard at my.wpengine.com
  2. Click on Sites in the left navigation
  3. Click on the environment name for your website
  4. Your install name is displayed at the top of the environment overview page — it’s also visible in the URL of your dashboard page

Your full install URL will be: [installname].wpengine.com


Where to enter it


When the WebLinguist setup wizard asks for your origin URL, enter your WP Engine install URL instead of your current domain or IP address:

yourinstallname.wpengine.com

If you have already completed setup and entered the wrong origin value, you can update it from your WebLinguist dashboard under Settings → DNS Setup → Origin URL. No DNS changes are required — this is purely a backend configuration update on our side.


Step 2: Add the Real IP Header Rule to Your WP Engine Environment


What it is


An nginx configuration rule that tells WP Engine’s server to read the real visitor’s IP address from the request headers sent by WebLinguist’s proxy, rather than treating WebLinguist’s server as the visitor.

The rule looks like this:

real_ip_header X-Forwarded-For;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

Why it’s needed


When traffic reaches WP Engine through WebLinguist’s proxy, every request appears to WP Engine’s server as coming from a single IP address — our proxy server’s IP. Without this rule, WP Engine’s nginx has no way of knowing the actual IP address of the visitor who made the original request.

This matters for several reasons:

IP-based access rules stop working correctly. If you have Web Rules in your WP Engine dashboard that block specific IP addresses, allow only certain IPs to access wp-admin, or restrict access by country — all of those rules would be applied against WebLinguist’s proxy IP rather than the real visitor’s IP. An IP block you set up to stop a bad actor would have no effect. A restriction on wp-admin access would potentially block all visitors, or none of the ones you intended.

Country-based rules stop working correctly. Any Web Rules using country conditions would see your proxy server’s country (wherever our infrastructure is located) rather than the visitor’s actual country. A rule allowing only US traffic would block all visitors, because every request appears to come from our data center.

WP Engine’s logging and analytics become inaccurate. WP Engine’s access logs would show our proxy IP for every request rather than real visitor IPs, making traffic analysis, security auditing, and support troubleshooting much harder.

WordPress itself may behave incorrectly. Some WordPress plugins use the visitor IP for rate limiting, spam detection, personalization, or security purposes. Without the real IP being passed through correctly, those plugins operate on the wrong data.


Why the rule uses Cloudflare’s IP ranges


WebLinguist’s proxy infrastructure sits behind Cloudflare’s network (the orange cloud). This means that when our proxy makes a request to your WP Engine origin, the connection appears to come from one of Cloudflare’s IP addresses rather than our own server’s IP. The IP ranges listed in the rule above are Cloudflare’s complete published IP ranges — both IPv4 and IPv6. By telling WP Engine to trust those ranges and read the X-Forwarded-For header from them, WP Engine correctly identifies the real end visitor’s IP for every request.

This also means your actual server IP is never exposed in this configuration — which is the correct and intended behavior.


How to get this rule added


This rule cannot be added through WP Engine’s Web Rules dashboard — it requires a direct nginx configuration change. You will need to contact WP Engine’s support team and ask them to add it.

How to contact WP Engine support:

  1. Log in to your WP Engine dashboard at my.wpengine.com
  2. Click the Help icon or navigate to the support chat from any page in your dashboard
  3. WP Engine offers 24/7 live chat support — this is the fastest path

What to say to WP Engine support:

You can copy and paste the following message:

“I’m using a reverse proxy service in front of my WP Engine environment. I need the following nginx rule added to my environment [your install name] so that the real visitor IP is correctly read from the X-Forwarded-For header rather than the proxy IP. This is a standard reverse proxy configuration per WP Engine’s own documentation.”

real_ip_header X-Forwarded-For;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

This is a well-documented, routine request. WP Engine’s support team handles this type of configuration regularly and will typically complete it within one business day, often much faster via live chat.


Step 3: Add the X-Forwarded-Proto Header Rule


What it is


A second nginx rule that tells WP Engine’s server that the original request arrived over HTTPS, even though the connection between WebLinguist’s proxy and WP Engine’s origin may be perceived differently at the server level.

This is typically handled by WP Engine automatically for sites on the Advanced Network, but if you encounter any of the symptoms described below after setup, adding this rule resolves them.

The rule:

proxy_set_header X-Forwarded-Proto https;

Or as a Web Rule in your WP Engine dashboard, you can set a response header:

X-Forwarded-Proto: https

Why it’s needed


WordPress stores your site’s URL in its database and uses it to generate all internal links, asset URLs, and redirects. If WordPress believes the incoming request arrived over HTTP rather than HTTPS — even for a moment — it can generate links with http:// instead of https://, trigger redirect loops as it tries to enforce its own HTTPS settings, or produce mixed-content warnings in browsers.

When traffic passes through a proxy chain, the original protocol information (HTTPS) can get lost or misrepresented by the time the request reaches WP Engine’s origin server. This header explicitly preserves that information.


Symptoms that indicate you need this rule


  • Your site is redirecting visitors in an infinite loop after setup
  • Pages load but images, CSS, or JavaScript appear broken (mixed content errors in browser console)
  • WordPress is generating http:// links instead of https:// links on translated pages
  • The browser shows a “Not Secure” warning even though your domain has a valid SSL certificate

If you experience any of these after completing your WebLinguist DNS setup, contact WP Engine support and request the rule above be added to your environment alongside the real IP rule from Step 2.


Step 4 (Optional): Verify Your Web Rules Still Work Correctly


Once the nginx rules from Steps 2 and 3 are in place, any existing Web Rules you have configured in your WP Engine dashboard should function correctly again. However, it’s worth a quick verification pass — particularly for any rules that use IP address or country conditions.

To verify:

  1. Log in to your WP Engine dashboard
  2. Navigate to your environment and click Web Rules in the left navigation
  3. Review any active Access Rules that use IP address or country conditions
  4. Test those conditions by accessing your site from the expected IP or location and confirming the rule behaves as intended

If a rule is not behaving as expected after the nginx changes are in place, contact WP Engine support referencing the real IP header configuration and ask them to confirm it was applied correctly to your environment.


Summary: Complete WP Engine Configuration Checklist


Step Action Where Required?
1 Enter yourinstallname.wpengine.com as your origin URL WebLinguist setup wizard (or dashboard Settings) ✅ Always required
2 Add real_ip_header + set_real_ip_from nginx rule WP Engine support (live chat) ✅ Always required
3 Add X-Forwarded-Proto: https rule WP Engine support or Web Rules ⚠️ Required if HTTPS/redirect issues occur
4 Verify existing Web Rules behave correctly WP Engine dashboard ✅ Recommended

What About the Subdomain Setup?


If you chose the Subdomain DNS setup instead of the Full Domain setup, none of the above steps are required. Because the subdomain approach leaves your root domain record pointing directly at WP Engine’s infrastructure, WP Engine’s Cloudflare validation never detects a DNS change. Their platform continues to operate exactly as it did before. WebLinguist’s proxy only handles traffic to the language-specific subdomains you’ve set up, and WP Engine’s origin is fetched directly without any special configuration.

The steps in this guide apply only to the Full Domain (Subdirectory) setup.


Still Having Trouble?


If you’ve completed the steps above and are still experiencing issues, here are the most common culprits:

Error 1001 is still appearing — Double-check that your origin URL in WebLinguist is set to your WP Engine install URL (e.g., yourinstallname.wpengine.com) and not your old A record value or WP Engine’s public Cloudflare IPs. You can verify and update this from your WebLinguist dashboard under Settings → DNS Setup → Origin URL. Also confirm that DNS propagation has completed — changes can take up to 24 hours to fully propagate, though most providers update within a few minutes.

Site loads but wp-admin is inaccessible — This is typically an IP access rule in WP Engine’s Web Rules that is now matching against WebLinguist’s proxy IP rather than your IP. Confirm with WP Engine support that the real_ip_header rule has been applied, then check your Web Rules for any access restrictions on /wp-admin/ or /wp-login.php/.

Images or styles are missing — This usually indicates an HTTPS/mixed content issue. Add the X-Forwarded-Proto: https rule from Step 3 and clear all caches in both WP Engine’s dashboard and your browser.

WP Engine dashboard shows an SSL warning about your domain — This is expected. Because your domain’s DNS now points to WebLinguist’s proxy rather than WP Engine’s infrastructure, WP Engine’s dashboard will flag your domain’s SSL as unmanaged on their side. This is correct — your domain’s SSL is now managed by WebLinguist’s Cloudflare layer. Your site visitors see a valid, secure HTTPS connection. The warning in WP Engine’s dashboard can be safely disregarded.

If you’ve worked through all of the above and are still stuck, reach out to our support team via live chat in your WebLinguist dashboard and we’ll work through it with you directly.