How do I get .app TLD to work with my .htaccess

Question

I have a number of domains hosted on one server. I tried them as sub-domains but that was a failure. So I obtained new certificates and I have them configured as Add-On_Domains.

They are all using the same template for .htaccess and are configured identically in cpanel. They are all working, except for .app

I know that Google owns this TLD and it has to be secure. But not all combinations are working. These are not working

https://www.example.app/
http://www.example.app/

They give "COMMON_NAME_INVALID" or similar. But these work

https://example.app/
http://example.app/

This is my complete .htaccess file

RewriteEngine On

RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^www\.example\.app$ [NC]
RewriteRule ^(.*)$ https://example.app/$1 [R=301,L]

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^(www\.)?example\.app$ [NC]
RewriteRule ^(.*)$ https://example.app%{REQUEST_URI} [R=301,L,QSA]

# stop it being rooted from .software
RewriteCond %{HTTP_HOST} !^example\.app$ [NC]
RewriteRule ^ - [F]

#Force hmtl extn
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html

Header always set Content-Security-Policy "upgrade-insecure-requests;"
Header append X-Frame-Options: "SAMEORIGIN"
Header append X-Content-Type-Options: "nosniff"

# 1 month
<filesMatch ".(ico|jpg|jpeg|png|gif|mp4|avi|mov|svg)$">
 Header set Cache-Control "max-age=2592000, must-revalidate"
</filesMatch>
# 2 days
<filesMatch ".(js)$">
 Header set Cache-Control "max-age=172800, must-revalidate"
</filesMatch>
# 5 mins
<filesMatch ".(css|html|shtml)$">
 Header set Cache-Control "max-age=120, must-revalidate"
</filesMatch>
# never
<filesMatch ".(rar|zip)$">
 Header set Cache-Control "no-cache, must-revalidate"
</filesMatch>

# compress css and javascript for now
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/opentype

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_include mime ^text/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_include handler ^cgi-script$
</ifModule>

Have I got a typo or is there something else going on ?

https://www.example.app has this trace

Request URL: https://www.example.app/
Referrer Policy: strict-origin-when-cross-origin

Request Headers
Provisional headers are shown
 sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="97", "Chromium";v="97"
sec-ch-ua-mobile: ?1
sec-ch-ua-platform: "Android"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Mobile Safari/537.36

http://www.example.app has this trace

Request URL: http://www.example.app/
Request Method: GET
Status Code: 307 Internal Redirect
Referrer Policy: strict-origin-when-cross-origin

Response Headers
Location: https://www.example.app/
Non-Authoritative-Reason: HSTS

Request Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Mobile Safari/537.36

The above is from Chrome. When Googling it would appear that Chrome is enforcing something for .app domain. However, it doesn't work on Firefox either. And where is the 307 coming from ?

Answer 1

You've basically answered your own question...

I know that Google owns this TLD and it has to be secure.

They give "COMMON_NAME_INVALID" or similar

That's an SSL cert error (in the browser) - nothing to do with .htaccess. The request is not "successfully" reaching your server. .htaccess is not even processed.

Your SSL cert does not appear to cover the www subdomain.

Chrome is enforcing something for .app domain.

Yes, that's why it "has to be secure", it's enforcing HTTPS in the browser before it even sends the request to your server. If the server does not respond correctly on HTTPS then the connection is blocked by the browser.

This is what HSTS preloading is all about. The .app TLD (as well as many other Google TLDs) are included in the HSTS preload list that is compiled into Chrome (and other mainstream browsers).

307 Internal Redirect

It's "internal" to the browser. It's not a conventional (external) redirect. This is really just how Chrome is reporting it. 307s preserve the request method. (But why a 307 "temporary" and not a 308 "permanent"? An HSTS upgrade is effectively permanent.)

Reference:

• https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
• https://hstspreload.org/
• https://serverfault.com/questions/1067229/list-of-top-level-domains-tlds-that-require-https-connections-like-dev