I've read all the other threads here on SO regarding this and have even tried this walkthrough to no avail.
I have a wildcard SSL installed on my 2008R2/IIS7 box. I have it bound to it's own IP address and I only have 1 site that's using it. The site sub-domain is in this format - sub.sub.sub.tld.tld. So my wildcard is the *.tld.tld.
The site comes up fine in HTTPS but I get the warning that reads like this:
You attempted to reach sub.sub.sub.tld.tld, but instead you actually reached a server identifying itself as *.tld.tld. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of sub.sub.sub.tld.tld.
I'm at a loss on why this is happening as everything I've read and done should work and I should not be seeing the SSL warning since I have a wildcard SSL cert.
Any ideas on what I'm doing wrong?
Found out the answer and confirmed it by reading this post. Seems that my *.domain SSL cert only works with 1 level of subdomains due to RFC 2818.
Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.
So my solution is either get a SAN type of SSL Cert or reduce my subdomains to just 1 (which I did).
Related
In I/O 2018 Google announced their new .app TLD and they said that it will be HTTPS only.
I thought that DNS just maps domain names to IP's.
How are they forcing HTTPS?
(a little offtopic here)
It is called HSTS Preloading, see https://hstspreload.org/
HSTS (HTTP Strict Transport Security) is a way for servers to reply to clients: please contact me over HTTPS only (see https://www.troyhunt.com/the-6-step-happy-path-to-https/ for examples). It enhances security but still does not solve one case: the first connection to a given server can happen over HTTP before the browser learns it should have done an HTTPS instead.
Hence come the "preloading" of HSTS.
Basically this is an hardcoded list embarked in all major browsers code
(see https://caniuse.com/#feat=stricttransportsecurity for compatibility depending on browser and version, or see at bottom for links to code[1]) that says which domains/TLD are HSTS enabled, which means no HTTP connection allowed to them at all.
Note that:
Anyone can submit names to this list by following some requirements, see https://hstspreload.org/#submission-requirements
Google (as it started with Chrome but it is now spread among browsers) welcome inclusion of TLDs and not only hostnames, see end of document at https://hstspreload.org/ ("TLD Preloading")
They already did add .DEV in the past (the TLD by itself is not live yet, but Google will launch it "soon") which broke many developers setup where they used (wrongly) a .DEV domain name to name their local resources and as soon as their browsers were updated with the newer HSTS preloading list, they refused to connect to their local .DEV host without HTTPS. You can find here and elsewhere (ex: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/) many horror stories of developers up in arms against that and also may people offering bad solutions for that (like disabling HSTS preloading which is a very bad idea).
Also when you buy a .APP domain name (and it will be same for .DEV), Google (as registry of .APP) made sure contractually with all registrars that they will, during checkout of a .APP domain name buy, display a prominent message saying something along the line of: ".APP is a secure TLD and websites will only work with an SSL certificate(sic); make sure to buy an SSL certificate" (SSL certificate is straight out of Google documentation and this is very sad to read out of them since it is a doubly wrong term, it should have been an "X.509 certificate" or, in order not to frighten anyone, at least a "certificate used for TLS communications", noone should use SSL anymore nowadays...).
By the way, .APP opened for the public at standard prices yesterday, May 8th.
Of course all of that is only related to web browsing. You could set any other kind of service, like email, on top of a .APP domain name, without any mandatory TLS (which of course is not a good idea nowadays but nothing will refrain you from doing that). For email, there is ongoing discussion to have basically HSTS but for MTAs, see https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/
[1] see some source codes with the HSTS preloading list:
https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc
or you can use the API at https://hstspreload.com/ to learn if a name is on the list
It's just a policy. A domain name is a domain name, and DNS only cares about how the name is translated to other resources, like for example an IP address. Technically any IP address can be used together with any IP protocol (there are 256 to choose from, one of which is TCP) and when applicable, any port number (there are 65536 to choose from, two of which are HTTP and HTTPS respectively). There is no way to place restrictions on this via DNS, but of course the TLD registrar can attempt to do this via policy rules.
By trial and error I easily found an .app domain where HTTPS is not enforced:
curl -v -L http://foo.app/
This results in a couple of redirects, but none of them redirect to HTTPS, and the final response is a HTTP response from a GoDaddy address.
I've got a fairly simple app deployed on OpenShift that uses CloudFlare as a DNS provider, since they support CNAME records for the root domain, which our current domain provider does not.
The issue with this setup is somewhere along the line https is not working. I believe this is an OpenShift issue because it's the same kind of issue you get when you've mapped the domain name to your app but haven't added the proper aliases yet - you get a timeout essentially.
We've got two aliases - with www and without. There's no option to specify https or anything with OpenShift aliases from what I can see. There aren't any SSL certificates assigned to these aliases as we do not need or use https - we're on the Free plan.
The main URL to access the site is http://www.jcuri.com - notice this works as expected, however https://www.jcuri.com times out.
Initially we were thinking of using CloudFlare page rules to auto-redirect to a non-https URL however this is locked down behind a paywall which we're hoping to avoid, as we don't need any of the Pro features.
Is there something I'm missing here? It seems that OpenShift is just denying any https connections purely because we don't have certificates assigned to the aliases. I wouldn't even mind if there were certificate errors, at least that would give us a chance to do a redirect on the actual NodeJS application, but we don't even reach that point.
Can anyone offer some advice on this?
Since those domains are not pointed directly at openshift via CNAME, but are seemingly redirected via another service (from what i can tell from the dns) it is hard to say whether it is OpenShift that is causing the https issues. If you do not have a custom ssl certificate installed on openshift, you will just get an invalid certificate error, but since you are using a redirect service, maybe it is possible that the service is checking the certificate first, seeing an error, and then not working?
Since the https page rules you stated above are behind a paywall, this actually makes a lot of sense that they are blocking it, not OpenShift. Godaddy provided a forwarding service that would allow you to point both www and naked domain to openshift correctly using cnames, i have used it before.
I am new to development and at my new job we have this issue where on a sub-domain users are getting the error you see below but when they go to the base domain (e.g: domain.com) they don't see that.
I am supposed to solve this but not sure what might be causing it. I am not looking for somebody to solve this for me but if you can outline possible reasons why, i would be very thankful.
First thing: open up the "Technical details". They will give you more information, information you might or might not yet fully understand, but it still have the necessary info.
Basically, SSL (https) certificates are created for a specific domain. If the domain name changes (from e.g. example.com to foo.example.com), the certificate can not be used without a security warning popping out.
You need to create (either by self-signing or purchasing) separate SSL certificates for all the host names/domains under which the site will be accepted, to avoid the security warning. An alternate option is to purchase a wildcard certificate for the entire domain and sub tree (ie: *.example.com).
There are, to the best of my knowledge, no other ways around this; it's one part of how the HTTPS security is established.
When you're running HTTPS, you should have a different certificate for each server (subdomain) not each domain and the client should trust it if you don't want them to see this error.
You can use a wildcard certificate also. It would inherit through all subdomains.
I have a single site in IIS with a blank host header and 50+ unqiue domains that all point to this one site. Is there a catch-all or wildcard SSL available that I can install on the site so it will work with each domain? I know wildcard certs exist but I think they're limited to a single TLD.
I was hoping to install multiple certs on a single site since each domain already has a cert purchased but that isn't going to happen.
I had a look at IIS 7 SSL for multiple sites with a single IP which points to http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html which says I need a unified communications certificate http://www.sslshopper.com/unified-communications-uc-ssl-certificates.html
Any ideas? Will the unified cert work?
IIS 7.5
Wildcard SSL certs are for a single domain. For your situation you'd have to have a certificate that worked for every domain, which, err, wouldn't be that safe, you could, for example, spoof hotmail.com
However there is an attribute in X509 called Subject Alternative Name (SAN). That allows for a fixed list of domains for which the certificate may be used on, but the list is fixed at issuance time. Your link says it uses that method, but I'm confused why they say they're primarily for UC server, they work fine as plain old HTTPS certificates. I'm using one right now on a development box.
In case you think they're specialised Verisign do them too,as does Entrust
In principle, each server (meaning whatever program on the server side answers to the client's request) can send only one certificate. It also will send a chain of certificates up to the root certificate.
With plain SSL/TLS, the handshake is done before the client has a chance to indicate for which domain it wants a page (this is done in the HTTP header), thus you have no chance here to offer the right certificate.
A common solution is that the server has several IP-addresses (one for each domain, or at least one for each SSL-certificate), and thus can recognize by the IP address, which certificate should be used. (I don't know how IIS handles this, though.)
Assigning new IP-addresses gets more problematic with the increasing scarceness of IPv4 addresses, for this and other reasons RFC 6066 (and its predecessors) defines the server name TSL extension (extension-ID 0), which allows the client to include the wanted server name in the ClientHello message (which starts the handshake), allowing the server to select the right certificate for .
No serious certification agency will give you a wildcard certificate for *.com or similar, since with such a certificate you can pretend to be almost anyone. A certificate can list multiple domain names, but I have no idea if there is an upper limit in the number of those (both for IIS and the usual clients).
I'm a beginner in .htaccess and I need help. We have this website with its store module in https. We also have a parked domain pointing to this website. The problem is, when I type "https://www.parked_domain_name.com/store/" in the address bar, I get an SSL error. However, when I type "http://www.parked_domain_name.com/store/" on the address bar, it redirects to "https://www.parked_domain_name.com/store/" without getting any SSL errors. How can I view the store w/o SSL errors when I type "https://www.parked_domain_name.com/store/" in the address bar?
In general, you can only have HTTPS running on a single domain name for a site.
There are exceptions, for example a certificate for *.example.org would let you run HTTPS on both www.example.org and web.example.org subdomains. Also, some certificate providers will issue certificates for a fixed list of several domain names.
But in common usage, one IP address can have only one certificate, and one certificate can have only one domain name.
The behaviour you describe of the http URL redirecting the the https URL without warnings does not sound like it is possible. Perhaps try a few different browsers - they all act a bit differently on this front. How you reached the URL is not relevant. If you access example.org over HTTP and the certificate says anotherdomain.com then you will get SSL warnings.
You're best off running the site only on e.g. https://example.org/ and redirecting any other domains to that one, rather than hosting the site from multiple domains.
I hope this helps.