Help for Qualifying for HSTS Preload List


I just went to in order to determine if my domain qualifies for the HSTS Preload List.

The HSTS test tool sent me back the following error message:

Error: Invalid Certificate Chain uses an incomplete or invalid certificate chain. Check out your site at

However, over the past two days, I have already gone to SSL Labs, and each time it reports no problems that I am aware of, and grades me with an “A”.

Being as I am using your service in conjunction with Certbot, I was hoping you can help me resolve this issue, and determine why the HSTS test tool is sending me that error message.

As you can determine from the above, my website can be accessed at:

BTW, assuming that I did it correctly, just a short while ago, I added the following to my httpd.conf template file in MAMP PRO, right before the VirtualHosts section, and after the last “IfModule” section:

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Also, the httpd.conf file does show that the headers module is being loaded.

Thank you kindly.

Okay, I think I might know what is going on here.

I just went back to SSL Labs and checked again.

This time, I did even better than last time, and they gave me an A+.

Furthermore, below my grade and the green graphs, it even says this:

“HTTP Strict Transport Security (HSTS) with long duration deployed on this server.”

That leaves me a little confused, because it sounds as if my domain,, is already on somebody’s HSTS list, even though I never applied for it.

Is it possible that it just happened because I added that code to my httpd.conf template file in MAMP PRO?

But here is what I am thinking regarding the site.

When I went there, I submitted the domain That resulted in their tester sending me this error message:

Status: is not preloaded.

Eligibility: In order for to be elegible for preloading, the errors below must be resolved:

Error: is a subdomain. Please preload instead. (Due to the size of the preload list and the behaviour of cookies across subdomains, we only accept automated preload list submissions of whole registered domains.)

However, when I submit instead, that is when it sends me the aforementioned “Invalid Certificate Chain” error and says that my domain uses an incomplete or invalid certificate chain.

This is leading me to believe that the problem may possibly lie in the fact that you only issued me a certificate for, and not for as well. Of course, I am just guessing here.

But if I am correct, does this mean that I need to run Certbot in the OS X Terminal again, and make a second request for just, without the www? Again, I am just working on a hunch here.

If any of the above is correct, MAMP PRO’s GUI offers the option to point to only one key file, one chain file, and one fullchain file.

If I do have to make a second request via Certbot for a certificate for, will both and be included in the new keys and certificates?

Oh, one other thing . . .

If HSTS is already enabled on my server, why does the SSL Labs report also say the following?:

“HSTS Preloading Not in: Chrome Edge Firefox IE”

Sorry, but I am in my 60s, and a total newbie at all of this AMP and SSL stuff.

Thanks again for your assistance.

***** BIG UPDATE *****

Ha! Please disregard all of the above.

Not only do I now have certificates and a key for both and, but I also figured out the rest, so that my submission was accepted at

I only encountered one problem there, because my httpd.conf redirect points to, and they didn’t like that, so I had to add another RedirectMatch so that it points to first, and then a second RedirectMatch to go from to

Once I did that, I was good to go for the HSTS preload list.

However, the redirects are not working quite the way I want.

I already made the https version of my preferred destination at Google’s Search Console, but all redirects are now going to the https version instead.

Here is the code I am currently using:

For HSTS preload list, we must redirect to first,

and then to after that

RedirectMatch 301 (.*)$1

RedirectMatch 301 (.*)$1

Can I somehow tweak that code so that I and my visitors end up at www.billkochman every time, instead of without the www?

As I said, I am very, very new to all of this stuff. I have made tremendous progress over the past two weeks, but I am still very far from being a pro at it. Basically, I am just puppeting what I see other folks do, or what I find in online docs.

Thanks again for your time. I really appreciate it. :slight_smile:

Bill K.

Yes, you're in charge of what is issued, not Let's Encrypt. If you forgot the base domain the first time, you can't blame Let's Encrypt for that :wink:

1 Like

