[9front] wildcard in auth/acmed

[9front] wildcard in auth/acmed

[Dave MacFarlane]

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);
 	}

Re: [9front] wildcard in auth/acmed

[ori]

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);
>  	}

Re: [9front] wildcard in auth/acmed

[Dave MacFarlane]

[-- 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);
>  	}

Re: [9front] wildcard in auth/acmed

[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?