Certificates for DoT and DoH?
Any recommendations for a CA with a published policy allowing an IP address SAN (Subject Alternative Name)? Preferably someone using ACME with a simple RFC 8738 reference. Let's Encrypt had this in their TODO list for a while, but it was removed and the project was put on hold: https://github.com/letsencrypt/boulder/pull/4920#issuecomment-832104881 https://community.letsencrypt.org/t/planned-rfc-8738-support-pulled/152057 And I've been unable to find any other CAs with RFC 8738 support either. Most of them don't even bother documenting it as unsupported. All I've found is this answer from Buypass: https://community.buypass.com/t/h7hm76w/buypass-support-for-rfc-8738 So what do people use for DoT and DoH? I see that Google got a certificate from their own CA. No surprise... Version: 3 (0x2) Serial Number: 9c:d9:a2:0f:fe:dd:2b:0a:12:00:00:00:00:03:6f:0b Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 Validity Not Before: Feb 17 11:34:59 2022 GMT Not After : May 12 11:34:58 2022 GMT Subject: CN = dns.google Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:ec:43:69:7c:2b:7d:99:d5:f3:79:d7:b8:54:bd: 6e:61:7b:8d:50:c5:bb:86:6c:a3:60:27:3e:22:c6: 45:00:68:a2:d2:2e:c9:c2:8f:8e:58:0e:93:0a:a4: ff:2d:5c:71:d9:0a:5b:f3:1c:ce:79:d2:71:5c:20: 4a:34:21:c1:fa:c3:92:bd:e8:7e:bd:93:79:ef:ad: 0b:74:e0:21:f6:22:4e:9c:39:01:48:49:bc:a0:db: 98:0b:ab:4c:df:99:b1:30:92:09:0d:f8:ea:0f:7f: 85:65:55:e7:9f:ba:88:4a:ca:93:04:71:8d:13:f7: 3b:e3:36:ee:fc:b7:b9:fc:e5:5a:a8:7b:22:ce:0a: dd:4b:36:ee:d9:8f:09:d4:2e:3f:48:5e:f8:7c:71: 2d:65:26:29:67:b9:c7:b2:77:8a:60:20:4f:dd:74: 00:49:c5:6f:3b:19:d0:ea:f8:78:ef:86:02:37:be: 3d:2e:d1:14:18:22:22:e6:94:65:bb:9d:37:b8:61: 8b:2c:fc:85:bc:04:01:56:74:04:b9:86:dc:59:9a: 75:9d:de:d9:65:67:5d:9f:75:f3:6d:8a:4f:61:d2: c5:b5:e1:dd:2e:54:78:8a:a8:39:ab:d1:0c:97:4d: bc:7d:f2:64:cb:d3:21:5a:f0:70:03:08:a6:f4:21: 4c:63 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: A6:21:3C:08:17:99:1E:DE:2D:F5:EB:C8:90:C9:71:D2:E9:53:1D:EE X509v3 Authority Key Identifier: keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27 Authority Information Access: OCSP - URI:http://ocsp.pki.goog/gts1c3 CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der X509v3 Subject Alternative Name: DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com, DNS:8888.google, DNS:dns64.dns.google, IP Address:8.8.8.8, IP Address:8.8.4.4, IP Address:2001:4860:4860:0:0:0:0:8888, IP Address:2001:4860:4860:0:0:0:0:8844, IP Address:2001:4860:4860:0:0:0:0:6464, IP Address:2001:4860:4860:0:0:0:0:64 X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.11129.2.5.3 X509v3 CRL Distribution Points: Full Name: URI:http://crls.pki.goog/gts1c3/zdATt0Ex_Fk.crl [cut] But this is not an option for anyone else according to https://pki.goog/faq/#faq-29 : How can I get a certificate from Google Trust Services? At this time, the only way to get a certificate from Google Trust Services is via an Alphabet or Google product. I guess it's easy to push for DoT and DoH when you can create rules like that. Both Quad9 and Cloudflare got their certificates from DigiCert: Version: 3 (0x2) Serial Number: 05:45:06:fe:17:98:52:bb:fa:c1:a7:3d:cd:80:39:7b Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Validity Not Before: Jul 27 00:00:00 2021 GMT Not After : Aug 4 23:59:59 2022 GMT Subject: C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:7d:8b:d7:1d:03:85:0d:18:25:b3:34:1c:29:a1: 27:d4:ac:01:25:48:8a:a0:f1:ea:02:b9:d8:51:2c: 08:6a:ac:72:56:ec:fa:3d:a6:a0:9f:49:09:55:8e: ac:fe:b9:73:17:5c:02:fb:78:cc:24:91:94:6f:43: 23:89:0e:1d:66 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A X509v3 Subject Key Identifier: 7F:A9:12:A5:D7:C6:8B:48:02:C7:3D:2A:45:6E:40:1E:40:60:F4:97 X509v3 Subject Alternative Name: DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl Full Name: URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 CPS: http://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt X509v3 Basic Constraints: critical CA:FALSE [cut] Version: 3 (0x2) Serial Number: 0f:75:a3:6d:32:c1:6b:03:c7:ca:5f:5f:71:4a:03:70 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Validity Not Before: Oct 25 00:00:00 2021 GMT Not After : Oct 25 23:59:59 2022 GMT Subject: C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:fb:29:44:f2:98:3f:d8:bd:82:56:d3:2c:bd:8e: 09:9f:31:2b:98:26:9e:22:96:8d:7b:4b:fc:da:c5: 7b:7b:29:aa:8e:35:6c:9c:0a:48:05:6c:89:73:ed: 20:0e:cd:46:21:f0:ec:4d:b3:a5:e9:af:1b:38:99: e5:f4:da:f1:84 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A X509v3 Subject Key Identifier: 19:45:1B:23:18:F8:74:DA:22:14:CB:46:6B:E2:13:B3:60:15:82:40 X509v3 Subject Alternative Name: DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, DNS:one.one.one.one, IP Address:1.1.1.1, IP Address:1.0.0.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl Full Name: URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 CPS: http://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt X509v3 Basic Constraints: critical CA:FALSE CT Precertificate SCTs: [cut] Does this mean that DigiCert is the only alternative? And do they really have this offer for ordinary users, or is this also some special arrangement for big players only? I see that a CSR with a DNS name, an IPv4 address and an IPv6 address is accepted by https://www.digicert.com/ssltools/view-csr/ But when I test the same CSR on their order page, only the DNS name is extracted into the order form. Leaving me confused and worried about the addresses being ignored. And their documentation sucks. Like all CAs, I might add. There is no mention of how you are supposed to demonstraete IP address control on https://docs.digicert.com/manage-certificates/demonstrate-control-over-domai... Searchin for RFC 8738 on https://docs.digicert.com/search/?query=8738 returns "No results found for 8738". Even if they do have ACME support for automated certificate management. So I guess automated certificate management of certificates with IP address SANs is out of the question. That's a bummer. I really, really do not want to go back to semi-manual certificate management hell and the resulting periodical breakage. https://www.digicert.com/tls-ssl/multi-domain-ssl-certificates looks like a bad joke: The Subject Alternative Name field lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single TLS/SSL certificate That does make me wonder how they verify that I'm the rightful owner of "sites, IP addresses, common names, etc.". In particular, "etc" :-) Or you could ask yourself if you trust a CA with such an offer... Yes, I'm frustrated. Why is a business that is mostly about selling policies so afraid of actually publishing those policies? Bjørn
On Feb 28, 2022, at 3:29 PM, Bjørn Mork <bjorn@mork.no> wrote: Any recommendations for a CA with a published policy allowing an IP address SAN (Subject Alternative Name)? Both Quad9 got their certificate from DigiCert:
Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Subject: C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net X509v3 Subject Alternative Name: DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15
Does this mean that DigiCert is the only alternative?
I assume not, but we’d already used them for other things, and they didn’t have a problem doing it, so we didn’t shop any further.
And do they really have this offer for ordinary users, or is this also some special arrangement for big players only?
No, we didn’t have to do anything special, to the best of my knowledge.
That does make me wonder how they verify that I'm the rightful owner of "sites, IP addresses, common names, etc.". In particular, "etc" :-) Or you could ask yourself if you trust a CA with such an offer...
Yep. DANE is the correct answer. CAs are not. But that’s been true for a very long time, and people are still trying to pretend that CAs know what’s what. -Bill
Bill Woodcock <woody@pch.net> writes:
Does this mean that DigiCert is the only alternative?
I assume not, but we’d already used them for other things, and they didn’t have a problem doing it, so we didn’t shop any further.
Makes sense. That's how I started as well. But we are using Buypass, and for some unknown reason they did have a problem doing it.
And do they really have this offer for ordinary users, or is this also some special arrangement for big players only?
No, we didn’t have to do anything special, to the best of my knowledge.
Good to know. Thanks
That does make me wonder how they verify that I'm the rightful owner of "sites, IP addresses, common names, etc.". In particular, "etc" :-) Or you could ask yourself if you trust a CA with such an offer...
Yep. DANE is the correct answer. CAs are not. But that’s been true for a very long time, and people are still trying to pretend that CAs know what’s what.
Agree 100%. Now I'm going to ask another stupid question: How would DANE work for DoT/DoH? Having TLSA records in in-addr.arpa and ip6.arpa? Bjørn
On 28 Feb 2022, at 7:11, Bill Woodcock wrote:
On Feb 28, 2022, at 3:29 PM, Bjørn Mork <bjorn@mork.no> wrote: Any recommendations for a CA with a published policy allowing an IP address SAN (Subject Alternative Name)? Both Quad9 got their certificate from DigiCert:
Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Subject: C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net X509v3 Subject Alternative Name: DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15
Does this mean that DigiCert is the only alternative?
I assume not, but we’d already used them for other things, and they didn’t have a problem doing it, so we didn’t shop any further.
Update to Bill’s comments: They were the only CA at that time who would include IPv6 addresses in the signature, so it actually was a simple decision but for a different reason. We’re happy with how it’s working with them. For a few niche cases like recursive DNS, v6 signing is required, and Digicert went out of their way to implement that v6 ability. Thanks to them for making it available to what is probably a very small group of potential customers - they deserve some credit for making the technical effort and product decision.
And do they really have this offer for ordinary users, or is this also some special arrangement for big players only?
No, we didn’t have to do anything special, to the best of my knowledge.
Nothing “special” meaning there is no custom business relationship, but it did take time and having a highly capable and persistent team here at Quad9 who could track the request through the process and get it done successfully, and for Digicert to work to create a process that wasn’t entirely customized. While I can’t speak for Digicert, I would suspect v6 address signing is still not entirely “off the shelf” or in the best case it is “barely off the shelf” for ordering on the website but it is a product they can reliably deliver if you talk to someone there.
That does make me wonder how they verify that I'm the rightful owner of "sites, IP addresses, common names, etc.". In particular, "etc" :-) Or you could ask yourself if you trust a CA with such an offer... [snip]
To validate that the addresses were “ours” or at least under our control, there were still some hoops to jump through other than the standard validation of registry data. For example, we had to activate web servers and objects on our anycast network to answer specific queries during some of the check processes. TL;DR: Digicert is still the only player for v6 signing, and it will not be entirely hands-free to manage but also not overly difficult. JT -- John Todd - jtodd@quad9.net General Manager - Quad9 Recursive Resolver
John Todd <jtodd@quad9.net> writes:
To validate that the addresses were “ours” or at least under our control, there were still some hoops to jump through other than the standard validation of registry data. For example, we had to activate web servers and objects on our anycast network to answer specific queries during some of the check processes.
TL;DR: Digicert is still the only player for v6 signing, and it will not be entirely hands-free to manage but also not overly difficult.
Thanks a lot! This is incredibly useful. Yes, we are sort of prepared for the web server hoops. Not trivial since our addresses aren't normally reachable from the Internet, even if they are public and advertised. We are only providing AS internal DNS resolver service. Dropping outside traffic is an easy way to add some protection. But that's just one more hoop. The technical challenges are nothing anyway. Getting permission from sourcing to buy something from a new partner will be far worse... So I will go another round with our existing partners first. Thanks again. Bjørn
Hi Mork, You don't need a certificate for your IP address if your DoT and DoH use domains. For certificates with IPv4 address, we use ZeroSSL / GoGetSSL, both are SubCA with Sectigo, which works fine. For IPv6 address, we used Digicert but it's too expensive, so we give up ☹ Our DoT/DoH service is https://dns.sb/ Regards, David -----Original Message----- From: NANOG <nanog-bounces+david=xtom.com@nanog.org> On Behalf Of Bjørn Mork Sent: Monday, February 28, 2022 10:30 PM To: nanog@nanog.org Subject: Certificates for DoT and DoH? Any recommendations for a CA with a published policy allowing an IP address SAN (Subject Alternative Name)? Preferably someone using ACME with a simple RFC 8738 reference. Let's Encrypt had this in their TODO list for a while, but it was removed and the project was put on hold: https://github.com/letsencrypt/boulder/pull/4920#issuecomment-832104881 https://community.letsencrypt.org/t/planned-rfc-8738-support-pulled/152057 And I've been unable to find any other CAs with RFC 8738 support either. Most of them don't even bother documenting it as unsupported. All I've found is this answer from Buypass: https://community.buypass.com/t/h7hm76w/buypass-support-for-rfc-8738 So what do people use for DoT and DoH? I see that Google got a certificate from their own CA. No surprise... Version: 3 (0x2) Serial Number: 9c:d9:a2:0f:fe:dd:2b:0a:12:00:00:00:00:03:6f:0b Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 Validity Not Before: Feb 17 11:34:59 2022 GMT Not After : May 12 11:34:58 2022 GMT Subject: CN = dns.google Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:ec:43:69:7c:2b:7d:99:d5:f3:79:d7:b8:54:bd: 6e:61:7b:8d:50:c5:bb:86:6c:a3:60:27:3e:22:c6: 45:00:68:a2:d2:2e:c9:c2:8f:8e:58:0e:93:0a:a4: ff:2d:5c:71:d9:0a:5b:f3:1c:ce:79:d2:71:5c:20: 4a:34:21:c1:fa:c3:92:bd:e8:7e:bd:93:79:ef:ad: 0b:74:e0:21:f6:22:4e:9c:39:01:48:49:bc:a0:db: 98:0b:ab:4c:df:99:b1:30:92:09:0d:f8:ea:0f:7f: 85:65:55:e7:9f:ba:88:4a:ca:93:04:71:8d:13:f7: 3b:e3:36:ee:fc:b7:b9:fc:e5:5a:a8:7b:22:ce:0a: dd:4b:36:ee:d9:8f:09:d4:2e:3f:48:5e:f8:7c:71: 2d:65:26:29:67:b9:c7:b2:77:8a:60:20:4f:dd:74: 00:49:c5:6f:3b:19:d0:ea:f8:78:ef:86:02:37:be: 3d:2e:d1:14:18:22:22:e6:94:65:bb:9d:37:b8:61: 8b:2c:fc:85:bc:04:01:56:74:04:b9:86:dc:59:9a: 75:9d:de:d9:65:67:5d:9f:75:f3:6d:8a:4f:61:d2: c5:b5:e1:dd:2e:54:78:8a:a8:39:ab:d1:0c:97:4d: bc:7d:f2:64:cb:d3:21:5a:f0:70:03:08:a6:f4:21: 4c:63 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: A6:21:3C:08:17:99:1E:DE:2D:F5:EB:C8:90:C9:71:D2:E9:53:1D:EE X509v3 Authority Key Identifier: keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27 Authority Information Access: OCSP - URI:http://ocsp.pki.goog/gts1c3 CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der X509v3 Subject Alternative Name: DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com, DNS:8888.google, DNS:dns64.dns.google, IP Address:8.8.8.8, IP Address:8.8.4.4, IP Address:2001:4860:4860:0:0:0:0:8888, IP Address:2001:4860:4860:0:0:0:0:8844, IP Address:2001:4860:4860:0:0:0:0:6464, IP Address:2001:4860:4860:0:0:0:0:64 X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.11129.2.5.3 X509v3 CRL Distribution Points: Full Name: URI:http://crls.pki.goog/gts1c3/zdATt0Ex_Fk.crl [cut] But this is not an option for anyone else according to https://pki.goog/faq/#faq-29 : How can I get a certificate from Google Trust Services? At this time, the only way to get a certificate from Google Trust Services is via an Alphabet or Google product. I guess it's easy to push for DoT and DoH when you can create rules like that. Both Quad9 and Cloudflare got their certificates from DigiCert: Version: 3 (0x2) Serial Number: 05:45:06:fe:17:98:52:bb:fa:c1:a7:3d:cd:80:39:7b Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Validity Not Before: Jul 27 00:00:00 2021 GMT Not After : Aug 4 23:59:59 2022 GMT Subject: C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:7d:8b:d7:1d:03:85:0d:18:25:b3:34:1c:29:a1: 27:d4:ac:01:25:48:8a:a0:f1:ea:02:b9:d8:51:2c: 08:6a:ac:72:56:ec:fa:3d:a6:a0:9f:49:09:55:8e: ac:fe:b9:73:17:5c:02:fb:78:cc:24:91:94:6f:43: 23:89:0e:1d:66 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A X509v3 Subject Key Identifier: 7F:A9:12:A5:D7:C6:8B:48:02:C7:3D:2A:45:6E:40:1E:40:60:F4:97 X509v3 Subject Alternative Name: DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl Full Name: URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 CPS: http://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt X509v3 Basic Constraints: critical CA:FALSE [cut] Version: 3 (0x2) Serial Number: 0f:75:a3:6d:32:c1:6b:03:c7:ca:5f:5f:71:4a:03:70 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Validity Not Before: Oct 25 00:00:00 2021 GMT Not After : Oct 25 23:59:59 2022 GMT Subject: C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:fb:29:44:f2:98:3f:d8:bd:82:56:d3:2c:bd:8e: 09:9f:31:2b:98:26:9e:22:96:8d:7b:4b:fc:da:c5: 7b:7b:29:aa:8e:35:6c:9c:0a:48:05:6c:89:73:ed: 20:0e:cd:46:21:f0:ec:4d:b3:a5:e9:af:1b:38:99: e5:f4:da:f1:84 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A X509v3 Subject Key Identifier: 19:45:1B:23:18:F8:74:DA:22:14:CB:46:6B:E2:13:B3:60:15:82:40 X509v3 Subject Alternative Name: DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, DNS:one.one.one.one, IP Address:1.1.1.1, IP Address:1.0.0.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl Full Name: URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 CPS: http://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt X509v3 Basic Constraints: critical CA:FALSE CT Precertificate SCTs: [cut] Does this mean that DigiCert is the only alternative? And do they really have this offer for ordinary users, or is this also some special arrangement for big players only? I see that a CSR with a DNS name, an IPv4 address and an IPv6 address is accepted by https://www.digicert.com/ssltools/view-csr/ But when I test the same CSR on their order page, only the DNS name is extracted into the order form. Leaving me confused and worried about the addresses being ignored. And their documentation sucks. Like all CAs, I might add. There is no mention of how you are supposed to demonstraete IP address control on https://docs.digicert.com/manage-certificates/demonstrate-control-over-domai... Searchin for RFC 8738 on https://docs.digicert.com/search/?query=8738 returns "No results found for 8738". Even if they do have ACME support for automated certificate management. So I guess automated certificate management of certificates with IP address SANs is out of the question. That's a bummer. I really, really do not want to go back to semi-manual certificate management hell and the resulting periodical breakage. https://www.digicert.com/tls-ssl/multi-domain-ssl-certificates looks like a bad joke: The Subject Alternative Name field lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single TLS/SSL certificate That does make me wonder how they verify that I'm the rightful owner of "sites, IP addresses, common names, etc.". In particular, "etc" :-) Or you could ask yourself if you trust a CA with such an offer... Yes, I'm frustrated. Why is a business that is mostly about selling policies so afraid of actually publishing those policies? Bjørn
David Guo <david@xtom.com> writes:
You don't need a certificate for your IP address if your DoT and DoH use domains.
Sorry if I'm slow, but isn't that a chicken-and-egg problem? We're going to provide this as an add-on to our standard ISP resolver service. Most clients will pick up the addresses from DHCP/DHCPv6. Very few are configuring DNS resolvers manually, and those who do are using other providers. Like you :-)
For certificates with IPv4 address, we use ZeroSSL / GoGetSSL, both are SubCA with Sectigo, which works fine.
Thanks. That's interesting. I didn't know ZeroSSL offered this. And GoGetSSL has better docs than most. But we can't run a resolver service without IPv6 in 2022. Did you ever get any explanation of this restriction? Shouldn't be much harder/different to validate an IPv6 address if you can validate an IPv4 address.
For IPv6 address, we used Digicert but it's too expensive, so we give up ☹
Hard to claim it's too expensive if no one else thinks it's worth offering a similar service...
Our DoT/DoH service is https://dns.sb/
Nice. Good to have more examples to look at. Bjørn
Sorry if I'm slow, but isn't that a chicken-and-egg problem?
Normal DoT/DoH problem has bootstrap DNS setting, you always need to set a bootstrap DNS server to resolve the DoT/DoH domains, so this is not a problem. -----Original Message----- From: Bjørn Mork <bjorn@mork.no> Sent: Tuesday, March 1, 2022 3:57 AM To: David Guo <david@xtom.com> Cc: nanog@nanog.org Subject: Re: Certificates for DoT and DoH? David Guo <david@xtom.com> writes:
You don't need a certificate for your IP address if your DoT and DoH use domains.
Sorry if I'm slow, but isn't that a chicken-and-egg problem? We're going to provide this as an add-on to our standard ISP resolver service. Most clients will pick up the addresses from DHCP/DHCPv6. Very few are configuring DNS resolvers manually, and those who do are using other providers. Like you :-)
For certificates with IPv4 address, we use ZeroSSL / GoGetSSL, both are SubCA with Sectigo, which works fine.
Thanks. That's interesting. I didn't know ZeroSSL offered this. And GoGetSSL has better docs than most. But we can't run a resolver service without IPv6 in 2022. Did you ever get any explanation of this restriction? Shouldn't be much harder/different to validate an IPv6 address if you can validate an IPv4 address.
For IPv6 address, we used Digicert but it's too expensive, so we give up ☹
Hard to claim it's too expensive if no one else thinks it's worth offering a similar service...
Our DoT/DoH service is https://dns.sb/
Nice. Good to have more examples to look at. Bjørn
participants (4)
-
Bill Woodcock -
Bjørn Mork -
David Guo -
John Todd