* [9front] wildcard in auth/acmed
@ 2024-01-15 14:36 Dave MacFarlane
2024-01-15 17:02 ` ori
0 siblings, 1 reply; 4+ messages in thread
From: Dave MacFarlane @ 2024-01-15 14:36 UTC (permalink / raw)
To: 9front
I was trying to use a Let's Encrypt certificate to host a subdomain,
and the only way I could figure out how to do that was a wildcard certificate
because !/bin/service/tcp443 takes the certificate as an argument before
rc-httpd knows what domain it's for.
A wildcard certificate for *.example.com doesn't cover example.com
with no prefix, so I had to add it as a subject alternative name, but Let's Encrypt
seems to ignore the -t dns and send an http-01 challenge for the non-wildcard
portion and a dns-01 challenge for the wildcard.
I added a "hybrid" type to auth/acmed which determines whether to use dnschallenge
or httpchallenge based on the challenge, but isn't compatible with -o since dnschallenge
and httpchallenge need different formats.
With this, I was able to register a certificate request I created by:
auth/rsa2csr 'CN=*.example.com,example.com' $certkey>$csr
auth/acmed -t hybrid $username $acmeuser $csr >$crt
diff 9c2e8e2b13b0d01b7adf88b61af6edfbddd872c1 uncommitted
--- a/sys/src/cmd/auth/acmed.c
+++ b/sys/src/cmd/auth/acmed.c
@@ -633,6 +633,18 @@
}
static int
+hybridchallenge(char *ty, char *dom, char *tok, int *matched)
+{
+ if (strcmp(ty, "http-01") == 0){
+ challengeout = "/usr/web/.well-known/acme-challenge";
+ return httpchallenge(ty, dom, tok, matched);
+ } else if (strcmp(ty, "dns-01") == 0){
+ challengeout = "/lib/ndb/dnschallenge";
+ return dnschallenge(ty, dom, tok, matched);
+ }
+ return -1;
+}
+static int
dochallenges(char *dom[], int ndom, JSON *order)
{
JSON *chals, *j, *cl, *id, *wc;
@@ -910,7 +922,13 @@
}else if(strcmp(ct, "dns") == 0){
challengeout = (co != nil) ? co : "/lib/ndb/dnschallenge";
challengefn = dnschallenge;
- }else {
+ }else if (strcmp(ct, "hybrid") == 0){
+ if (co != nil) {
+ sysfatal("-o not compatible with hybrid challenge");
+ }
+ challengefn = hybridchallenge;
+
+ } else {
sysfatal("unknown challenge type '%s'", ct);
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9front] wildcard in auth/acmed
2024-01-15 14:36 [9front] wildcard in auth/acmed Dave MacFarlane
@ 2024-01-15 17:02 ` ori
2024-01-15 17:20 ` Dave MacFarlane
0 siblings, 1 reply; 4+ messages in thread
From: ori @ 2024-01-15 17:02 UTC (permalink / raw)
To: 9front
I'm confused about why a hybrid challenge type is needed; my
read of the RFC is that we should be using DNS challenges if
there's a wildcard domain name. To my knowlege, wildcards
should already work (though I haven't tested in a while).
As a side note, you can create one cert that covers multiple
domains. For example:
auth/rsa2csr 'CN=foo.example.com,bar.example.com,test.ai' $key>$csr
should work just fine for any of those domains. It doesn't
even need to be the same 'base' URL; This is how we get a
valid cert on both https://shithub.us and
https://only9fans.com; both domains serve the came cert,
with CN=shithub.us,only9fans.com
Quoth Dave MacFarlane <driusan@driusan.net>:
> I was trying to use a Let's Encrypt certificate to host a subdomain,
> and the only way I could figure out how to do that was a wildcard certificate
> because !/bin/service/tcp443 takes the certificate as an argument before
> rc-httpd knows what domain it's for.
>
> A wildcard certificate for *.example.com doesn't cover example.com
> with no prefix, so I had to add it as a subject alternative name, but Let's Encrypt
> seems to ignore the -t dns and send an http-01 challenge for the non-wildcard
> portion and a dns-01 challenge for the wildcard.
>
> I added a "hybrid" type to auth/acmed which determines whether to use dnschallenge
> or httpchallenge based on the challenge, but isn't compatible with -o since dnschallenge
> and httpchallenge need different formats.
>
> With this, I was able to register a certificate request I created by:
>
> auth/rsa2csr 'CN=*.example.com,example.com' $certkey>$csr
> auth/acmed -t hybrid $username $acmeuser $csr >$crt
>
> diff 9c2e8e2b13b0d01b7adf88b61af6edfbddd872c1 uncommitted
> --- a/sys/src/cmd/auth/acmed.c
> +++ b/sys/src/cmd/auth/acmed.c
> @@ -633,6 +633,18 @@
> }
>
> static int
> +hybridchallenge(char *ty, char *dom, char *tok, int *matched)
> +{
> + if (strcmp(ty, "http-01") == 0){
> + challengeout = "/usr/web/.well-known/acme-challenge";
> + return httpchallenge(ty, dom, tok, matched);
> + } else if (strcmp(ty, "dns-01") == 0){
> + challengeout = "/lib/ndb/dnschallenge";
> + return dnschallenge(ty, dom, tok, matched);
> + }
> + return -1;
> +}
> +static int
> dochallenges(char *dom[], int ndom, JSON *order)
> {
> JSON *chals, *j, *cl, *id, *wc;
> @@ -910,7 +922,13 @@
> }else if(strcmp(ct, "dns") == 0){
> challengeout = (co != nil) ? co : "/lib/ndb/dnschallenge";
> challengefn = dnschallenge;
> - }else {
> + }else if (strcmp(ct, "hybrid") == 0){
> + if (co != nil) {
> + sysfatal("-o not compatible with hybrid challenge");
> + }
> + challengefn = hybridchallenge;
> +
> + } else {
> sysfatal("unknown challenge type '%s'", ct);
> }
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9front] wildcard in auth/acmed
2024-01-15 17:02 ` ori
@ 2024-01-15 17:20 ` Dave MacFarlane
0 siblings, 0 replies; 4+ messages in thread
From: Dave MacFarlane @ 2024-01-15 17:20 UTC (permalink / raw)
To: ori, 9front
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
It's not a question of what challenge we request to use,
it's a question of what challenges Let's Encrypt sends
back to our request when we submit the csr. It doesn't always
match what we requested.
It will always include a dns challenge for a wildcard
certificate, even if we request an http challenge. In the case
where I requested a wildcard and the non-subdomain certificate,
it was sending back a dns challenge for the wildcard
and an http challenge for the domain root, even if I submitted
the signing request with auth/acmed -t dns.
The hybrid means "I don't know what the signer is going to request,
so figure it out when I get the challenge."
[-- Attachment #2: Type: message/rfc822, Size: 4616 bytes --]
From: ori@eigenstate.org
To: 9front@9front.org
Subject: Re: [9front] wildcard in auth/acmed
Date: Mon, 15 Jan 2024 12:02:39 -0500
Message-ID: <E8DF00A24335289ECDB5A610ADB1EAA7@eigenstate.org>
I'm confused about why a hybrid challenge type is needed; my
read of the RFC is that we should be using DNS challenges if
there's a wildcard domain name. To my knowlege, wildcards
should already work (though I haven't tested in a while).
As a side note, you can create one cert that covers multiple
domains. For example:
auth/rsa2csr 'CN=foo.example.com,bar.example.com,test.ai' $key>$csr
should work just fine for any of those domains. It doesn't
even need to be the same 'base' URL; This is how we get a
valid cert on both https://shithub.us and
https://only9fans.com; both domains serve the came cert,
with CN=shithub.us,only9fans.com
Quoth Dave MacFarlane <driusan@driusan.net>:
> I was trying to use a Let's Encrypt certificate to host a subdomain,
> and the only way I could figure out how to do that was a wildcard certificate
> because !/bin/service/tcp443 takes the certificate as an argument before
> rc-httpd knows what domain it's for.
>
> A wildcard certificate for *.example.com doesn't cover example.com
> with no prefix, so I had to add it as a subject alternative name, but Let's Encrypt
> seems to ignore the -t dns and send an http-01 challenge for the non-wildcard
> portion and a dns-01 challenge for the wildcard.
>
> I added a "hybrid" type to auth/acmed which determines whether to use dnschallenge
> or httpchallenge based on the challenge, but isn't compatible with -o since dnschallenge
> and httpchallenge need different formats.
>
> With this, I was able to register a certificate request I created by:
>
> auth/rsa2csr 'CN=*.example.com,example.com' $certkey>$csr
> auth/acmed -t hybrid $username $acmeuser $csr >$crt
>
> diff 9c2e8e2b13b0d01b7adf88b61af6edfbddd872c1 uncommitted
> --- a/sys/src/cmd/auth/acmed.c
> +++ b/sys/src/cmd/auth/acmed.c
> @@ -633,6 +633,18 @@
> }
>
> static int
> +hybridchallenge(char *ty, char *dom, char *tok, int *matched)
> +{
> + if (strcmp(ty, "http-01") == 0){
> + challengeout = "/usr/web/.well-known/acme-challenge";
> + return httpchallenge(ty, dom, tok, matched);
> + } else if (strcmp(ty, "dns-01") == 0){
> + challengeout = "/lib/ndb/dnschallenge";
> + return dnschallenge(ty, dom, tok, matched);
> + }
> + return -1;
> +}
> +static int
> dochallenges(char *dom[], int ndom, JSON *order)
> {
> JSON *chals, *j, *cl, *id, *wc;
> @@ -910,7 +922,13 @@
> }else if(strcmp(ct, "dns") == 0){
> challengeout = (co != nil) ? co : "/lib/ndb/dnschallenge";
> challengefn = dnschallenge;
> - }else {
> + }else if (strcmp(ct, "hybrid") == 0){
> + if (co != nil) {
> + sysfatal("-o not compatible with hybrid challenge");
> + }
> + challengefn = hybridchallenge;
> +
> + } else {
> sysfatal("unknown challenge type '%s'", ct);
> }
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9front] wildcard in auth/acmed
[not found] <2CEDDEA2213DC4D744EAF757A28E45EC@driusan.net>
@ 2024-01-15 17:38 ` ori
0 siblings, 0 replies; 4+ messages in thread
From: ori @ 2024-01-15 17:38 UTC (permalink / raw)
To: 9front, driusan, ori
Quoth Dave MacFarlane <driusan@driusan.net>:
> It's not a question of what challenge we request to use,
> it's a question of what challenges Let's Encrypt sends
> back to our request when we submit the csr. It doesn't always
> match what we requested.
>
> It will always include a dns challenge for a wildcard
> certificate, even if we request an http challenge. In the case
> where I requested a wildcard and the non-subdomain certificate,
> it was sending back a dns challenge for the wildcard
> and an http challenge for the domain root, even if I submitted
> the signing request with auth/acmed -t dns.
>
> The hybrid means "I don't know what the signer is going to request,
> so figure it out when I get the challenge."
is there a reason to keep the '-t' flag if we add logic to just
figure it out?
Maybe we split up the output location flags, and have one per
type, and figure it out from that?
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-01-15 17:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-15 14:36 [9front] wildcard in auth/acmed Dave MacFarlane
2024-01-15 17:02 ` ori
2024-01-15 17:20 ` Dave MacFarlane
[not found] <2CEDDEA2213DC4D744EAF757A28E45EC@driusan.net>
2024-01-15 17:38 ` ori
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).