SSL Certificate for IP Address

SSL certificates are commonly associated with domain names, but they can also be used to secure services accessed directly through an IP address. However, securing an IP address comes with specific requirements that differ from standard domain-based certificates.

A public, static IP address owned and controlled by your organization can be secured with an SSL certificate, provided it meets the applicable validation requirements. Not all IP addresses are eligible, and not every SSL certificate supports IP address-based authentication.

The one boundary to know upfront: private and reserved IP addresses, like 192.168.x.x or 10.x.x.x, aren’t eligible for a publicly trusted certificate.

This guide explains which IP addresses can be secured, which SSL certificates support IP addresses, the requirements you need to meet, and how to obtain an SSL certificate for an IP address.

Also, read The Risk of Self Signed SSL certificates

Now let’s get deeper into the individual subsets to learn further.

SSL certificate for Public IP address

Any IP address that is accessible over the internet is a Public IP address. These are the guidelines and necessities to get an SSL certificate for a public IP address:

1) Your association must prove the ownership of that specific IP address. I.e. the IP address must be only relegated to your association (not to the web hosting company) — and you must control the entire IP address, not just a specific port on it.

2) A certificate authority must have the option to check your IP proprietorship under an IP WHOIS query. Your association name, physical location, telephone number, and email id should appear in the IP WHOIS query.

3) Both Domain Validated and Organization Validated certificates can be issued for a public IP address — including single-domain and multi-domain SSL. Extended Validation (EV) is the one type that’s never permitted for an IP address, regardless of certificate authority.

4) You can compose an IP address in the Common Name (CN) or a Subject Alternative Name (SAN) field (if you have picked a multi-domain SSL) — and it’s fine to mix an IP address SAN entry with regular domain names on the same non-EV multi-domain certificate.

5) Validation happens through HTTP File-Based Domain Control Validation (DCV). The CA provides a verification file that you need to create and upload to a specific path on your server, typically: http(s)://yourdomain.com/.well-known/pki-validation/fileauth.txt

You also need to add the target value provided by the CA to the TXT file before uploading it to the specified path. The target value will be provided during the validation process, for example: scxmwngpx71gqtp55qj3ng2rngnz807c

This allows the CA to confirm that the specific IP address belongs to you and that you have access to upload the authentication file before issuing the certificate. File-based authentication is mandatory for IP verification. For Organization Validation, the verification process is the same as for an SSL certificate. For private IP addresses, however, there is no validation required; a request is sent to our DigiCert account for approval, after which the certificate is issued.

6) Windows compatibility varies by field: all supported versions of Windows accept an IP address in the Common Name (CN), but Windows 8.1 and earlier don’t recognize an IP address placed in the Subject Alternative Name (SAN) field — only Windows 10 and later do.

SSL Certificate for Private IP address:

An internal IP (aka private IP) is an IPv4 or IPv6 address that the IANA has set apart as saved, for example:

• Any IPv4 address in the RFC 1918 range (e.g. 10.0.0.0, 172.16.0.0, 192.168.0.0)
• Any IPv6 address in the RFC 4193 range

Since 2016, the CA/Browser Forum (the industry body that sets baseline rules for all public Certificate Authorities) has barred certificates for reserved IP addresses and internal server names entirely, and required CAs to revoke any that already existed. Reserved IPs and internal names aren’t globally unique, so they’re too easy for an attacker to impersonate in a man-in-the-middle attack — which is exactly the risk SSL is meant to prevent. You can check this complete guide on private IP addresses.

SSL Cert Alternative for internal IP Address

Get ready for running your own enterprise CA — nonetheless, this accompanies the expenses of obtaining, designing, and running your own CA and OCSP administrations. A Private Certificate Authority — set up using something like HashiCorp Vault or an internal OpenSSL-based CA — can issue and manage these certificates for you inside your own infrastructure.

Utilizing self-signed SSL Certificates — notwithstanding, this is just acceptable in constrained conditions (for example test servers). A tool like OpenSSL can generate one directly on your server. It instructs clients to overlook significant program alerts that can prompt security issues if they acknowledge self-marked certificates outside of their organization.

How to get an SSL Certificate for an IP address

The process comes down to four steps:

1) Generate a CSR — Create a Certificate Signing Request on your server, with your public IP address placed in the Common Name (CN) or SAN field.

2) Submit your order — Provide the CSR to your chosen Certificate Authority.

3) Pass file validation — Download the verification token file the CA provides, and upload it to your web server under the /.well-known/pki-validation/ directory so the CA can confirm it over HTTP/HTTPS.

4) Install the certificate — Once validated, download the certificate bundle and install it on your web server configuration (Nginx, Apache, or IIS).

To get your SSL certificate you can reach out to your existing SSL certificate vendor. Alternatively, reach out to a leading SSL certificate provider and we will help you expedite the process to get SSL for your IP address.

Restriction on SSL Certificate for IP address

On the off chance that you conclude that you truly need an IP in your cert there are explicit stipulations to consider. The greatest obstacle for most people is that the IP address must be explicitly doled out to your organization or association (not your ISP or facilitating supplier) as checked by an IP WHOIS query.

The limitation imposed by Public CAs are;

1. Open IP tends to just (e.g., 18.236.49.115)
2. Private IP addresses are not permitted (e.g., 10.0.0.0)
3. The IP must show your association’s lawful name and area in an IP WHOIS query
4. Only Organization Validated (OV) certificates can be issued (DV and EV certs can’t be issued)
5. Single domain and multi-domain certs are allowed.
6. The IP can be the Common Name (CN) or a Subject Alternative Name (SAN) field

People Also Ask:

Can I get an SSL certificate for an IP address?

Yes — for a public, static IP address, from a CA willing to issue Domain or Organization Validated certificates for IPs. Extended Validation is never available for an IP address, and private or reserved IP addresses (like 192.168.x.x or 10.x.x.x) can never get a publicly trusted certificate at all — see the private IP section above for your alternatives.

Is an SSL certificate tied to an IP address?

Not usually. Most SSL certificates are tied to a domain name, not an IP address. An IP-based certificate is the exception — issued specifically with the IP address in the Common Name or Subject Alternative Name field, for cases where there’s genuinely no domain involved.

Can I mix an IP address with domain names on the same certificate?

Yes. You can add an IP address as a SAN entry alongside regular domain names on any non-EV multi-domain certificate, as long as the IP itself still meets the usual requirements — public, under your organization’s control, and verifiable through file-based validation.

How do I get my SSL certificate?

Generate a CSR with your IP address in the Common Name or SAN field, submit it to your chosen Certificate Authority, complete file-based domain control validation, and install the certificate bundle on your web server once it’s issued. Reach out to us and we’ll help you through each step.