Is there any autonomous/programmatic way to create many VPS/cloud servers that securely serve a web page that will be accepted by off-the-shelf browsers without buying a new domain name for every VPS? I'm trying to find a solution that is fast, secure, and completely autonomous and it totally stumps me.
Creating many servers programmatically is easy--eg. create DigitalOcean droplets with their API. I also understand how to programmatically setup a web server and secure it with TLS using Let's Encrypt. The part that stumps me is how to setup TLS autonomously for an arbitrary number of VPSs.
What I've tried/though of so far:
Self-signed cert for the IP address of the new VPS won't be accepted by browsers without warnings of plague and death
Let's Encrypt does not support bare IP addresses, only domain names and I can't find any provider that offers bare IP certs with automated and cheap verification
I could buy a wildcard cert and create a new (random?) subdomain for every VPS but then it could take hours for the DNS records to propagate to my end user
I could setup ahead of time a few hundred subdomains, point IP addresses to them and then secure them with a wildcard cert but that would be really expensive, like $4/month per IP address to reserve it
I could use something like DigitalOcean's floating IPs and assign them to the VPS as it's created but again, that costs $4/month to reserve each floating IP
I could use a wildcard cert with pre-setup subdomains that are pointed to by a DDNS and update the DDNS when the new VPS is created. But again, as far as I understand DDNS, it could take hours or at least minutes for the propagation.
I could only secure one server with TLS then proxy traffic from the outside world through that server and then to the VPSs using self-signed certs. This would probably work but add latency and a performance bottleneck. The application is already needing high performance and low latency so this is not attractive.
Is there something I haven't thought of? Anyone with out of the box ideas?
Any DNS or DDNS gurus out there who know how to instantly assign a new subdomain to a new IP address? Can you avoid caching delays with random subdomains? Any cert authorities who issue automated bare IP address certs?
Thank you!
Background: My client sells a piece of software that runs only on Linux and they want to enable their customers to user that software occasionally in the cloud from any browser. My plan is to program a cloud hypervisor that serves a web interface, takes a request from the customer to use the software, spins up a new DigitalOcean droplet with an image that runs the software, connects the customer's browser to a VNC-to-websocket proxy, then destroys the droplet when the session is over.
To automate the infrastructure give a try to terraform for now probably is the most consistent and "easy" way of creating all your instances.
Now for using TLS on all your domain/subdomain probably the easiest solution is to delegate this to CloudFlare (considering you app is a web page HTTP/HTTPS):
Cloudflare-issued SSL certificates cover the root-level domain (eg- example.com) and one level of subdomains (eg- *.example.com)
In case you need to get the certificate and later use it like for a local web instance or an SMTP server you can still use lestencrypt but do the verification via DNS, this way, you don't need a web server and can "programmatically" manage your certificates, the how you deploy them or put them in your instances is another topic, maybe for that "ansible" could help to automate that process.
Related
I am a bit new to the deployment of a website. I have a server which is written in Node.js. Previously I had been using Heroku for deploying my apps without knowing much about deployment. I would like to know how do I deploy my server to create a website which has .com at the end of it like www.example.com and not www.example.herokuapp.com. I think it has something to do with domains (correct me if I am wrong). I would like to know what exactly is a domain and a DNS provider and how to deploy a website in such a way. Thank you.
You should ask one question to yourself when you hit www.example.com in browser how does it load a page?. When you run a website on your laptop it basically runs locally, if you want to access your website over the internet you would require public IP(host or server) accessible over the internet so you can access a webpage using public IP:port. But this is not the best option because IP may change in the future and also remembering IP for each application will be difficult. Imagine if you access Facebook, Instagram or any other websites by its IP addresses how difficult and inconvenient would it be? There are a couple of things you should know.
DNS-> Domain Name system
Every host is identified by the IP address but remembering numbers is
very difficult for the people and also the IP addresses are not static
therefore, a mapping is required to change the domain name to IP
address. So DNS is used to convert the domain name of the websites to
their numerical IP address.
DNS is a hostname to IP address translation service. DNS is a distributed database implemented in a hierarchy of name servers. It is an application layer protocol for message exchange between clients and servers.
Name servers
Domain Name Servers (DNS) are the Internet's equivalent of a phone book. They maintain a directory of domain names and translate them to Internet Protocol (IP) addresses. This is necessary because, although domain names are easy for people to remember, computers or machines, access websites based on IP addresses.
DNS record
A domain name, IP address what is the validity?? what is the time to live ?? and all the information related to that domain name.
Once you understand the DNS
Host(Deploy) your website to Amazon EC2 or Heroku and obtain Public IP.
Buy a domain from domain provider like Godaddy
Map domain(ie www.example.com to IP)-> DNS record
Mapping domain to IP may vary platform to platform but the Core principle remains the same. I would suggest you these below link. Try to find differences in both, doing so you will learn along the way
http://www.littlebigextra.com/map-domain-name-amazon-aws-ec2-instance/
https://medium.com/progress-on-ios-development/connecting-an-ec2-instance-with-a-godaddy-domain-e74ff190c233
I'll get straight to the point.
I have bought a domain. I want to host it on my computer, maybe on a raspberry pi since only 50 persons/month will visit it.
Anywhere I've looked I see two hosting methods, using IIS/WAMP/XAMPP to only create a localhost website or adding the domain to C:\Windows\System32\drivers\etc\hosts.txt that is also... localhost.
What is the magic answer here? How can I host LIVE a website with the domain that I have bought? Am I stuck to using a hosting service? Am I missing something really important?
using IIS/WAMP/XAMPP to only create a localhost website
You need an HTTP server if you want to host a website. It needs to run on the computer you want to host the website from.
adding the domain to C:\Windows\System32\drivers\etc\hosts.txt
That's what you do as a poor man's solution instead of buying a domain name.
The Domain Name needs to be associated with a DNS server (and secondary DNS server) by your registrar.
Usually, a registrar will provide DNS hosting services as part of the deal.
The DNS server needs an A record pointing at the IP address of the computer running the web server. This IP address needs to be available to whomever is going to visit it (which almost certainly needs to be public facing) and should be static (unless you want to play games with very short TTL values and frequent reconfiguration of the DNS servers).
If you plan to host multiple different websites on the same server, you'll probably want to configure the HTTP server software to handle Virtual Name Hosting (whereby it pays attention to the Host header in the request and dynamically serves different content based on it)
For our SaaS app, we're allowing customers to point their domain name to our server.
The plan right now is to simply hand out one of our AWS elastic IP addresses for them to point their domain to. The elastic IP address would essentially be pointed to a EC2 instance web-server...and maybe a load balancer in time (if traffic demands it!).
The user would specify what their domain is in our app, and we'd be able to resolve the host name coming in as their app.
My concern is the longevity of this solution. This IP cannot change. And we'll certainly be tied to AWS if we go this route.
(Note: Being a 1-2 person startup, standing up a data-center is more than likely no-go, and we hope to use AWS or Azure).
What solutions would make this IP address -> SaaS Web Server concept last in the long run, with flexibility, and as minor of a tie as possible to a cloud provider?
With running the risk of asking "what is the best way to do this"...what's the best way to do this, keeping in mind longevity and small opt-in to a cloud provider?
You can't point an IP address to a load balancer, so this seems like a very bad idea. You need your own domain/subdomain that clients can point their domains/subdomains to via a CNAME record on their end. Then if the location of your service ever changes you just have to update your domain record and their DNS records will continue to be correct.
I am looking to move my websites from sitting on an Azure VM to being in an App Service.
In the App service there are several items in the Pricing I don't understand and cannot find answers too. Do you know what these items means?
"Up to 10 Instances" Auto Scale. Does this means I can host 10 apps on this plan, or that it will create new instances for my individual apps when under load? IE if my website google.com was being used a lot, would 10 instances of this website spin up?
5 SNI, 1IP - What on earth does this mean?
Thanks!
Tom
Auto Scale means that the Azure will automatically create instances or shutdown them, based on your website traffic. So your second example is correct.
5SNI (Server Name Indication) or 1IP, I'm just gonna explanation copy and paste from Azure documentation website (here) as I believe it's explained quite well:
IP based SSL associates a certificate with a domain name by mapping the dedicated public IP address of the server to the domain name. This requires each domain name (contoso.com, fabricam.com, etc.) associated with your service to have a dedicated IP address. This is the traditional method of associating SSL certificates with a web server.
SNI based SSL is an extension to SSL and Transport Layer Security (TLS) that allows multiple domains to share the same IP address, with separate security certificates for each domain. Most modern browsers (including Internet Explorer, Chrome, Firefox and Opera) support SNI, however older browsers may not support SNI. For more information on SNI, see the Server Name Indication article on Wikipedia.
I was asked to create a sharepoint web application with ssl on a server with sharepoint 2010 installed. The problem is that this port seems to be in use for hosting our subversion repository. So when i try to browse my sharepoint site, it just shows a page with my repository. I've read about installing certificates and configuring multiple sites on one port with host headers but i never succeeded to complete this job. I would really appreciate some help here.
Thanks!
Assuming you're talking about individual SSL certificates (as opposed to a single wildcard certificate), I believe each website HAS to have its own IP address. AFAIK it is not possible to run multiple websites with multiple SSL certificates under the same IP address.
Depending on who is hosting the server, you would need a new IP address to be allocated to the server, and then within IIS you use the new IP address against the hostheader of your new website. You should find that the certificate works correctly, if not then try removing the certificate from the website and re-allocating it.
You would only be able to use a wildcard certificate if the primary domains of the websites were the same (e.g. website1.mydomain.com and website2.mydomain.com).
Thomas,
I've run into a similar situation before where the requirements dictated that we use 1 ip address, but the domains will be different (eg. website1.com, somesite.org, website2.us).
You can achieve this by using a Unified Communications certificate with Subject Alternative names. Currently, Digicert offers a UC certificate that can achieve this, but some other CA's will not.
Essentially you will have 1 certificate bound to :443 on the same ip address. The big drawback to this is that if the cert goes down, all the sites SSL will not work.
You have to manually (via powershell) bind each domain to port 443 however, but the instructions are fairly simple.
Server Name Indication would be another way, but it's not even an option in IIS 6