Is it at all possible to obtain an SSL certificate for an IPv6 address, for example https://[1234:5678:9000:abcd:9876:5432:10ab:cdef]? If so, are there any examples of such usage? Assume that setting up a personal root CA and installing on devices is a plausible option in this case.

This question is similar to: "SSL certificate for a public IP address?", but it's not exactly the same because:

  • I am asking about IPv6 SSL certificates
  • I am just asking whether making these certificates is possible, not how to achieve it (although an explanation of how would be appreciated)

6 Answers 6


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, 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

     Version: 3 (0x2)
     Serial: 1500 (0x5dc)
     Signature Algorithm: SHA256WithRSAEncryption
     Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
      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:

        sbgp-ipAddrBlock: critical

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: 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 details how an IP address is validated, with the following possibilities (see the document for details):

  • Agreed-Upon Change to Website
  • Email, Fax, SMS, or Postal Mail to IP Address Contact
  • Reverse Address Lookup
  • Any Other Method (which is now moot because of "CAs SHALL NOT perform validations using this method after July 31, 2019.")
  • Phone Contact with IP Address Contact
  • ACME “http-01” method for IP Addresses
  • 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.

  • IP-based URIs for DoH are of course a problem in mobile clients. That's why Android demands a hostname for DoT, not IPs.
    – TJJ
    Mar 4, 2020 at 21:55
  • @TJJ But if you use an hostname, to connect to it, you need to resolve its name to an IP address, hence you need the DNS for that, so you have a chicken and egg problem. Jul 24, 2021 at 16:40
  • Yeah, you need one initial lookup. IPs are also a problem in IPv4- or IPv6-only networks, where the IP you're using might not work.
    – TJJ
    Aug 15, 2021 at 13:30

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.

  • 3
    Yes they will, and the question says that a private CA is an option.
    – womble
    Aug 21, 2019 at 3:40
  • 1
    Wow. I learned something today. I thought they had entirely stopped issuing certs for IP addresses. Aug 21, 2019 at 4:28
  • 2
    @MichaelHampton: cabforum a few years back prohibited issuance (and required revocation) of certs for reserved IP addresses such as rfc1918, fe80::/10 and similar. 'Real' (routable) addresses that you 'own' are still permitted. Aug 21, 2019 at 5:05
  • 3
    support.globalsign.com/customer/portal/articles/… has an horrible example: "and a SAN for 123.456.78.90 would be specified as iPAddress." as if 123.456.78.90 would be a valid IPv4 address. Coming from a CA, this is scary.. Aug 29, 2019 at 5:54
  • 1
    If that's the worst thing you find coming from a CA this week, consider yourself lucky. For true horror, you've got to go look at some of the certificates they issue...
    – womble
    Aug 31, 2019 at 22:31

Regarding production use, cloudflare-dns.com is more commonly known as 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

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.


Yes it is possible to have an SSL cert for an IPv6 address. It may be an Self-Signed one or from a Trusted CA such a DigiCert.

See the below IPv6 has an SSL cert. (Its By the service)


  • 2
    This answer does not appear to add anything beyond what is already mentioned in other answers.
    – anx
    Feb 6, 2021 at 17:08

Technically it is perfectly possible, however some CA's do not support it. Let's Encrypt does not support IPv4 and IPv6 and are clear about it, but for example Sectigo does support IPv4 but not IPv6, but that difference is not documented clearly in their documentation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .