Certificate for an API server

In order to understand my question, I need to start by explaining what I'm trying to do.
I have a web app that's split in two parts:

  1. I have a React app that's hosted on a web hosting service and has a valid SSL certificate provided by the hosting service.
  2. I have a Java (SpringBoot) application that I host on a Google Compute Engine VM running Debian 10 (my database is on this VM too). The Java application is a REST API server.

I press a button on the website, the React app sends a HTTP request to my Java app, which sends back a response.
I went ahead and setup a subdomain (api.mydomain.ro) that "redirects" to the IP of my Java application, so I can use the subdomain for the requests rather than an IP address.
However, this is all HTTP, so these calls don't go through on the HTTPS version of my website.

When I run certbot on the Google VM to generate a SSL certificate for my Java application it asks for a domain.
I can think of 3 domains that it could ask for, but it's not giving me any details. (all 3 of these have SSL enabled)

  1. I have the main domain (domain.ro / www.domain.ro), there's nothing on this one. My application doesn't use this domain at all.
  2. I have the subdomain where my React app is actually deployed / displayed (subdomain-name.domain.ro)
  3. I have the subdomain where I make the API calls to, that "redirects" to the IP address of my Java application (api.domain.ro)

Which of these is certbot asking for in order to generate a certificate for my Java application so I can use HTTPS endpoints for the API? The domain and the 2 subdomains have working SSL certificates generated by the hosting service. Am I supposed to use one of those to secure my Java application? I've spent 2 days trying to learn about certificates, and all I've managed to do is break my VM twice (generating a certificate that doesnt work, removing it which breaks the apache webserver)

2 Likes

This really depends on you.
If you want the simple way, use the subdomain / domain that's pointed to the instance.

I'm rather confused on this part, what exactly do you mean that it redirects to the IP?
For example, if you make a request to api.mydomain.ro, does it ends up being redirected (either 301 or 302 or whatever) to your IP hostname? Or it's simply pointing to the IP of your instance?

2 Likes

Initially, when I tried to generate the certificate, it wasn't going through, giving me an error about the A/AAAA DNS records. I googled that and I found a lead sending me to the "Zone Editor" in cPanel, and adding an A record there. After doing so, if I make an API request to api.mydomain.ro it does work (it gets to the Java application, and the response gets back to the React app and the browser)

2 Likes

In that case, you can and should proceed to secure your API endpoint, which is your API subdomain.
I'm not sure whether you'll need a Apache proxy or not, since I have minimal experience on Java API webserver. But you should attempt to deploy your certificate in a webserver (such as nginx or Apache) where you can reload relatively easy and able to handle the acme validation before it reach your Java application.

2 Likes

Where is certbot running?
Which authentication method are you using?

If certbot is on server A and you are going to do HTTP authentication, then certbot can only do the FQDN for server A.
If you also need a cert for server B, then certbot will also have to run on server B.

If neither server A nor server B are required to use HTTP, then I would try moving your app services to another port (like 81). That way certbot can run using --standalone (this can greatly simplify the cert process). So on your other services you end up with ports:
80 for certbot
81 for app via HTTP [can be any other port and closed after HTTPS is active]
443 for app via HTTPS [or any other port you like]

2 Likes

Certbot is running on the same server as the Java application. The communication between the two servers is done through HTTP (RESTful API), however they don't use port 80 for the communication.

2 Likes

Then if port 80 is free, you can use certbot with --standalone for authentication.

Try:
certbot certonly --standalone -d "YOUR.FQDN" --keep-until-expiring

[requires port 80 to be open]

2 Likes

I have a confession to make. The reason I thought my certificate wasn't working was because I was listening to port 8433 and sending my requests to port 8443. Everything works fine. Thanks everyone.

3 Likes