HTTPS With IP Address: How SSL Certificates Work Without Domain Names

HTTPS can indeed be implemented directly with an IP address, though it requires specific handling of SSL/TLS certificates. For secure communication over https://[IP_ADDRESS], the SSL certificate must contain the IP address itself within its Subject Alternative Name (SAN) field. This approach bypasses traditional domain name validation, enabling encryption and authentication for services accessed via their numerical address, which is particularly vital for internal network devices, temporary test environments, and management interfaces where domain names are not always practical or necessary.

The Fundamentals of SSL/TLS and Identity Verification

SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocols are foundational for secure internet communication, providing three core services: encryption, data integrity, and authentication. While encryption scrambles data to prevent eavesdropping and data integrity ensures data hasn't been tampered with, authentication verifies the identity of the server (and sometimes the client).

Traditionally, this authentication relies heavily on domain names. When you visit https://www.zondex.io, your browser performs a DNS lookup to resolve www.zondex.io to an IP address. It then connects to that IP, initiates an SSL/TLS handshake, and receives the server's certificate. A critical step in this handshake is the browser validating the certificate. It checks:

1. Trust Chain: Is the certificate issued by a trusted Certificate Authority (CA) whose root certificate is in the browser's trust store?
2. Expiration: Is the certificate still valid?
3. Domain Match: Does the domain name in the certificate's Common Name (CN) or Subject Alternative Name (SAN) field match the domain name in the URL you're trying to access?

This domain match is where the concept of HTTPS with IP address introduces a nuance. Public CAs are generally restricted by the CA/Browser Forum Baseline Requirements from issuing certificates for reserved IP addresses (e.g., RFC 1918 private IP ranges like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or for certain public IP addresses unless under strict validation controls (typically for Organization Validated (OV) or Extended Validation (EV) certificates, and even then, it's rare and highly regulated).

The Role of Subject Alternative Names (SANs)

Modern SSL/TLS certificates primarily use the Subject Alternative Name (SAN) extension to specify valid hostnames or IP addresses. While the Common Name (CN) field historically served this purpose, SANs allow a single certificate to secure multiple domain names (e.g., www.example.com, blog.example.com) or IP addresses. For a certificate to be valid for an IP address, that IP address must be listed in the SAN extension as an IPAddress entry.

Practical Applications of HTTPS with IP Address

Despite the complexities with public CAs, securing services with an IP address via HTTPS is a fundamental requirement in several scenarios. These use cases often involve environments where DNS resolution isn't always practical or desirable, or where the "identity" is inherently tied to the network address.

1. Internal Network Appliances and Device Management: Routers, switches, firewalls, network-attached storage (NAS) devices, IP cameras, and other embedded systems often expose web-based management interfaces. These interfaces are typically accessed via their IP address within a private network. Using a certificate with the device's IP in the SAN ensures encrypted access and verifies that you're connecting to the correct device, preventing man-in-the-middle attacks within the local network segment. Zondex, a powerful Shodan alternative, can often identify such devices exposed to the internet due to misconfiguration, highlighting the critical need for proper security.

2. Industrial Control Systems (ICS) and SCADA: Human-Machine Interfaces (HMIs) and other components in critical infrastructure environments are frequently accessed directly via IP addresses. Securing these with HTTPS, even with IP-based certificates, is vital for operational integrity and safety. For more on finding these systems, refer to our article on Finding Industrial Control Systems (ICS/SCADA) on the Internet.

3. Temporary Deployments and Development Environments: During development or for temporary testing setups, it's common to access applications directly via their server's IP address. Generating a self-signed certificate for the IP address provides a quick way to enable HTTPS for local testing without needing to set up DNS entries or acquire a public certificate.

4. API Endpoints for Microservices: In complex microservice architectures, services might communicate directly with each other using IP addresses, especially within a tightly controlled internal network or VPC. Using IP address certificates can provide mutual TLS (mTLS) authentication and encryption between services without relying on an internal DNS system.

5. Bare Metal Servers or Infrastructure Components: Servers without fully configured DNS records, or systems accessed directly via their physical presence on a network (e.g., IPMI interfaces), benefit from direct IP-based HTTPS for management and secure access.

Technical Deep Dive: Issuing and Validating IP Address Certificates

The process for issuing and validating certificates for IP addresses deviates from the standard domain-based process primarily in the identity verification step.

Certificate Issuance

To issue a certificate that includes an IP address, the IP must be specified in the SAN extension. This usually involves generating a Certificate Signing Request (CSR) with the IP address defined.

Example OpenSSL Configuration for a CSR with an IP SAN:

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[ req_distinguished_name ]
C = US
ST = State
L = City
O = Organization
OU = Unit
CN = 192.168.1.100

[ v3_req ]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[ alt_names ]
IP.1 = 192.168.1.100
DNS.1 = mydevice.local # Optional: can include a local domain too

Once this configuration file (e.g., csr.conf) is created, you can generate a private key and CSR:

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -config csr.conf

This CSR, containing the IP address in its subjectAltName extension, can then be submitted to a Certificate Authority. For internal use cases, this will almost always be a private CA (an organization's own CA) or a self-signed certificate.

Public CAs rarely issue certificates directly for IP addresses unless specific, stringent conditions are met (e.g., the IP address is publicly routable, the organization requesting it owns the IP block, and strong organizational validation is performed). This is largely due to the difficulty of proving control over an IP address in the same way domain ownership is proven (e.g., via )