How to disable X-Frame-Options: DENY in LetsEncrypt

I have struggled for days using Wordpress Multisite and a Wordpress theme called “Elementor”. It works great on the main site but not on subdirectory sites due to cross-site scripting errors that point to the X-Frame-Options: DENY setting that is forced by Letsencrypt and results in these errors:

Blocked a frame with origin “https://www.yourwebsite.com” from accessing a cross-origin frame.
Permission denied to access property “elementorFrontend” on cross-origin object

The usual fix for this is to set X-Frame-Options: SAMEORIGIN in the .htaccess file. I tried that and the same errors persisted. I thought it might be the Apache 2 service or the Nginx service because both of them can also have a setting for this issue.

Ultimately, I became aware that LetsEncrypt has that X-Frame-Options: DENY setting to protect all of the sites it encrypts with SSL.

It is a good thing because it prevents “ClickJacking” if not properly setup on a website.

For me it is a big inconvenience because the Elementor theme doesn’t work without the proper X-Frame-Options: SAMEORIGIN setting in a WordPress Multisite situation.

Everything in the Wordpress Multisite environment works as it should when only using HTTP but LetsEncrypt’s best intentions stop some wonderful software from working.

If LetsEncrypt would provide a way to override that setting it would solve a problem that has been vexing users for years.

I can bypass the issue by paying for SSL certificates that don’t use Letsencrypt but that would get expensive very quickly in a multisite environment.

The only other way to make this all work at this time is to not use SSL certificates but then nobody woudl actually trust the sites with all that Chrome has done to force SSL now for every site.

Hi @hostingexpress

why do you want to include Letsencrypt via iFrame in your site?

And what has that to do with creating Letsencrypt certificates?

I don’t understand your setup.

1 Like

Hi,

Let’s Encrypt is a service that provide endpoints which will then allow you to obtain and issue a certificate, it’s not a program that you run locally. So if you think the program you used to obtain certificate added “X-Frame-Option” to your nginx / apache config, please provide us the program / script name.

Thank you

I don’t include LetsEncrypt via iFrame in the site.

It has nothing to do with creating LetsEncrypt certificates.

LetsEncrypt seems to set X-Frame-Options: DENY setting that is forced by Letsencrypt and results in these errors:

If I don’t use LetsEncrypt and simply run HTTP that error does not show up because something in LetsEncrypt is no longer part of the environment. I have replicated this issue on two separate WordPress Multisites with their respective subsites. I use subdirectories instead of subdomains. Let’sEncrypt allows me to assign certificates to alias domain names for each subsite. This is exciting if it would work but that X-Frame-Options issue only shows up when I use the LetsEncrypt certificate. If I use a conventional certificate I can’t SSL protect the alias domain name subsite.

Steven,

I have no idea which program or script adds the “X-Frame-Option” to my nginx / apache config. All I know is that this symptom only appears if I use LetsEncrypt. Read my reply to JuergenAuer. When I use a regular Digital Certificate I don’t have that “X-Frame-Option” issue.

Previous posters have been trying to convey to you that it’s not possible for this to happen. HTTP headers exist at a completely separate layer to SSL/TLS and certificates.

Go grep through your application source code and web server configuration for x-frame-options, and you will identify where the header is coming from. It might even come from a CDN, if you are using one.

3 Likes

Let’s Encrypt certificates are “regular” digital certificates.

1 Like

What does that mean?

Do you have a sample link?

If you include a site via iFrame, you must accept a X-Frame header. But to use a Letsencrypt certificate, it’s not required to include a site via iFrame.

I don’t understand what you want to do.

PS:

Letsencrypt doesn’t know something about alias domains. A certificate has one or more domain names, that’s all.

Sounds like you include the subdomain via iFrame, then you send a wrong header.

Why? If you have a correct certificate, that should work.

Now I have an idea.

If your server sends a http site, no X-Frame-Option is set.
If your server sends a https site, the X-Frame-Option is set to DENY.

Check one of your subdomains via https://check-your-website.server-daten.de/

If it is finished, check “show header”.

Then you see which header is sent via http and https.

That was a great idea. Here is what I did and apparently Wordpress is looking for this but WordPress is not adding this.

grep -R X-Frame-Option
wp-includes/js/wp-auth-check.js: // “X-Frame-Options: DENY” header.
wp-includes/class-wp-customize-manager.php: * Filter the X-Frame-Options and Content-Security-Policy headers to ensure frontend can load in customizer.
wp-includes/class-wp-customize-manager.php: $headers[‘X-Frame-Options’] = ‘SAMEORIGIN’;
wp-includes/functions.php: @header( ‘X-Frame-Options: SAMEORIGIN’ );
.htaccess:Header set X-Frame-Options “ALLOW-FROM https://www.mysubdirectorysite.com/

1 Like

Did you grep the server config as well? My psychic debugging abilities tell me that your webserver has different configurations for the :80 and :443 sections, and X-Frame-Options is somehow involved (perhaps not explicitly, it might be internally translated via some directive). Aside from grepping, diffing the :80 and :443 sections might expose the problem.

It’s not? :face_with_raised_eyebrow:

The last entry from your grep:

Seems to me, your .htaccess actually does set it.

So the standard header is DENY, sometimes Wordpress changes the standard header.

But that doesn’t work.

You see: It’s not a problem of the certificate, it’s a problem of your configuration. So fix it.

JuergenAuer,

thank you for your attention to this matter. After days of going in circles and starting to question my sanity, I found the issue.

This was never a LetsEncrypt issue.

The error only showed up when I was insisting on using the Elementor theme which, apparently, isn’t WordPress Multisite compatible. It is a fantastic theme and toolset but the way their code is written it breaks the rules and definitely was creating the cross-site scripting errors that had me completely convinced it was from LetsEncrypt.

Once I went back to other themes it all settled down.

Now, I can declare that LetsEncrypt is completely compatible with Domain Name Pointers as Alias Domain names being assigned to the core Multisite domain name and being properly interpreted and displayed as the Alias Domain names for that specific subsite if you also install the “WordPress MU Domain Mapping” plugin when installed on Directadmin Control Panel using the NGINX/APACHE configuration.

When setting up Wordpress Multisite this way you can have up to 100 domain names all using LetsEncrypt and all pointing to separate subsites in the Wordpress Multisite environment and all of that on a single web hosting site.

Gerry Bakker

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.