Category Archives: Ubuntu

Opening up port 80 and 443 for Oracle Cloud servers

Posted on by
Reply

Original: https://dev.to/armiedema/opening-up-port-80-and-443-for-oracle-cloud-servers-j35

Are you working on setting up your Oracle Cloud server and are facing issues with sites rendering as expected? Such as, getting time out issues when navigating to the site’s url?

Before we get into the steps of making port 80 and 443 work properly on an Oracle server, you may be wondering why Cleavr only integrates with some of the free server options and does not provide paid tier options. In short, we wanted to provide users with a free server option and Oracle in one of the few providers that offers a decent free server option. However, the experience to connect with Oracle accounts is very rough around the edges plus these oddities around port connections have led us to delay integrating with Oracle further until their experiences improve.

But, let’s get back to the main issue. When you provision a server via Oracle’s cloud interface, ports 80 and 443 won’t be fully opened until you make the following updates.

Step 1: Add ingress rules

For this first step, you’ll need to access your Oracle Cloud account.

Port 80 and 443 will be closed by default. Assuming you plan to add websites to the server, open port 80 and 443 by clicking on Virtual Cloud Network from the server instance details screen.

setting up ports

Click Security List on the left menu.

![setting up ports]((https://dev-to-uploads.s3.amazonaws.com/uploads/articles/43y5fy5paah81vle9bh8.png)

Click on the security list

setting up ports

Click Add Ingress Rules

setting up ports

Add the following source and port –

setting up ports

Add the ingress rule for port 80. Do the same process for port 443.

At this juncture, you may be led to believe that ports 80 and 443 are opened. Afterall, you just set the ingress rule that opens up the ports.

Not so fast!

It’d be best and most expediant to scan the server ports to make sure that these ports are actually opened to the outside world.

We’ll use Doneo.io’s server port scanning tool to scan the server after making the above updates.

doneo port scan shows 443 is still closed

In the above, we can see that we still have some work to do to open up port 443.

Step 2: Modify iptables

For this step, we’ll need to SSH into the server so we can run some terminal commands.

Run the following commands:



iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT
netfilter-persistent save

This will update the iptables to allow port 443. If port 80 was blocked after performing a port scan, then also run the above but swap out 443 with 80.

Now, run another server port scan to see if 443 is open.

doneo port scan shows 443 is open

We can see from the screenshot above from the Doneo.io port scan that 443 is now open.

Your http and https sites should now be accessible to the public.

Hopefully, this article saves you some time and stress as this can be a frustrating issue to resolve.

Copy Let’s Encrypt certificate to another server after renewal

Posted on by
Reply

Steps:

    1. Set Up Passwordless SSH Access

    Ensure that the server running Let’s Encrypt (Server1) can connect to the target server (Server2) via SSH without a password:

    On Server1, generate an SSH key pair (if not already created):

    ssh-keygen -t rsa -b 4096

    Copy the public key to Server2:

    ssh-copy-id user@server2

    Replace user with the username on Server2.

    2. Create a Script for Copying Certificates

    On Server1, create a script (e.g., copy_cert.sh) to copy the certificate files to Server2:

    #!/bin/bash
    REMOTE_USER="user"
    REMOTE_SERVER="server2"
    REMOTE_PATH="/path/to/certificates"

    scp /etc/letsencrypt/live/yourdomain.com/fullchain.pem ${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_PATH}/
    scp /etc/letsencrypt/live/yourdomain.com/privkey.pem ${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_PATH}/

    Replace yourdomain.com with your domain.

    Replace /path/to/certificates with the directory on Server2 where the certificates should be stored.

    Make the script executable:

    chmod +x copy_cert.sh

    3. Test the Script

    Run the script manually to ensure the certificates are copied successfully

    ./copy_cert.sh

    4. Use Certbot’s --deploy-hook

    Modify the Certbot renewal configuration to include a deploy hook that runs the script after successful renewal. You can add this directly when renewing or use an existing configuration:

    certbot renew --deploy-hook "/path/to/copy_cert.sh"

    Alternatively, edit the renewal configuration file (usually located at /etc/letsencrypt/renewal/yourdomain.com.conf):

    renew_hook = /path/to/copy_cert.sh

    5. Ensure Scheduled Renewal

    Certbot typically installs a cron job or systemd timer for automatic renewal. Verify it:

    For cron: Check /etc/cron.d/certbot.

    For systemd: Check certbot.timer with:

    systemctl list-timers | grep certbot

    6. Restart Services on Server2 (Optional)

    If the certificates are used by a service (e.g., Nginx or Apache) on Server2, modify the script to restart the service:

    ssh ${REMOTE_USER}@${REMOTE_SERVER} "sudo systemctl reload nginx"

    Now, whenever the certificate is renewed on Server1, it will automatically be copied to Server2 and (optionally) reload the relevant service.