SSL/HTTPS for a Google Domain [compute engine Ubuntu]

Using port 80 and a cert seems like a contradiction.
Where did you get that command?

You probably need to choose an ACME client [that will obtain the cert and renew it for you].
Then use it [on port 443].

3 Likes

I'm not the certbot expert but I'd expect something like sudo certbot certonly --standalone -d pod.danielbakas.com because your first task is to get a cert and for that you need to prove you control the domain over http, but you don't have a web server running yet so the 'standalone' part spins a temporary one up for you, to serve the challenge response. Give it a try. If it works you'll end up with the files on disk.

Note that once you have a cert the aim would be to automate how that gets renewed (the certs expire after 90 days)

5 Likes

Really a service like this should be more than capable of getting and renewing it's own cert, we're living in the future after all.

4 Likes

I was using port 80 because I hadn't been using a cert. I guess now that I'll be using a cert I'll probably be switching to 443.

That command comes from the documentation at the Community Solid Server repo, specifically from this issue I opened.

Could I ask something over at the GitHub or Solid Forum to ask what type of server runs with that command? Maybe that could help to know whether I need apache or something else :nerd_face:

1 Like

Okok let me try that command right now

2 Likes

Is it installed?
What version is it?
certbot --version

If not installed, see:
Certbot (eff.org)

2 Likes

@rg305 @webprofusion this command worked like a charm. Certbot generated these files

`privkey.pem`  : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

Would you then say I use:

  • privkey.pem for the --httpsKey flag
  • fullchain.pem for the --httpsCert

?

1 Like

Sounds great. Once you have it running you will want to figure out how (and how often) to repeat this process for renewals.

4 Likes

Got an INVALID_URL error :melting_face:

I shared the error on the GitHub issue

I feel we're really so close :face_holding_back_tears::pray:t4:

Can it sit behind a proxy?
Putting one inline would be quite simple/almost trivial.

3 Likes

We can certainly try! How could this be done? :star_struck:

I'd recommend installing nginx and using it with certbot to host the HTTP site [to validate the HTTP-01 authentication requests] and also host the HTTPS [via proxy] to your HTTP [insecure] application.

You could also use certbot in --standalone mode to "host" the HTTP-01 authentication requests.
And just use nginx for the secure proxy.

3 Likes

Which one would be simpler? I'm browsing YouTube for tutorials on how to do this :grin::pray:t4::seedling:

Also worth looking at Caddy (which is a newer type of web server) as a reverse proxy because it has automatic https renewal built in: Reverse proxy quick-start — Caddy Documentation

4 Likes

Caddy seems pretty straightforward :star_struck:

Would something like this make sense? caddy reverse-proxy --from pod.danielbakas.com --to :80

No, so when you reverse proxy one app is your front end service and the other is an invisible back end service.

So in this case you might want your solid app to be running on say port 8080, or some other non-default port, probably as http only (no SSL configured, but that's optional). This is your back end service.

Then caddy (acting as your front end service) answers http and https request (on port 80 and port 443 respectively) and forwards them to your app. So your app is never talking directly to the internet, caddy (or which web serer you want to use) is doing that for you.

So, first get your solid app running on a port that's not public (8080 was just a suggestion), make sure that works, then get caddy working.

I think the simplest command is caddy reverse-proxy --to :8080 which will proxy any incoming https request and forward it to your app, if your app is running on 8080. Note that this is just to test, to actually be able to reboot your server and have everything work you need to setup caddy as a service (Keep Caddy Running — Caddy Documentation)

6 Likes

I'm trying to read the docs to understand whether a proxy is actually needed, since Solid servers provide config files where (I think) they implement proxys internally when you use a certain configuration.

Look at this comment from my issue on Run CSS on secure HTTPS? · Issue #1522 · CommunitySolidServer/CommunitySolidServer · GitHub

And using a specific config "Adds CLI options --httpsKey and --httpsCert and uses those to start an HTTPS server."

Maybe not, what we're trying to do is save you time.
A proxy can resolve the issue now.
There is no telling if, or when, you might get it working without one.

5 Likes

You're really kind! And it seems I just got it to work with HTTPS and without a proxy!!! :face_holding_back_tears::sob::partying_face:

I could have never done this without you. I appreciate what you just did and helped me with. This really means a lot and I thank you profoundly.

I send you the warmest and kindest thanks, and hope you are well.

Take care @rg305 and @webprofusion. You were patient, generous and really helpful!

Daniel

4 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.