0

I am utterly failing to find a working guide for installing Let's Encrypt certificates on a single Google Cloud virtual machine.

I'm pretty clearly getting the picture that just doing the Apache webserver configuration isn't enough.

The information here, https://cloud.google.com/load-balancing/docs/ssl-certificates , seems to assume I'm doing load balancing--um, I'm on a tight budget here so it's only the one virtual machine. No load balancing.

I found some gcloud commands somewhere which I translate as:

  • gcloud compute ssl-certificates create partsunknownorg --certificate=/etc/letsencrypt/live/parts-unknown.org/fullchain.pem --private-key=/etc/letsencrypt/live/parts-unknown.org/privkey.pem
  • gcloud compute target-https-proxies update partsunknownorg --certificate=/etc/letsencrypt/live/parts-unknown.org/fullchain.pem --private-key=/etc/letsencrypt/live/parts-unknown.org/privkey.pem

I used the first one to try to install the certificates; I gather I should use the second to update them. Is that right?

In any event, it seems not to have worked. And I'm baffled.

David Benfell
  • 1
  • 3
    If you have only a single virtual machine, why are you bothering with instructions for a load balancer (which presumably you don't have)? Or anything unusual at all? Just install Let's Encrypt normally. Being on Google Cloud isn't even relevant in your scenario. – Michael Hampton Mar 29 '19 at 12:47
  • 2
    If you're not using Google's load balancers, don't use any of the `gcloud` commands. Just follow a Let's Encrypt tutorial for your Linux distribution. *edit:* Argh, too slow! :-p – ceejayoz Mar 29 '19 at 12:47
  • Being on Google Cloud seems to be extremely relevant. I'm flat out getting SSL protocol errors with a configuration that worked when I wasn't on Google Cloud. As near as I can tell, I need to facilitate a man-in-the-middle here, the "man" being Google Cloud, but I can't tell how to feed it the keys. I tried looking at Google's SSL service, but that doesn't make any sense either. – David Benfell Mar 29 '19 at 15:39
  • For what it's worth, I also had to feed it ssh keys--editing ~/.ssh/authorized_keys file like I've done since time immemorial leads to a situation where ssh simply stops working. – David Benfell Mar 29 '19 at 15:42
  • 3
    There shouldn't be any man in the middle. Your domain should be pointed directly at the instance's IP if you're not using load balancing. The SSL error is probably a misconfiguration on your part. Follow a LE tutorial for your distribution, then test it out using something like https://www.ssllabs.com/ssltest/ and see what issues they report. – ceejayoz Mar 29 '19 at 16:05
  • There absolutely is a man-in-the-middle. Google doesn't provide these instances with direct access to routable IP addresses. One attaches an external (routable) address through their web configuration and this man-in-the-middle forwards the traffic. That's the way they do it, which I assume offers a layer of security, but complicates end-to-end cryptography. – David Benfell Mar 29 '19 at 17:15
  • You assume incorrectly, to my knowledge. Calling Google's external IP implementation a "man in the middle" isn't accurate. – ceejayoz Mar 29 '19 at 20:27

0 Answers0