How can I generate a SSL certificate for my backend?

Help
1

Hi,

I created my certificates like so:

$ openssl req -new -newkey rsa:2048 -nodes -keyout my-domain.key -out my-domain.csr
$ openssl x509 -req -days 365 -in my-domain.csr -signkey my-domain.key -out my-domain.crt

I then dockerized, then deployed to Google Compute Engine, but, I am still getting this net::ERR_CERT_INVALID while requesting my API from a ReactJs App (Google Chrome)

So I understood than using let’s encrypt could solve my problem, however, I can’t find the way to achieve it (or maybe i am just lost)

I bought a domain “xyz.fr” and from OVH (my provider), i made a AAAA relation between the IP of my backend and “api.xyz.fr” (which points to XX.XXX.XXX.XX:443 where my API listens)
My domain is:

My web server is developed in Go and runs (dockerized) on a Google Compute Engine:

// RunAsRESTAPI runs the API as REST API
func (api *API) RunAsRESTAPI(restAddr string) error {

	// Generate a `Certificate` struct
	cert, err := tls.LoadX509KeyPair( ".certificates/my-domain.crt", ".certificates/my-domain.key" )
    if err != nil {
		return errors.New(fmt.Sprintf("couldn't load the X509 certificates: %v\n", err))
	}

	// create a custom server with `TLSConfig`
	restAPI := &http.Server{
		Addr: restAddr,
		Handler: nil, // use `http.DefaultServeMux`
		TLSConfig: &tls.Config{
			Certificates: []tls.Certificate{ cert },
		},
	}

	// Defining the routes
	routes := map[string]func(http.ResponseWriter, *http.Request){
		"": api.handleIndex,
	}

	// Initialize mux
	mux := http.NewServeMux()

	// Register endpoints handlers
	for route, function := range routes {
		endpoint := "/" + route
		mux.HandleFunc(endpoint, function)
		log.Printf("[%s] endpoint registered.\n", endpoint)
	}

	// cors.Default() setup the middleware with default options being
	// all origins accepted with simple methods (GET, POST). See
	// documentation below for more options.
	restAPI.Handler = cors.Default().Handler(mux)

	log.Printf("REST TLS Listening on %s\n", restAddr)
	return restAPI.ListenAndServeTLS("", "")
}

If I listen on 80 using HTTP, it works like a charm.
If I listen on 443 using HTTPS, it works only from Postman

My hosting provider, if applicable, is:

Google Cloud Platform

I can login to a root shell on my machine (yes or no, or I don’t know): Yes I think so, at least I can SSH into it

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): I think I can do both, quite new to compute engine on google!

Thanks!

2

I believe the idiom in Go is to launch two HTTP servers in separate goroutines, one with .ListenAndServe (port 80), and one with .ListenAndServeTLS (port 443), both pointing to the same handler.

Not sure if this is quite the advice you are looking for. If not, it might help to elaborate upon on precisely what errors you are encountering.

Also, if you’re not already aware, the autocert library makes this waaaay easier: https://godoc.org/golang.org/x/crypto/acme/autocert#example-NewListener

1 Like
3

Hey,

Thanks for your feedback. Ok I could listen on both 80 (HTTP) and 443 (HTTPS) and point to the same handlers, however, I would still have the certificate error from my web client trying to ping the backend :frowning:

Now, about autocert, I just was just about to try out, but I was wondering if I put “api.my-domain.com” would the redirection to 80 or 443 being automatic?

Thanks!

4

Well, you would replace the self-signed certificates with Let's Encrypt certificates, right? That would address the browser SSL error.

No, autocert will only listen on port 443. If you want to setup an *http.Server on port 80 to perform an HTTP-to-HTTPS redirect, you can do that yourself in another goroutine.

But if this Go server is an API for your React app, then you may as well not listen on port 80 at all (unless perhaps you need it for local development). After all, your React app is not going to accidentally try and send API requests to port 80.

5

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