X
點擊此處開啟此網站的行動版。

技術支援討論區

Impossible to make my website with HTTPS wíth certificate

已張貼

Hello, there is a https:// setting that is destroying my charity project and (since my project is about creating funds for many charities), it's affection many other charities as well.

I’ve got a website called Doelshop.nl which raises free donations for charities. This is done through affiliate marketing, someone buys something through my website (I’m just linking through) and 75% of the commission goes to the charity that the buyer chooses. The buyer doesn’t pay anything extra.

PROBLEM with Firefox/Google Chrome

Many charities have applied (because they can get free donations through their users who are already shopping online), recently we have implemented in our system a function where each project can make their own subdomain.

This means, if you have a charity called ABC, you can create ABC.doelshop.nl and automatically you have selected the ABC charity. Very handy for charities, because it’s easy promotion.

Now here’s the problem, we have bought a SSL wildcard certificate to establish https:// connection for all these subdomains.

BUT, some are typing into their URL boxes: www.abc.doelshop.nl and this CANNOT be certified. Technically it can if we manually insert every subdomain into multiple certificates, which would cost us thousands of dollars. Also our subdomains are not set, new ones are being created all the time.

Both Firefox and Google Chrome now always give an error message when people type in their URL address with ‘www.’. People cannot even reach the website, it gives un unsafe warning and shoppers won’t donate for free to their charity.

We have redirected the ‘www.’ to ‘without www.’ but this doesn’t help.

PLEASE HELP

Is there any way where you could help, for example by listing these sub-subdomains as safe? I can give you any kind of openness to prove there is nothing scammy going on.

I’m willing to change these domain setups towards Doelshop.nl/abc instead of abc.doelshop.nl but it takes a while. If you could list it as a safe connection in the meantime that would also mean a lot!

Instead of using abc.doelshop.nl for testing, you can use https://make-a-wish.doelshop.nl (working) and https://www.make-a-wish.doelshop.nl (unsafe in your browser)

Hello, there is a ''https://'' setting that is destroying my charity project and (since my project is about creating funds for many charities), it's affection many other charities as well. I’ve got a website called Doelshop.nl which raises free donations for charities. This is done through affiliate marketing, someone buys something through my website (I’m just linking through) and 75% of the commission goes to the charity that the buyer chooses. The buyer doesn’t pay anything extra. PROBLEM with Firefox/Google Chrome Many charities have applied (because they can get free donations through their users who are already shopping online), recently we have implemented in our system a function where each project can make their own subdomain. This means, if you have a charity called ABC, you can create ABC.doelshop.nl and automatically you have selected the ABC charity. Very handy for charities, because it’s easy promotion. Now here’s the problem, we have bought a SSL wildcard certificate to establish https:// connection for all these subdomains. BUT, some are typing into their URL boxes: www.abc.doelshop.nl and this CANNOT be certified. Technically it can if we manually insert every subdomain into multiple certificates, which would cost us thousands of dollars. Also our subdomains are not set, new ones are being created all the time. Both Firefox and Google Chrome now always give an error message when people type in their URL address with ‘www.’. People cannot even reach the website, it gives un ''unsafe warning'' and shoppers won’t donate for free to their charity. We have redirected the ‘www.’ to ‘without www.’ but this doesn’t help. PLEASE HELP Is there any way where you could help, for example by listing these sub-subdomains as safe? I can give you any kind of openness to prove there is nothing scammy going on. I’m willing to change these domain setups towards Doelshop.nl/abc instead of abc.doelshop.nl but it takes a while. If you could list it as a safe connection in the meantime that would also mean a lot! Instead of using abc.doelshop.nl for testing, you can use https://make-a-wish.doelshop.nl (working) and https://www.make-a-wish.doelshop.nl (unsafe in your browser)

由 erwinklomp 於 修改

被選擇的解決方法

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.

A certificate error like this would suggest that you have to remove a leading www. since only one sub domain level is supported.

The certificate is only valid for the following names: *.doelshop.nl, doelshop.nl Error code: SSL_ERROR_BAD_CERT_DOMAIN
從原來的回覆中察看解決方案 0

額外的系統細節

應用程式

  • User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

更多資訊

PPort 1 個解決方法 5 個答案

You can view a description of the underlying problem, and options for the solution, on Stack Overflow at:

Stack Overflow Subdomain WWW Issue

https://stackoverflow.com/questions/8296054/subdomains-not-working-when-www-is-added

As the Stack Overflow answer indicates, the www.subdomain.domain.nl 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.

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.

You can view a description of the underlying problem, and options for the solution, on Stack Overflow at: [https://stackoverflow.com/questions/8296054/subdomains-not-working-when-www-is-added Stack Overflow Subdomain WWW Issue] https://stackoverflow.com/questions/8296054/subdomains-not-working-when-www-is-added As the Stack Overflow answer indicates, the www.subdomain.domain.nl 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. 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.

提出問題者

The problem described in stackoverflow link is about setting up DNS records

But our DNS records are correct:

https://mxtoolbox.com/SuperTool.aspx?action=dns%3adoelshop.nl&run=toolpage

The problem described in stackoverflow link is about setting up DNS records But our DNS records are correct: https://mxtoolbox.com/SuperTool.aspx?action=dns%3adoelshop.nl&run=toolpage

提出問題者

Hello, I'm still in search for an answer the response you gave didn't help unfortunately.

Hello, I'm still in search for an answer the response you gave didn't help unfortunately.
kede81 2 個解決方法 24 個答案

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 *.*.doelshop.nl nor www.*.doelshop.nl, 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.

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.

You may consider automating certificate requesting with www.letsencrypt.org - they also support wildcards but in your case, listing both SANs for each client (i.e. www.abc.doelshop.nl and abc.doelshop.nl, 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.

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.

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 *.*.doelshop.nl nor www.*.doelshop.nl, 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. 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. You may consider automating certificate requesting with www.letsencrypt.org - they also support wildcards but in your case, listing both SANs for each client (i.e. www.abc.doelshop.nl and abc.doelshop.nl, 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. 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.
cor-el
  • Top 10 Contributor
  • Moderator
17415 個解決方法 157327 個答案

選擇的解決方法

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.

A certificate error like this would suggest that you have to remove a leading www. since only one sub domain level is supported.

The certificate is only valid for the following names: *.doelshop.nl, doelshop.nl Error code: SSL_ERROR_BAD_CERT_DOMAIN
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. A certificate error like this would suggest that you have to remove a leading www. since only one sub domain level is supported. <pre>The certificate is only valid for the following names: *.doelshop.nl, doelshop.nl Error code: SSL_ERROR_BAD_CERT_DOMAIN</pre>

提出問題者

Thank you!

Thank you!