You can get both and covered in a single certificate by providing multiple -d parameters (e.g. -d -d, in case you haven’t already done so.

Hi @IslandBoy! Welcome to the forums, and I’m glad you’ve got HSTS working properly.

Can I ask what led you to want to implement HSTS preloading as well? Because HSTS preloading involves adding an entry to a list that ships with every copy of a browser, I’m trying to get an idea of what factors lead to the list’s growth over time.


Hello again @schoen . Thank you for your gentle reply. I appreciate it. Yes, I in fact figured out on my own that that is precisely what I had to do, which I did in fact do yesterday. As a result, my submission to the HSTS Preload List was accepted, and I am now waiting to be included on the list.

BTW, in case you didn’t realize it, I was NOT blaming Let’s Encrypt for not issuing me a certificate for both variations of my domain. After re-reading the Certbot instructions, I fully realized that the responsibility fell on me to properly submit my data to Certbot.

While this is not directly related to my Let’s Connect setup, I am wondering if you can offer some suggestions regarding my redirects.

As I stated above, after setting up SSL/TSL properly on my server, after much experimentation, I used a RedirectMatch in MAMP PRO’s httpd.conf file to redirect all http traffic to https instead.

However, in order to qualify for the HSTS Preload List, I had to redirect to, instead of to, because the latter is a subdomain of the former.

What I used above . . .

RedirectMatch 301 (.*)$1

. . . works just fine. In other words, all traffic to is properly redirected to

Furthermore, all requests made to are also automatically redirected to

The only issue is that if a person uses in their web browser, they are redirected to

I want ALL traffic redirected to – or to the corresponding secure page under that address – the reason being that this is the primary, preferred address that I use in the Google Search Console.

I assumed that I have to add a second Redirect, or possibly RedirectMatch, to the one I have already noted above, but I can’t seem to get it right; and – as Apache even notes on their website – priority is being given to the first RedirectMatch.

So, what should I add to the RedirectMatch I am already using, so that after a person is redirected to – which meets HSTS’s requirements – they are immediately redirected a second time to

That is all I am trying to accomplish, but have failed thus far. Is it possible to do two consecutive redirects in a row?

Thank you Seth.

Bill K.

Hello Jacob,

My reasons for opting for the HSTS Preload List are really quite simple:

  1. Small speed boost to access my primary website.
  2. Further legitimizes my establishment as a safe, secure website to visit.
  3. Small advantage over similarly-themed websites.

To clarify, I live on the U.S. territory of Guam in the Mariana Islands in the Western Pacific.

However, I am American born, my native language is U.S. English, and my hreflang on all of my pages is also set to English – but not U.S. English – being as most of my audience are U.S. resident English speakers, as also occurs on my Facebook timeline and page.

A problem arises the further east my web server data must travel, in order to respond to the end user’s http request. It can sometimes be 20 to 30 hops, according to traceroute.

As an example, from here on Guam, I can easily connect to servers in California, such as to Apple. However, the further east my requests must travel, the more potential there is for deterioration/degradation due to Internet congestion, etc. Loading sites in say New York or Florida can result in some noticeable lag.

Obviously, this works in reverse as well, for my end users, and that is bad news. At some 7,000 miles away from those who live on the U.S. East Coast, they can have a hard time connecting to my web server, particularly to my WP blog, being as it uses PHP, which automatically results in some drag from the start.

For the record, I don’t use any WP caching plugins, because they have caused me nothing but problems in the past, oft times conflicting with other plugins, or in other ways.

The point is, Jacob, I need every small advantage I can get, in order to retain the folks that I do get here. So, submitting my website to the HSTS Preload List seemed like another small and smart way to do that, because it reduces the lag just a tiny bit.

I hope the above sufficiently explains my reasoning to you. It may possibly be flawed, being as I am so new to all of this, but that is why I did it. Plus, I have no motivation to ever draw back from using SSL/TSL, since that is obviously the wave of the future, so why not?

Hi @IslandBoy,

Thanks for the detailed explanation of your reasons! That makes sense to me, and helps deepen my understanding of the HSTS preloading ecosystem.

You are welcome @jsha. Now you know to never ask a windy writer a simple question. :stuck_out_tongue:

It is also possible that HTTP/2 is the culprit if you have it. See

Thanks for the response, @Weird, but as I explained a few days ago in the above thread, this issue has already been resolved. The problem was that I had only made a certificate request for, and not for Thus, I simply had to make a second request via Certbot, in order to obtain a certificate that covers both of them. Once I did that, was happy. All is now well, and my website should hopefully be included on the HSTS Preload List within a few months, in the major web browsers.

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