Not quite sure I understand the whole "ephemeral IP address" business.

[James Lampert]

I'm not entirely sure I understand the whole "ephemeral IP address" business, and its ramifications.

We've currently got a Google Compute instance up and running, as our Trac and SVN servers, and as a first stage development server (running both Tomcat and MySQL) for the product we're developing, but now, we're trying to move up to a configuration more like a production installation, with a Google SQL instance, storage buckets, and a load-balanced cluster to actually run the product (in Tomcat).

Now to host an HTTPS server, you obviously have to have it tied to a domain, that you can have as the CN for your SSL certificate. But don't we need to have a static IP address, in order to tie it to a domain? And how does load balancing fit into all that?

Also: I've got the Google SQL instance up and running, and I'm able to connect to it easily with Sequel Pro, from my Mac, using the IP address given in our "SQL overview" page. But I note that this is an entirely different IP address from our existing Compute instance's static IP address (as well it should be, given that it would otherwise collide with the MySQL we've got running on the Compute instance). But it doesn't show up on our "VPC network" static IP address page. Does that mean that it, too, is ephemeral? How ephemeral is ephemeral?

--

JHHL

[Karthick (Cloud Platform Support)]

Hello, 

The Ephemeral IP address remains attached to the VM until you stop it. If the VM is rebooted, it will be assigned a new ephemeral IP. As mentioned here, Ephemeral Ip addresses that are available for forwarding rules can either be external or internal. If the "Address" flag in the forwarding rule is unspecified, "forwaring rule will be automatically assigned an ephemeral external IP address. An example configuration is here. You can also check threads [1][2] for the necessity of static IP over dynamic. Cloud SQL instances have a static IPV4 address automatically assigned to it. The static IP addresses that you are seeing on the "VPC network" are for the GCE instances, kubernetes engine containers and APP engine Flex instances. 

[1] https://stackoverflow.com/questions/15783990/what-exactly-does-every-ssl-certificate-requires-a-dedicated-ip-mean

[2] https://community.spiceworks.com/topic/1984358-is-a-static-ip-necessary-for-servers

[James Lampert]

Thanks. That answers a lot of my questions, but it also raises one:

Consider the planned system: an HTTPS load balancer talking to an instance group running Tomcat servers. Obviously, the load balancer's target proxy is going to need a static IP address, tied to a domain name, and a certificate on that domain name.

But the "Setting up HTTP(S) Load Balancing" page also says that HTTPS is "recommended" for sessions between the load balancer and the instance. How does that work? Are the internal certs self-signed, or CA-signed? And for what CN, when instances are being created and destroyed on the fly? Or does the communication between the load balancer and the instances even care about the CN?

Also, all the docs I've seen so far about this discuss OpenSSL with regard to certificates and keystores. With the possible exception of configuring security for the Apache server on our Trac/SVN instance, 100% of my HTTPS-configuration experience has been with running Tomcat with JSSE, and Java Keystores, generated and maintained using Keytool and Wayne Grant and Kai Kramer's KeyStore Explorer. I know little about OpenSSL beyond its existence. Any insights there?

[Karthick (Cloud Platform Support)]

Hello,

Thank you for your patience while I was looking to find supporting information. HTTPS is recommended to make sure the data is secure from end to end as in encrypted form even from load-balancer to backend servers. We recommend HTTPS to the backend because, at the moment, without it the traffic from the backend going to the VM instance is not encrypted.  It is an added security.  You can check this forum which claims its use. 

Also, as mentioned in the documentation[1], "self-signed certificates are not suitable for public sites, though you can use it. The load balancer selects a certificate whose Common Name (CN) or Subject Alternative name (SAN) matches the SNI hostname specified by the client". RFC 2818 describes two methods to match a domain name against a certificate- using the available names within the SAN extention, or, in the absence, falling back to CN. 

Finally, about the using the Open SSL, you can can check this third party site to generate self-signed certificate.