I am planning to change the IP address of a server.
The server has ssl certificate installed.
Will SSL certificate be affected after the IP address changes?
SSL certificates are not bound to IP addresses. They are bound to the fully qualified domain names such as www.stackoverflow.com
So you will not have to worry about SSL cert changes, just ensuring that the new IP is bound to your domain name.
Related
When I read this document:
If you host a service on xyz123boot.com, the original server IP is 136.23.63.44. CloudFlare will provide you with DDoS protection, Web application firewalls, and other security services to protect your services from attack. To do this, your Web server must support SSL and have a certificate, at which point the communication between CloudFlare and your server is encrypted (i.e., no flexible SSL exists), just like the communication between you and CloudFlare. This looks safe, but the problem is that when you connect directly to the IP on port 443 (https://136.23.63.44:443), the SSL certificate is exposed.
how to understand this line:
when you connect directly to the IP on port 443 (https://136.23.63.44:443), the SSL certificate is exposed.
That article is about "ways to bypass CDN to find real IP". That is, how do you find the IP address of a server when it's being proxied by a CDN server at a different IP address?
The cited paragraph applies when the CDN (CloudFlare, in this case) communicates with the origin server over SSL/TLS. The CDN will contact the origin server at port 443, and the origin server will "expose" a certificate so that they can communicate securely.
So, if you could crawl the entire internet at port 443 and gather the certificates exposed, you could then make a mapping between IP addresses and the domain names mentioned in the certificates. According to this article there is a tool (Censys) that has done just that. So by using this tool you can find the origin IP address even though the CDN itself hasn't exposed that information.
I have successfully deployed my spring boot app to Compute Engine on ubuntu 18.04, it is behind Nginx proxy but currently Nginx is listening to 80 port, which is http. I need to set up secure connection. I have question about few details, im new to this, all i've done so far is write spring boot/react js apps on windows, in IDE.
Is it necessary to buy a domain for my compute engine or I can just make SSL for the external ip of compute engine ? On compute
engine only the back end rest api is deployed, the front end is on
Netlify and it's already working. I don't need a good sounding
domain name for back end because user won't see it, only front end
app will use the external ip of my compute engine to fetch data
from back end.
I have seen guides that set up SSL in the setting of Nginx, why is that ? Isn't the request first coming to the compute engine's external ip and only after that to Nginx ? Isn't it the job of compute engine to do secure connection by sending public key&certificate to front end and only then relay the request to Nginx ? Or does compute engine simply relay the https request that comes to it to Nginx right away, without securing it/doing any key&certificate sending ?
You can give some advice if you have any, i'm just trying to make a secure connection to my back end spring boot app which is behind Nginx on google compute engine, which currently works only with HTTP but not HTTPs.
1. Technically you're able to have SSL certificate for public IP, but it's rarely used. More details you can find in RFC 5280 and in this question.
Keep in mind that if your IP address changes your SSL certificate become useless.
I've checked a few SSL providers and found that you should be the owner of the IP to obtain such SSL certificate:
accordingly to the article Using an IP Address in an SSL Certificate posted by geocerts:
If you decide that you really need an IP in your cert there are
specific stipulations, conditions, and limitations to consider. The
biggest hurdle for most folks is that the IP address must be
specifically assigned to your company or organization (not your ISP or
hosting provider) as verified by an IP WHOIS lookup.
accordingly to the article Issuing SSL certificate for an IP address by LeaderSSL:
Quite frequent question: is it possible to issue an SSL certificate
for an IP address (and not for a domain name)? Yes, it is possible.
However, there are several requirements:
Only OV SSL certificates can be issued;
The company must own IP address (validation based on WHOIS information of IP-addresses).
same in the article WHAT IS AN IP ADDRESS SSL CERTIFICATE?:
An IP address SSL certificate secures connections directly with the IP
address submitted. Whereas typically an SSL certificate is issued to a
Fully Qualified Domain Name (FQDN), some organisations may need to
secure an IP address.
Only public IP addresses may be used and you must be the owner of the
IP address according to the records at RIPE.
As result, practically, it's almost not possible in case of GCE VM instance and it's easier to proceed with domain certificate.
2. In GCE all the connections to the external IP of VM instance passed through directly to the VM instance. GCE isn't able to secure connections on it's own. You should configure SSL certificate on VM instance. More details you can find in the documentation VPC network overview and IP Addresses.
In addition, you're able to use Google-managed SSL certificates or own SSL certificates on external HTTP(S) load balancers.
I'm a little confused about IP addresses.
I know that every web domain has an ip address.
Does the IP address represent the physical machine / host the website files are stored on?
Therefore when DNS lookup is performed, the domain's IP address is returned to the client. The client then uses this ip to contact the server that the web files reside on.
Is my understanding correct?
Many thanks
You are correct.
It is kind of like how some companies may say Dial PIZZAHUT instead of saying, Dial 74992488. PIZZAHUT is easier to remember, but you actually are dialling the number.
You're talking about HTTP protocol. Yes, FQDN (web domain) is resolved to IP address by DNS server. Client will connect to server IP address. Since you're probably using HTTP 1.1, HTTP request will contain also FQDN. This information is used by web server to perform several checks, like SSL certificate validation or Virtualhost management (several domains on a single IP address).
I'm setting up 4 servers that each have RESTful APIs that go over HTTPS. Because we're in the early stages of a startup, I'm going to host these in my closet.
I have business-class Comcast service, so I can get a static IP address or a series of them. The IP addresses are $10/ea per month, so I can save about $30 if I get just one. I realize this sounds like I'm being super cheap, but we're pinching pennies until we get some customers.
We will probably use one server as a "tools" server that will allow us to reach the other servers via SSH; the other 3 servers will need to have HTTPS open to the internet on the LAN.
I'm considering getting one static IP address, and then using my router to forward HTTPS traffic to the various servers. The port forwarding would look something like:
WAN Port LAN Port Server
22 22 Tools
1443 443 Server 1 (API via SSL)
2443 443 Server 2 (API via SSL)
3443 443 Server 3 (API via SSL)
I would then set up A NAME records in my DNS that would be:
tools.mydomain.com -> <static IP address>:22
server1.mydomain.com -> <static IP address>:1443
server2.mydomain.com -> <static IP address>:2443
server3.mydomain.com -> <static IP address>:3443
Is this a reasonable approach? Will it work?
You cannot direct traffic to a specific TCP port with DNS records. You can only point at an IP-address. The client by default uses tcp port 80 for HTTP and port 443 for HTTPS (unless you explicitly name the port to use in the URL).
Furthermore you cannot have multiple HTTPS-based hosts using the same IP address unless they also use the same SSL certificate. That is because the SSL handshake takes place before the client reveals to the server which hostname it was trying to reach, so the server can only give out an SSL certificate based on the IP address (and port) that was connected to.
In this particular instance, if you have four servers that actually have the same domain, you can get a wildcard SSL certificate (i.e. it covers *.mydomain.com) and then you can actually get away with one single public IP address for all four servers. Just point all DNS records to the same IP address and then you have the server give out your wildcard certificate which is valid regardless of which hostname the client is using. After the SSL handshake is thus completed, the server can look at the Host: -header in the client request to determine which server the request was actually intended for, i.e. you have one server acting as the HTTPS-endpoint where all HTTPS-requests are received and then internally forwarding to unencrypted request to the correct server (or handle all servernames virtually by one physical server).
If you are using Apache HTTP server I suggest you read about name-based virtual hosts and proxy forwarding:
http://httpd.apache.org/docs/current/vhosts/name-based.html
http://httpd.apache.org/docs/current/rewrite/vhosts.html
http://httpd.apache.org/docs/current/rewrite/proxy.html
I would like to know. When a domain example.com has an IP address: 41.72.111.222, would any of its subdomains (sub.example.com, mail.example.com etc) have the same IP address listed in the DNS records? Or does it work like this: A request is sent from the browser to the DNS server for sub.example.com. The DNS server returns the IP address for example.com, and the split/differentiation is made when the request for sub.example.com hits the example.com host server? So the host server basically know what to do with sub.example.com and not the DNS server?
It can kind of be a combination of both. Ultimately, though, the decisions are made based on what you set your DNS settings to be. Your host (or hosts) will then get whatever traffic you determined they should get in your DNS settings.
So for example...
You can set your DNS settings to take [anything].example.com and always direct that to your server. You would do this by adding a wildcard entry to your DNS subdomains. Wildcard entries use a * symbol to mean "anything". You would then need to configure your server to know what to do with all these different potential subdomains it could be receiving.
At the same time, you can set specific subdomains to go to other hosts. For example, if you wanted mail.example.com to go to some other webmail host, you would set up in your DNS the subdomain "mail" and have that traffic redirected to wherever you were hosting your webmail.