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).
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.
We want to create 'whitelabel' sites by having multiple hostnames pointing to the same IP (and website in IIS) and dynamically switching the site's database according to the hostname the user came in on.
eg. https://co1.mysite.com, co2.mysite.com and co3.mysite.com will all point to the same site, but in the site's code, we may change database connection strings and logos etc depending on what hostname they came in on.
In this particular context (with all sites going to the same IP) am I right in presuming that SNI doesn't come into play and as as long as a wildcard certificate is used (*.mysite.com) then all browsers will be able to access the site OK? Even those with no SNI support (eg Internet Explorer on Windows XP)?
Yes, you are correct. Server will send the same cert for every request (even from SNI-capable clients). Of course you can't host there any other hostnames outside of scope of your wildcard cert, if all of them needs to be accessible from non-SNI clients.
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.
How can I make my website display a green label in the address bar of the browser:
Do I need to just use https or is it a more complex process?
Just using HTTPS (HTTP over SSL/TLS) does not give you the green address bar. You need an extended validation certificate, where the CA verifies your identity, and not just your domain ownership.
EV certificates are more expensive than simple domain validated certificates.
On security.SE we have a related question: What are the advantages of EV Certificate?
For example, the EV certificate at http://www.paypal.com/ will make the browser show a green bar and display "PayPal, Inc." next to it. This is designed not only to link the certificate to the domain owner (like standard domain-validated certificates do), but also link it to a more physical institution (here, PayPal, Inc.). To do this, the CA must verify that the named institution is indeed the one owning the domain.
You do need to make it HTTPS (which uses SSL or secure socket layer. ) This basically encrypts the data that goes to and from your website. This can be a lengthy process depending on your web host but usually involves purchasing a certificate from your host.
Yes the Green "Favicon" comes and differs from browser to browser and signalises the https connection
I would advice you not to try to implement this if you dont need it for security reasons
I have multiple ssl certificates for multiple pages. I want to run all pages on the same server on the same port, so I need to create one single https server and then proxy the request based on the hostname to the sites.
The problem here is, that I can't find out, how i can use multiple ssl certificates and ever the right certificate is used.
Is this even possible?
Combining the certificates to a wildcard one is not possible by the way, since I use different top level domains for the sites. For example:
www.a.xx
www.a.yy
www.b.xx
www.b.yy
c.xx
c.yy
You can only do it for browsers (and in your case the proxy) supporting Server Name Indication. Not all browsers are supported though, so if you want it completely "generic", you need to use separate IPs for the different sites.
(Granted, most modern browsers support it, so it depends on your "support matrix" for the sites)