How to Use HTTPS with an IP Address and Port

The short answer

You can open a site over HTTPS using a machine's IP address instead of a domain name. Type the scheme "https", then the IP address, then a colon and the port number if the server isn't on the standard HTTPS port, 443. If it is on 443, leave the port out. Typing the right address only gets you part of the way, though. The connection is trusted only if the server presents a certificate that lists that exact IP address and your browser or operating system trusts whoever issued it. Without that, you get a security warning. For camera and microphone testing, that warning can decide whether the browser lets the page ask for access at all.

"The machine's IP address" can mean two different things, and the setup differs for each:

• A private (local network) address, such as a laptop or small server on your home or office network. Publicly trusted certificate authorities don't issue certificates for private addresses, so you need a self-signed certificate or your own local certificate authority, and you have to trust it on every device that connects.
• A public address, reachable from the internet. Some certificate authorities issue certificates for public IP addresses, but not all do, and terms vary. Check with your provider. A domain name pointing at that IP is usually the simpler and better-supported route.

Why this matters for cameras and microphones

Browsers only allow camera and microphone access in a "secure context". In practice, a secure context is a page loaded over HTTPS, or one loaded from the machine itself through localhost. A page opened over plain HTTP using a network IP address is not a secure context. In that case the browser won't show a permission prompt, and the page can't reach the camera or microphone. This is why a video-call test page might work on the computer running it but fail on a phone or a second computer that opens it by IP address.

There are three separate stages, and each can fail on its own. First, the browser allows the page to request the camera or microphone. Second, a video image actually appears and the microphone picks up input. Third, the call looks and sounds good. HTTPS only solves the first stage. Lighting, a muted or wrong input device, and network quality are separate issues.

Step-by-step setup

1. Find the machine's IP address

Run one of these on the machine that hosts the page. Use the address on the network your other devices share, not the loopback address.

Windows:   ipconfig
macOS:     ipconfig getifaddr en0
Linux:     hostname -I

On macOS the network interface may not be named en0. If that command returns nothing, check your active interface in the network settings.

2. Create a certificate that includes the IP address

The IP address has to appear in the certificate's Subject Alternative Name (SAN) field. The SAN is the list of names and addresses a certificate is valid for. Modern browsers ignore the older "common name" field for this check, so a certificate that only has the IP there will still be rejected. With OpenSSL 1.1.1 or newer, you can create a self-signed certificate like this, replacing the placeholder with your actual address:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout key.pem -out cert.pem -days 365 \
  -subj "/CN=YOUR_MACHINE_IP" \
  -addext "subjectAltName=IP:YOUR_MACHINE_IP"

If you'll connect from several devices, a local certificate authority is easier to manage. You create one root certificate, trust it once on each device, and use it to sign certificates for your machines. Several development tools automate this. Whichever method you use, the certificate must be reissued if the machine's IP address changes, so a reserved or static address on your router saves trouble.

3. Configure the server to use HTTPS on your chosen port

Point your web server or development server at the certificate file and the private key file. How you do this depends on the software, so check its HTTPS or TLS settings. Also check two common sources of trouble:

• The server must listen on the network interface, not only on localhost. Many development servers bind to localhost by default, which makes them unreachable by IP address from other devices.
• The port must actually serve HTTPS. If you type "https" in front of a port that serves plain HTTP, the browser shows a protocol or connection error, not a page.

4. Open the firewall port

Allow inbound connections on that port in the host machine's firewall. If the page loads on the host but times out from other devices, the firewall is a likely cause.

5. Trust the certificate on each connecting device

Install the self-signed certificate, or your local root certificate, into the trusted store of each device and browser that will connect. Desktop operating systems, phones and some browsers keep separate trust stores, so the exact steps vary. Only trust certificates you created yourself. Trusting an unknown root certificate lets whoever controls it impersonate any site to that device.

Some browsers let you click past a certificate warning. Whether camera and microphone access then works differs between browsers and versions, so don't count on it. Trusting the certificate properly gives consistent results.

6. Connect using the IP and port

In the address bar, enter "https", a colon and two slashes, the IP address, then a colon and the port number. Skip the colon and port if the server uses 443. Don't add "www" or any other prefix, because those only apply to domain names.

How to verify it worked

• The browser shows a secure-connection indicator and no certificate warning.
• In the browser's developer console, the expression window.isSecureContext returns true.
• The page triggers a camera or microphone permission prompt. If you previously blocked access, reset it in the site permission settings.
• After you allow access, a live video image appears and the microphone input level moves when you speak. Then make a short test recording or call to check whether the picture and sound are actually clear.

window.isSecureContext

A temporary workaround for local testing

Chromium-based browsers have a developer setting that treats a specific insecure origin as secure. It is meant for development only. It turns off a protection for that origin, it affects only the browser where you set it, and its location or behavior may change between versions. Use it for quick tests on your own equipment, not as a replacement for a real certificate.

What this guide can't confirm

No device-, browser- or version-specific test results were available for this guide. Menu locations, how browsers handle certificate warnings, and which certificate authorities issue certificates for public IP addresses can all change. Check those details against your browser's and provider's current documentation.