Add certificate to conn.internet.nl
We connect directly to an IP address over HTTP to test IPv6 connectivity. Because of possible 'mixed content' warnings conn.internet.nl does not do HTTPS. However, it seems possible to have a valid CA certificate for IP addresses. For example check https://1.1.1.1
See also #355
For Sectigo certs for IP addresses see: https://sectigostore.com/page/ssl-certificate-for-ip-address/
Note that CSP currently does not allow IP addresses. See: https://www.w3.org/TR/CSP3/#match-hosts
To make the whole connection test run via HTTPS, we probably also need (wildcard) certs for:
- *.bogus.conn.test-ns-signed.internet.nl
- *..aaaa.conn.test-ns-signed.internet.nl
- *.a.conn.test-ns-signed.internet.nl
- *.a-aaaa.conn.test-ns6-signed.internet.nl
Note that ACME seems to require a DNS challenge for wildcard certs.
@gthess: question: could you explain a bit on why we need unique ID's in the labels for the connection test? Thanks!
Because the client information is encoded in the unique ID of the qname. Then the data from DNS can be correlated with the ongoing test.
Since test-ns-signed.internet.nl has it's own nameserver, we can automatically manage _acme-challenge, so we can handle the Let's Encrypt dns-01 validation method.
BTW looking into this, we could also handle ACME on the main domain this way (but we don't need/want wildcard certificates on the apex domain):
Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the
_acme-challengesubdomain to a validation-specific server or zone.
Just spoke with @bwbroersma about this: CNAME might also be a solution to automate the renewal of DANE records. However, note that the availability of the delegated nameserver is probably not as good as that of our main nameservers.
This certificate (for IP address) also seems necessary for people using a browser in HTTPS only mode.
FWIW: We tried to get a certificate for IP addresses from Sectigo a while back for our DoH service (DNS4ALL.eu) but ultimately gave up, because they weren't able to verify IPv6 addresses.
Thanks for sharing your experience, @mdavids! It seems that Digicert and Globalsign support TLS certificates for IPv6 addresses:
- "DigiCert supports IPv6 in SAN as does GlobalSign. Problem is: Its only supported on their Enterprise PKI platform. In the case of GlobalSign that platform is called ATLAS and in the case if DigiCert its called PKI 8" (https://www.reddit.com/r/ipv6/comments/1729k4k/issue_ssl_certificate_for_public_ipv6/)
- 1.1.1.1 (Cloudflare) uses Digicert.
To be discussed in stuurgroep
Stuurgroep discussion:
- Our goal is HTTPS-only conntest.
- We should get wildcard certs for the conntest hostnames.
- IP cert is very difficult for now, SIDN is also trying to do this.
- We definitely do not want a manual separate cert management process for direct IPv6 test.
- If that is the only option, we can remove direct IPv6 testing from the conntest (connecting to a AAAA-only hostname would still be tested)
To document an idea I shared with the email-security-scans.org project: since they need it for mta-sts.* a wildcard certificate is not possible. Wildcard certificates might not be ideal for apex domains, but IMHO they are way less of a risk when used with a deep hostname, e.g. *.{bogus,aaaa,a,a-aaaa}.conn.test-ns-signed.internet.nl. However this is still a neat concept to use, if needed:
Rate Limits - Let's Encrypt (letsencrypt.org)
- Certificates per Registered Domain (50 per week)
- 100 Names per Certificate
- Renewals are treated specially: they don’t count against your Certificates per Registered Domain
100×50=5 000 SANS per week can be added, in 12 weeks that are 60 000 unique names. I thought of a ‘pool’ before. However a pool of 1000 – 100 000 hostnames might not be ‘enough random’. A way to fix this would be using some ‘Code-division multiplexing’ (like in CDMA), have 1000 domains, use 3 hostnames (as desired about the unique/random-ness), this would give 1000³=10⁹=1E9. Of course if 10 000 or 100 000 hostnames are used, the math is more in our favor in terms of reaching larger combinations with fewer traffic/tests. The downside of is of course is extra traffic/tests in general.
So it’s nice to build up a large pool of certificates first, this will require some extra scripting with ‘delays’ to not hit the LE rate limits.
RFC8738 "Automated Certificate Management Environment (ACME) IP Identifier Validation Extension", https://datatracker.ietf.org/doc/html/rfc8738
LE started issuing certs for IP addresses: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate/