Πρόσφατες απαντήσεις προς Impossible to make my website with HTTPS wíth certificatehttps://support.mozilla.org/el/questions/12503302019-02-28T03:03:04-08:00Thank you!
2019-02-28T03:03:04-08:00erwinklomphttps://support.mozilla.org/el/questions/1250330#answer-1200993<p>Thank you!
</p>It works if I use the http protocol with the www. prefix.
In that case you get redirected to the cor2019-02-23T22:17:04-08:00cor-elhttps://support.mozilla.org/el/questions/1250330#answer-1199742<p>It works if I use the http protocol with the www. prefix.
In that case you get redirected to the correct https website.
The problem is that once you try https then HSTS is cached in SiteSecurityServiceState.txt and you won't be able to use the http protocol and get a server redirect.
</p><p>A certificate error like this would suggest that you have to remove a leading www. since only one sub domain level is supported.
</p>
<pre>The certificate is only valid for the following names: *.xxxxxxxx.xx, xxxxxxxx.xx Error code: SSL_ERROR_BAD_CERT_DOMAIN</pre>I researched this and in wildcard certificates, the * only matches one level and can only be the lef2019-02-23T21:17:42-08:00kede81https://support.mozilla.org/el/questions/1250330#answer-1199729<p>I researched this and in wildcard certificates, the * only matches one level and can only be the leftmost part of a name, so you can have neither *.*.xxxxxxxx.xx nor www.*.xxxxxxxx.xx, you will have to enumerate the subdomains to cover the "www." name of each.
If browsers match more generously, they deviate from the standard which reduces security.
</p><p>Surely you cannot expect Firefox browser to ship with exceptions for particular domains which are not covered by the SSL certificate they are presenting? It remains your responsibility to present a certificate that covers the domains you wish to provide via https.
</p><p>You may consider automating certificate requesting with <a href="http://www.letsencrypt.org" rel="nofollow">www.letsencrypt.org</a> - they also support wildcards but in your case, listing both SANs for each client (i.e. www.abc.xxxxxxxx.xx and abc.xxxxxxxx.xx, and the same for each of the others) seems the more streightforward option. It is a free service and they support as many SANs as you want as long as you can prove they belong to you by storing the challenge file on each.
</p><p>One script of automating letsencrypt certificate requests is dehydrated, I am using that on my webserver and it works great. A daily cronjob will check your server name list, and if the list differs from your current certificate, it will automatically request a new certificate covering all of them.
</p>Hello, I'm still in search for an answer the response you gave didn't help unfortunately.
2019-02-21T01:59:46-08:00erwinklomphttps://support.mozilla.org/el/questions/1250330#answer-1198971<p>Hello, I'm still in search for an answer the response you gave didn't help unfortunately.
</p>The problem described in stackoverflow link is about setting up DNS records
But our DNS records are 2019-02-19T00:22:17-08:00erwinklomphttps://support.mozilla.org/el/questions/1250330#answer-1198399<p>The problem described in stackoverflow link is about setting up DNS records
</p><p>But our DNS records are correct:
</p>You can view a description of the underlying problem, and options for the solution, on Stack Overflo2019-02-15T05:41:52-08:00PPorthttps://support.mozilla.org/el/questions/1250330#answer-1197356<p>You can view a description of the underlying problem, and options for the solution, on Stack Overflow at:
</p><p><a href="https://stackoverflow.com/questions/8296054/subdomains-not-working-when-www-is-added" rel="nofollow">Stack Overflow Subdomain WWW Issue</a>
</p><p><a href="https://stackoverflow.com/questions/8296054/subdomains-not-working-when-www-is-added" rel="nofollow">https://stackoverflow.com/questions/8296054/subdomains-not-working-when-www-is-added</a>
</p><p>As the Stack Overflow answer indicates, the <a href="http://www.subdomain.domain.nl" rel="nofollow">www.subdomain.domain.nl</a> URL fails because it can't be found on the web server - unless you make changes to the CNAME record. You can go through and do that but most people just drop the WWW. when passing along, or publishing, URLs for subdomain targets. In most cases, modern web servers consider the initial WWW. as superfluous anyway - for all URLs.
</p><p>Also, the security / encryption component of the transmission is triggered by the "s" in https:// (bringing in the underlying certificate) - so just make sure you don't drop the "s" and go back to http:// alone.
</p>