My main site https://example.com has an SSL cert, no problem.
Now, I have developped a related application, that is hosted on a completely different server, and under : app.example.com. It has a dedicated IP.
The app uses websockets and needs SSL to function properly acros all devices. But I'm having trouble finding out how to register a new certificate for a subdomain... What's the strategy here? Should I have a wildcard cert on the main server, and somehow redirect from there? In that case, the app server wouldn't have access to the cert, and I wouldn't be able to create my secure socket connection, right?
The certificate has to be installed where the server which provides content using this certificate. This means
That the certificate for the subdomain has to be used on all servers which serve the subdomain, i.e. your websocket server.
And nowhere else, i.e. it is not needed at the main domain just to provide a redirect from the main domain away.
You are free to use any certificate which matches the subdomain, that is it can be a wildcard certificate but can also be specific for only this domain.
You can go for a wild card certificate and bind it to all the URL's who share the same domain. But keep in mind, the wildcard certificates (irrespective of any brands) supports unlimited first level sub domains .
Wild card certificates can be installed on any server where the FQDN is hosted. In situations where the the sub domains are hosted on multiple servers, the wildcard certificate will work for all of them.
Related
I'm using a React frontend application on a domain with a valid SSL certificate, which makes calls to a Django backend application on a VPS (Ubuntu 20.04, apache2), which doesn't have a domain name registered (instead the calls are being made using the IP of the server). The server doesn't yet have a valid SSL certificate which prevents the React app from receiving the resources. Self-signed won't work since it's then not valid in the browser (I might be wrong here).
Do I also need to register a domain name for the backend API server for the SSL certificate to be valid or can I just buy an SSL certificate and work from there?
To even get an SSL certificate back from the vendor, you need a fqdn (fully qualified domain name). That information is used to sign and create the certificate request. Your webserver won't even properly encrypt until you have valid signed certificate for the server in question. You can expand the number of hosts that a certificate will serve by buying a wildcard certificate (*.example.com vs specifichost.example.com)
If your back end server is on some cloud or hosted service, you can use self signed certificates but you would have to disable "strictness" in your front end. If you're at any time performing financial transactions this is not advisable.
If you're making axios calls, here's a pretty good article on disabling https strictness (https://github.com/axios/axios/issues/535).
Your vendor for the VPS might have some helpful information on how to harden up the server.
If this is not how you'll be doing this in production and the setup you describe is for testing only, then probably you want to use the environment to set a variable indicating 'strict' or 'test' and switch your calls accordingly. That way, a relaxed setup will work in test or in your sanbox, but production would use a properly configured host with a valid certificate.
I have an SSL cert working on my main domain but I cannot get it working on subdomains off the main domain. The hosting vendor is now telling me I need to buy a wildcard SSL. Wish they had been honest with me while I was researching the windows host product. They assured me in multiple conversations the SSL would work with all Sub Domains off the main domain I applied the SSL cert to.
They said only if I had a completely different domain in addition to the first one would I need to purchase a second SSL or SSL package.
This is the first I've heard of this wild card domain thing.
So I guess I either need to purchase that or go to letsencrypt for every subdomain.
Is anyone able to just apply your SSL to all subdomains under the main domain you have applied your cert to?
Total newbie here in working with web host environment.
I also noticed you could go to SSL/TLS Certificats
But when you go to that page for the subdomain's site, it already has the main domain's SSL cert listed along with an upload button.
I am having a bit of trouble understanding how many ssl certificates I should get under specific conditions:
I have two pages the user is supposed to use (index and main) and all other scripts users don't access in the front end (e.g. uploadFile.php).
I have socket.io implemented in port x which I want to run over https protocol.
How many ssl certificates should I get under these conditions to assure secure data traffic? (is the data from all other php scripts still secure if index and main have ssl?)
SSL cert is issued for a specific DNS name. So if you run your PHP and Socket.io applications on the same domain, one cert is surely enough to secure both.
If you run your app on two different domains, you need to (a) use two separate regular certificates, or (b) have one SAN certificate (it secures multiple DNS names).
Also there is a wildcard certificate, it secures all direct subdomains of specified domain (*.some-site.com). It can be combined with SAN feature, so it can secure base domain some-site.com and direct subdomains as well.
IF your website is accessed via different website on https , then your website and the website through which its accessed needs to have their separate SSL certificate.
If your website does not have an ssl certificate , the connection will be dropped when your website link is accessed via other website.
We have a server running Win Server 2003 SP1 with IIS 6. The server runs three websites of which only one needs to be secured. However, adding HTTPS in front of any of the others redirects the user to the secured website.
From my reading I can see it's because pre SP1 SSL worked based on IP addresses only whereas post SP1 it is possible to configure it for host headers using some scripts. That's all great.
What I need to know is what the final requirements be if I have the following for my applications:
http://www.site1.com - SSL not required, but if the user types in https://www.site1.com it should not redirect to https://app.site1.com
http://www.site2.com - SSL not required, same as 1.
http://app.site1.com - SSL required.
Questions
Do I need to purchase 2 wildcard certificates for this configuration. One for *.site1.com and one for *.site2.com?
If I do get two wildcard certificates do I configure each of the sites to use them and assume that the user can choose to view https://www.site1.com can do so without being redirected
There are a number of similar questions on Stack, but not quite the same requirements. See
Hosting multiple sites in IIS 6, one need SSL
Edit
Microsoft's Recommendation on IIS6 and Wildcard certificates
I found a link where Microsoft explains more about using Wildcard certificates to configure the scenario I have described: https://web.archive.org/web/20161114165638/https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true
Note: We are definitely having the scenario where if the user browses to https://www.site1.com the browser displays the exception (which is correct) but then after accepting the exception they're being redirected to https://app.site1.com.
If you need to secure only http://app.site1.com then you don’t need to buy wildcard ssl certificate. You can simply secure your website using domain SSL Certificate. (Recommended SSL: RapidSSL Certificate, Thawte SSL123, QuickSSL Premium)
Suppose your all three websites are hosted on same IP address.
When user type https://www.site1.com then he will not redirect to your https://app.site1.com but visitor will get domain mismatch error in his browser because of same IP address.
Wildcard SSL can only secure your primary domain plus unlimited sub domain for that primary domain name.
Example: site1.com, www.site1.com, mail.site1.com, blog.site1.com
If you want to secure *site1.com and *.site2.com then you should go with Multi Domain SSL Certificate instead of Wildcard ssl certificate.
We would like to setup an application on Windows Azure at abc.cloudapp.net which would have a CNAME record for www.mydomain.com pointing to it and then allow clients to do the same. Our application would then look at the requested URL and then pull out relevant data based on the requested domain (abc.theirdomain.com or www.theirotherdomain.com).
Our initial tests show that this should work, however the problem lies in that we need the site to be secure. So we'd like clients to be able to setup shared SSL certs with us that we would upload to our Azure subscription that then allowed them to create a CNAME record (abc.theirdomain.com or www.theirotherdomain.com) that points to either www.mydomain.com or abc.cloudapp.net.
Is this possible?
Edit: I'm not sure if this is the same question as Azure web role - Multiple ssl certs pointing to a single endpoint.
We've used a multi-domain certificate in this situation - see http://www.comodo.com/business-security/digital-certificates/multi-domain-ssl.php for details. This will work for up to 100 different top-level domains.
The problem with a multi-domain certificate is that it is more expensive than a "normal" certificate and that every time you add a new domain, you will have to deploy a new package with the updated certificate.
On the other hand, you could have multiple SSL certificates (one for each domain) and then the answer you seek is here Azure web role - Multiple ssl certs pointing to a single endpoint.
No, I don't think your setup would be possible with a single SSL cert. In general, SSL certs are tied to the hostname (e.g. foo.domain.com and foo.domain2.com need different certs). However, you can purchase a wildcard SSL cert that will help if you use the same root domain, but different subdomains (e.g. foo.domain.com and foo2.domain.com can share a wildcard cert).
So, in your case, since you are allowing different root domains, then you need a different SSL cert for each. If instead you choose to allow different sub-domains on same root domain, you can get away with the wildcard cert.