You can technically have an IP address (v4 or v6, it does not matter) in the SAN section of an X.509 certificate, however not without precautions.
Use of certificates using IP addresses
They are rare in the HTTPS world (because they defeat mass HTTPS virtual hosting), but do exist, https://1.1.1.1/ being a famous case.
Using Certificate Transparency Logs searches you can find many more certificates having IP addresses in their Subject Alternative Name extension, here is a link to search for some: https://censys.io/certificates?q=parsed.extensions.subject_alt_name.ip_addresses%3A*
(I was also not able to find a way to search specifically for IPv6 addresses; https://crt.sh/ also has a search criteria on Identify/iPAddress but I was not able to make that one work at all).
They are indeed needed for the newer "DNS over HTTP" and "DNS over TLS" protocols.
Note that:
- for DoT, the certificate does not matter so much as the underlying public key, as the client should have pinned it beforehand
- for DOH there is a discussion about the certificate:
A DoH client may face a similar bootstrapping problem when the HTTP
request needs to resolve the hostname portion of the DNS URI. Just
as the address of a traditional DNS nameserver cannot be originally
determined from that same server, a DoH client cannot use its DoH
server to initially resolve the server's host name into an address.
Alternative strategies a client might employ include 1) making the
initial resolution part of the configuration, 2) IP-based URIs and
corresponding IP-based certificates for HTTPS, or 3) resolving the
DNS API server's hostname via traditional DNS or another DoH server
while still authenticating the resulting connection via HTTPS.
But note that certificates with IP addresses work and existed far before DoT and DoH went mainstream but in another area that is little known: RPKI.
This deals with securing BGP exchanges: when someone announced a given block
of IP addresses, through its RIR from which he got the IP addresses block, it can get a certificate (hence signed by the RIR CA) containing both its IP addresses blocks and its AS number. This enables other to verify that IP addresses are
announced by the correct AS number. See https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure for a primer on all of that.
These certificates are normalized in RFC 6487 and they look like this:
Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer
Data:
Version: 3 (0x2)
Serial: 1500 (0x5dc)
Signature Algorithm: SHA256WithRSAEncryption
Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
Validity
Not Before: Oct 25 12:50:00 2008 GMT
Not After : Jan 31 00:00:00 2010 GMT
Subject: CN=A91872ED
Subject Public Key Info:
[...]
X509v3 extensions:
[...]
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
24021
38610
131072
131074
sbgp-ipAddrBlock: critical
IPv4:
203.133.248.0/22
203.147.108.0/23
Generating the certificate/CSR
See RFC 5280 as womble said in his answer. Make particular attention to the fact that you need to use an "IPAddress" field in the Subject Alternative Name and not the often default/common case of "DNSname" that applies only to names.
That RFC correctly caters for both IPv4 and IPv6 addresses:
When the subjectAltName extension contains an iPAddress, the
address MUST be stored in the octet string in "network byte order",
as specified in [RFC791]. The least significant bit (LSB) of each
octet is the LSB of the corresponding byte in the network address.
For IP version 4, as specified in [RFC791], the octet string MUST
contain exactly four octets. For IP version 6, as specified in
[RFC2460], the octet string MUST contain exactly sixteen octets.
If you control the CA, then it is not a problem to sign the appropriately built CSR. If you want it to be signed by a well-known CA you will then need to find one accepting to do that and while I do not have a list I believe they exist but are not the majority.
Validation by a "reputable" CA
Most CAs, and those recognized by browsers apply the CAB Forum requirements guidelines. Besides other things they describe what kind of validation a CA needs to do based on the content of the certificate to be issued.
See https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf
In your specific case:
7.1.4.2.1 Subject Alternative Name ExtensionCertificate Field: extensions:subjectAltNameRequired/Optional: RequiredContents: This
extension MUST contain at least one entry. Each entry MUST be either
a dNSName containing the Fully-Qualified Domain Name or an iPAddress
containing the IP address of a server. The CA MUST confirm that the
Applicant controls the Fully-Qualified Domain Name or IP address or
has been granted the right to use it by the Domain Name Registrant or
IP address assignee, as appropriate.Wildcard FQDNs are permitted
Section 3.2.2.5 details how an IP address is validated, with the following possibilities (see the document for details):
- 3.2.2.5.1. Agreed-Upon Change to Website
- 3.2.2.5.2. Email, Fax, SMS, or Postal Mail to IP Address Contact
- 3.2.2.5.3. Reverse Address Lookup
- 3.2.2.5.4. Any Other Method (which is now moot because of "CAs SHALL NOT perform validations using this method after July 31, 2019.")
- 3.2.2.5.5. Phone Contact with IP Address Contact
- 3.2.2.5.6 ACME “http-01” method for IP Addresses
- 3.2.2.5.7 ACME “tls-alpn-01” method for IP Addresses
Especially for the last two points, you will see more details also at https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-04#section-4 which in fine references the ACME protocol recently published as an RFC: https://www.rfc-editor.org/rfc/rfc8555
Little dark corner of CAB Forum guidelines
There are some points that are not often well known nor spectacularly enforced by CAs. But in summary they should revoke any certificate as soon as the underlying properties do not validate anymore. For example if a domain is not renewed by current owner and registered by another one, then the existing certificate should be revoked.
The same happens for IP addresses: if the block owner changes, the existing certificates should be revoked.
