How to Install a Certificate and Enable HTTPS on Ubuntu Server

The short answer: to enable HTTPS on Ubuntu Server, point a domain name at the server, install a web server such as Nginx or Apache, then use Certbot to get a free, publicly trusted certificate from Let's Encrypt. Certbot can also update your web server configuration and set up automatic renewal. After that, confirm that the site loads over HTTPS and that renewal works.

One distinction changes the steps. If the server has a public domain name that resolves to it, follow the Certbot steps below. If the server only runs on a local network or lab machine without a public domain, Certbot's standard method usually cannot issue a certificate. In that case, use a self-signed certificate, as described near the end.

Why HTTPS matters for camera and microphone pages

Modern browsers only let web pages request the camera and microphone in a secure context. A secure context is a page served over HTTPS, or a page opened from the local machine itself (localhost). On a plain HTTP page reached by a server name or IP address, the browser does not offer the camera API at all. You will not see a permission prompt in that case.

Enabling HTTPS only makes the browser able to ask. It does not grant access. The visitor still has to allow the camera or microphone in the browser prompt. The operating system's privacy settings must also allow that browser to use the device. And getting access is a separate question from successful video capture or good call quality. A camera can be permitted and still show a black frame. A microphone can be detected and show input activity while still producing sound that is hard to understand.

Before you start

• Shell access to the Ubuntu Server with a user that can run sudo.
• A domain or subdomain whose DNS record points to the server's public IP address.
• Inbound ports 80 (HTTP) and 443 (HTTPS) reachable from the internet, including any cloud firewall or router rules outside the server.
• A web server installed, or permission to install one. The examples use Nginx, with Apache alternatives noted.

In the commands below, replace YOUR_DOMAIN with your actual domain name.

Step 1: Allow web traffic through the firewall

If you use UFW, Ubuntu's built-in firewall front end, allow HTTP and HTTPS. Port 80 needs to stay open because Certbot's default check uses it to confirm that you control the domain. Allow SSH as well before enabling UFW, so you do not lock yourself out.

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

For Apache, the profile name is 'Apache Full' instead of 'Nginx Full'. Install the web server first, because the profile only appears after installation.

Step 2: Install the web server and set the server name

sudo apt update
sudo apt install nginx

Certbot finds the right site by matching the server_name directive. Open the site configuration, for example /etc/nginx/sites-available/default, and set server_name to your domain. Then test the configuration and reload Nginx.

server_name YOUR_DOMAIN;

sudo nginx -t
sudo systemctl reload nginx

For Apache, install it with sudo apt install apache2. Set the ServerName directive in your site's virtual host file instead of server_name.

Step 3: Install Certbot

Certbot is the client that requests and renews Let's Encrypt certificates. Its maintainers recommend installing it as a snap package, which Ubuntu Server normally supports.

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Ubuntu's own repositories also include Certbot. You can install it with sudo apt install certbot python3-certbot-nginx, or python3-certbot-apache for Apache. That version may be older than the snap.

Step 4: Obtain and install the certificate

sudo certbot --nginx -d YOUR_DOMAIN

For Apache, use sudo certbot --apache -d YOUR_DOMAIN. To cover more than one name, such as a bare domain plus its www version, repeat the -d option for each name.

The first time, Certbot asks for an email address for expiry and security notices, and asks you to accept the terms of service. It then confirms that you control the domain, installs the certificate, and edits your web server configuration to use it. Depending on the version, it may also set up a redirect from HTTP to HTTPS. If it asks whether to redirect, choosing the redirect is usually right. That way, visitors who type the plain address still end up on the secure version, which pages using the camera need.

Step 5: Confirm automatic renewal

Let's Encrypt certificates expire after a short period, so they must be renewed regularly. The Certbot snap installs a timer that handles renewal automatically. Run a simulated renewal to make sure it will work.

sudo certbot renew --dry-run
sudo certbot certificates

The first command should finish without errors. The second lists each certificate, the names it covers and its expiry date.

Step 6: Verify that HTTPS works

• Open the site in a browser using the HTTPS address. The address bar should show the secure indicator, with no certificate warning.
• Open the plain HTTP address and check that it redirects to HTTPS, if you enabled the redirect.
• Open the browser's developer console on the page and type window.isSecureContext. It should return true, which means the page can request camera and microphone access.
• From the server or another machine, inspect the certificate the server presents (see the command below).

openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN </dev/null | openssl x509 -noout -subject -issuer -dates

If the page uses the camera, test the full chain after HTTPS works. Confirm that the browser shows a permission prompt, then that a live image appears, then check the image and sound quality on a real call. Each step can fail separately.

If you have no public domain: self-signed certificate

For a server on a local network, a self-signed certificate encrypts traffic, but browsers do not trust it automatically. You can create one with OpenSSL. The subjectAltName entry matters because current browsers check that field instead of the older Common Name. The key size and validity period below are common choices, not requirements.

sudo openssl req -x509 -nodes -newkey rsa:2048 -days 365 \
  -keyout /etc/ssl/private/selfsigned.key \
  -out /etc/ssl/certs/selfsigned.crt \
  -subj "/CN=YOUR_SERVER_NAME" \
  -addext "subjectAltName=DNS:YOUR_SERVER_NAME"

If you reach the server by IP address, use IP:YOUR_SERVER_IP in the subjectAltName value instead of DNS:YOUR_SERVER_NAME. Then add an HTTPS server block to Nginx, test the configuration and reload it.

server {
    listen 443 ssl;
    server_name YOUR_SERVER_NAME;

    ssl_certificate     /etc/ssl/certs/selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/selfsigned.key;

    root /var/www/html;
}

sudo nginx -t
sudo systemctl reload nginx

Visitors will see a certificate warning until each device trusts the certificate. Browsers differ in which features they allow after someone clicks past that warning. For dependable camera and microphone testing, import the certificate into the trust store of each test device or browser, then confirm that window.isSecureContext returns true. If you only test on the server machine itself in a desktop browser, a page opened through localhost already counts as a secure context without any certificate.

Common problems

Symptom | Likely cause | What to check

Certbot fails domain validation | DNS does not point to this server, or port 80 is blocked | DNS record, UFW rules, cloud or router firewall

Certbot cannot find a matching server block | server_name or ServerName not set to the domain | Site configuration file, then reload the web server

Browser shows a certificate warning | Self-signed certificate, or a name that does not match the certificate | Certificate subjectAltName and the address you typed

HTTPS works but camera prompt never appears | Page or an embedded frame still loaded over HTTP, or the site's permissions are blocked in the browser | window.isSecureContext, mixed content warnings in the console, site permission settings

Prompt appears but no image | Camera in use by another app, or blocked in operating system privacy settings | OS camera permissions and other open apps

Limits of this guide

No specific Ubuntu release, Certbot version or hosting setup was provided, so the commands reflect common defaults on current Ubuntu Server releases. Package names, firewall profile names and where Certbot places its redirect can differ on older systems or custom setups. Certificate lifetimes and renewal intervals are set by the certificate authority and can change. Rely on the expiry dates that sudo certbot certificates reports, not a fixed number.