0

The .htaccess successfully diverts all variants to @@@@.software on the browsers. And I have appropriate CSP headers (that work on all other sites in different installations) installed in htaccess. I have a multi-domain certificate and I had thought that everything was fine. I had been using cspvalidator.org and it was reporting everything as all good. However

  1. Nibbler never finishes scanning the site
  2. Mozilla observatory never finishes either
  3. Google CSP evaluator says there is no CSP
  4. Probely says there is no CSP.

And finally hstspreload.org is a little more enlightening and says this.

Error: www subdomain does not support HTTPS

Domain error: The www subdomain exists, but we couldn't connect to it using HTTPS 
("x509: certificate is valid for @@@@.software, mail.@@@.software, @@@.app, @@@@.co.nz,
@@@.online, www.@@@.app, @@@websites.co.nz, not www.@@@.software"). 
Since many people type this by habit, HSTS preloading would likely cause issues for your site.

I am assuming that this is what is causing all the problems on this installation. This installation has a named multi-domain certificate while other installations have a multi-sub-domain certificate.

This installation is a multi-site hosting and 5 websites redirect to their individual folders under @@@.software. Do I really need the certificate to be valid for www.@@@.software (and probably on the other domains redirecting here as well)?

5
  • 1
    This serverfault.com/a/566433/89279 may be helpful. You need to tell your CA to add the www versions to your predefined list of domain names, to use the certificate you are using. Nov 6, 2022 at 5:48
  • If it means anything? I would have thought they would have assumed you wanted the www under the same certificate --- Apparently, they didn't. Nov 6, 2022 at 5:58
  • It may be possible, depends on your server/host to have the www.@@@.software only on port 80 or HTTP then redirect from there to the @@@.software on https. The only data revealed is the name of the site which is not secure by default during the DNS cycle. But you do need the www.@@@.software to not respond to the https request, as chrome now tries HTTPS first then trys http if https does not respond. Nov 6, 2022 at 6:07
  • You can try using a wildcard certificate - *.example.com - it will basically create a certificate that is valid for any subdomain you own Nov 8, 2022 at 21:40

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.