Add certificate to conn.internet.nl

[baknu]

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

[baknu]

See also #355

[baknu]

For Sectigo certs for IP addresses see: https://sectigostore.com/page/ssl-certificate-for-ip-address/

[baknu]

Note that CSP currently does not allow IP addresses. See: https://www.w3.org/TR/CSP3/#match-hosts

[baknu]

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.

[baknu]

@gthess: question: could you explain a bit on why we need unique ID's in the labels for the connection test? Thanks!

[gthess]

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.

[bwbroersma]

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-challenge subdomain to a validation-specific server or zone.

Source DNS-01 challenge - Challenge Types - Let's Encrypt.

[baknu]

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.

[dennisbaaten]

This certificate (for IP address) also seems necessary for people using a browser in HTTPS only mode.

[mdavids]

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.

[baknu]

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.

[baknu]

To be discussed in stuurgroep

[mxsasha]

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)

[bwbroersma]

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.