IPv6 Address in SSL Certificate

Solution 1:

Yes, the subjectAltName extension allows an iPAddress OID, which may contain an IPv6 address as 16 octets in network byte order. See RFC5280 s4.2.1.6 for more details.

Solution 2:

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://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4 which in fine references the ACME protocol recently published as an RFC: https://tools.ietf.org/html/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.

Solution 3:

Regarding production use, cloudflare-dns.com is more commonly known as 1.1.1.1. The cert's SANs include the IPv4 and IPv6 addresses of the service.

I suspect a reason for such a cert is to implement DNS over TLS. Also responsive to https, you can see the cert in your browser: https://[2606:4700:4700::1111]

Implementations supporting subjectAltName but not v6 iPAddress is a bug.

There are few examples of iPAddress certs requests out there, and even fewer with v6. Thanks to FreeIPA for testing v6 when they recently added IP address certs. Cert request can be generated with NSS like so:

certutil --extSAN dns:host.example.com,ip:2001:db8:3902:3468::443

Solution 4:

There is a project to give a name to every IPv6 address. They have a corresponding Docker image that runs Let's Encrypt on those names. This is not exactly the same as "a cert for an IPv6 address" but it is pretty close and it is automated.

  • https://ungleich.ch/u/blog/has-a-name-for-every-ipv6-address/
  • https://ungleich.ch/u/blog/fully-automated-ssl-certificates-for-docker/

Tags:

Ipv6

Ssl Certificate

Recent Posts