I'm about to buy an SSL certificate from GoDaddy for a site, let's say "example.com".
However I'm currently making design and performance updates in a non production VPS, using it's IP address. Let's say: 10.10.10.10
I would like to purchase the certificate to use it in example.com, but first I want to test https and everything in the non-production server.
This is probably a stupid question but I'm new to this area and I need to know if this will cause the certificate not to work on this other ip address(Before spending the money).
The certificate doesn't change. As long as you're only specifying the domain name, and not the IP address, in the certificate, it can be used on multiple machines. You will have to adjust your test setup to point the domain to the test IP address.
Related
I've bought a .com domain from a provider on the internet. But, I want to host it locally.
I know that I can host a local web by using XAMPP or WAMP, but I want to make it accessible on the internet.
I also know that we could host a web to be accessible on the internet like ngrok, serveo, etc.
But, I want it with my .com domain that I bought. Could this possible? How to? Is there any references?
Thanks in advance ^_^
It seems to me you are asking 1. if it is possible to map a DNS entry such that traffic to the URL would be directed to a server in your personal network, and 2. if it is possible, how to do it.
The answer to the first question is yes, it is possible. The second question is difficult to answer because it depends on many factors such as your ISP, country, your web host provider's rules and services, etc.
First, you must determine two IP addresses:
The public IP address for your network (whatismyip.com)
The private IP address of the local machine which will host your website (typically (192.168.0.x)
Then, you must enable port forwarding in your router configuration, such that any requests to port 80 and/or port 443 on the external interface (public) will be forwarded to the internal port on which your website is hosted. If done properly, putting the public IP in your browser will take you to the website you are hosting locally.
Once you verify access via public IP, then you must go into your DNS entries on your domain host and create a CNAME record which points your root domain (www.yourwebsite.com) to your public IP address. That will route all traffic to your .com to your local server.
I do NOT recommend doing this however, and would caution against it, because it leaves your local server/network open to the public, and makes your domain vulnerable to things such as spoofing etc. To do it properly, you should obtain a security certificate for your domain through a Certificate Authority (CA) - generally, you can request a certificate via your domain hosting service. Once you have a certificate, you must upload the key to your server and configure your web application/hosting service to use the certificate, and then change your port forwarding to use 443 instead.
This is a very complex topic that takes time to learn, and your question is extremely non-specific. There is no good place to start really, and no shortage of information/resources available online. To start, you need to understand how your DNS works. For any local webhosting, port forwarding is important to learn. You should also determine if your ISP blocks the forwarding of certain external ports, which effectively disables any private webhosting.
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.
Aim:
I want to use free SSL certificate on Cloudflare on the website that is current hosted on Azure.
Background
A SSL certificate has been bought from Azure, but we found that we need to upgrade our subscription before able to bind it to our website. Hence, we decided to use Cloudflare free plan that also offers SSL. The domain provider that we use is godaddy.
Problem:
I have followed the instructions here, and now on the Cloudflare, I could see the status for SSL certificate as Active Certificate. However, when I enter the url as https://mywebsite (https), it says that This certificate is not valid (host name mismatch), which is shown on the screenshot below:
Questions
Why does the current SSL certificate points to .azurewebsites.net? Shouldn't it points to cloudflare, after changing the nameservers? What does it mean by host name mismatch?
Current status for SSL certificate on Cloudflare is Active Certificate, does it mean that it's verified and currently applied to the website?
Thank you very much!
You are correct, if it is configured properly it should display the correct certificate in your browser. Possible reasons that it doesn't show correctly: old certificate cached in browser, old nameservers cached, you're not using cloudflare for the appropriate DNS records.
1b. As for the host name mismatch, you typed in example.com and it returned a certificate for a different domain. This means that the data can still be encrypted during transmission but that you are probably not communicating with who you think you are.
Not necessarily. In the article that you link is a great diagram of this process (5th image). You are using Flexible SSL. In order for this to work your website needs to go to Cloudflare's servers first. You can have an active certificate but that doesn't mean that it's been applied to your website. Make sure that the domain and/or any subdomains are on cloudflare and that data is routed through Cloudflare's servers.
We have a Windows Server 2003 machine running IIS6.0 that hosts two different websites. We purchased an SSL certificate for both domains, but then discovered we couldn't use both at once because SSL uses port 443, and I can't set both domains to use that port number.
So my question is, is it possible to host https://www.domain1.com and https://www.domain2.com on the same IIS 6.0 server? If so, how can I do this?
As #Bahri Gungor said the way to do this is for the server to have multiple IP addresses, have the different domains attach to different IPs and then you should be able to have each have a seperate SSL certificate.
Windows Servers can be assigned lots of IP addresses, then depending on your network setup you could change the DNS records for your different domains to point to the different IP addresses. Remember DNS changes take a while to role through the network (depending on their time-to-live). So you need to have the domain you move hosted on multiple IP addresses until all clients have the new DNS records.
See the following
http://technet.microsoft.com/en-us/library/cc722518.aspx
http://www.windowsnetworking.com/articles_tutorials/understanding-advanced-tcp-ip-settings-windows-2003.html
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/74097d64-d3d7-4b07-a1b7-0be86494ba97.mspx?mfr=true
Why?
How I assume you have things configured is serving both domains off the same port and the same IP address, and have IIS choose the different WebSite based on the host-header. The host-header as the name implies is part of the http headers sent to the server with the request, when using HTTPS this information is encrypted using the SSL certificate. So if your could have multiple certificates servered off the same port and IP address IIS would not know which certificate to decrepit the incoming request.
Wild Card Certificates
One way round this is if you have multiple sub-domains they can share one SSL certificate then you can use host-headers to choose which site the user is interested in
so if you had
a.example.com
b.example.com
c.example.com
You could get a certificate for
*.example.com
Then the websites for the subdomain could share one SSL certificate and the same IP address and port.
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